For a college assignment I'm building a networked Java application using sockets*. My architecture must be scalable so I would like to have multiple servers available for my clients to communicate with.
My question is, how can a client know about all available servers? My first thought is for the clients to keep a (hardcoded) list of server IP addresses and select from the list. What is best practice in this case?
*We cannot use RMI.
Let's imagine your network provider's costs got too high, and you decided to switch. Boom go your IP addresses. I would suggest the judicious use of DNS, especially round-robin DNS.
Using a central tracker could seem like a good idea, but it itself must be scalable, akin to Google App Engine, or it will become a chokepoint.
Simply create multiple A-records for a given name, and your clients will randomly select one when resolving.
If you are unable to use DNS an IP list may be beneficial--with one change. All of the servers circulate updated copies of the list and if a server cannot be reached, another is tried until a connection is made(and the list likewise updated). When the list is found to differ from the existing one the client's list is updated.
You can use RMI stuffs, making primary and secondary servers.
Secondary server may be continuously polling primary, when primary goes down, secondary can register on naming services to take on. When primary comes back, it will register back making secondary go down... like that.
Regarding client to know server, client can ask servers using RMI for identity.
Related
i am developing a chat application for local environment where our office employees can chat easily so here I am getting some conflicts when I am trying to send message over the IP but there IP being change dynamically so how can i resolve it .
First of all, I recommend using a well established solution like a local Jabber Server installation and using a client that supports the required features.
If you really want to pull this off on your own, you'll need at least a central controlling point (Server) to abstract Users from their Endpoint.
Configured user would then have to login to that server to signal they are ready to receive messages. Doing this, you have the momentarily correct IP that you can then use to relay messages or to give to other clients wanting to send to that user. Also consider that users may want to use more than one client (they have 2 PCs?). You probably wouldn't want to bind one user to one client device.
Also note that you will have to create a decent protocol for all this. This can be quite tedious if you want similar features to for example Skype Chat or ICQ, or some derivate of XMPP / Jabber.
This leads me again back to my first suggestion: Better use something that already exists. Installing and configuration of that can already be effort enough. Coding all that by yourself, though will take way more effort.
And I didn't even go into status/statusmessages, groupchats, sending/sharing Files, sending messages while User is away/offline ...
I'm creating on online real-time multiplayer mobile game using Kryonet (a Java TCP/UDP networking library) that I'm planning to host on AWS.
The architecture is as follows: clients connect to a central login/account server that allows them to login and view their stats etc. This bit is easy, as it'll basically just be a REST API, and can be scaled in a pretty standard way (like you would any webapp).
However, the more interesting bit is when players actually play a match. For this, I plan to have a separate pool of "match" servers (EC2s). The login/account server will pair two players, then send the client the address of a particular match server. The players will then join that match server, which will host their match (perhaps lasting 5-10 minutes). The match server needs to be sticky as it will be running a real-time instance of the game, and will be sending/receiving UDP packets in real time. Each match server will probably be able to host a few hundred matches.
My question is about how I should go about scaling these match servers. I suppose I will have them auto-register with the central server at start-up, and send some type of keep alive. I could build this all myself; however, I'm wondering if AWS has tools/services that can do this all for me.
Okay, I've done a little more reading of the AWS documentation. It seems that I can probably achieve this as follows:
Each time two players are paired up, they are added to a queue. They are taken off the queue when a spot is free on one of the match-playing servers. When the size of this queue exceeds some threshold, then the number of EC2s is scaled. This can be done with basically all in AWS config: http://docs.aws.amazon.com/autoscaling/latest/userguide/as-using-sqs-queue.html
The tricky bit is then scaling down instances. Unlike a normal REST API, you can't just turn a server off. The server needs to finish all its current games. It seems that AWS has this covered too with lifecycle hooks.
I have a concept of a game system that includes (preferably) Java server and multi-platform clients (Web, Android, iOS).
This is a 1vs1 player-vs-player realtime game. Servers performs a matchup of 2 players. So basically server needs to handle many matches containing 2 players. Both players alter same data, and each player should be updated in realtime with actions of other player.
Can you suggest me:
1) Server-side framework/library that would ease the implementation, as I would rather not start learning node.js from the scratch. :) Vert.x comes to mind.
2) Should clients hold the replica of the data, and alter it locally (meaning only data that is transfered are only commands, here I see JMS as good solution), or should only server alter the data and then send the complete data set every time change occurs?
3) How should the data be transfered? Considering the multi-platform requirement only thing I see viable are WebSockets.
4) An example/tutorial of server handling pairing of WebSocket connections? All I ever found are 1-to-1 connections.
5) Considering scalability, can you explain how could all this work in a distributed environment?
1) I don't think node.js is such big deal to learn. I would personally prefer a well known - broadly used framework.
2) If you are considering mobile, probably the first option seems more sound. You should consider send/push deltas during the game, and still provide functionality to retrieve the full state of the game in case the client disconnect and connect with same ID.
3) WebSocket would be the best option. Push approach, TLS option and well supported. Another option is the WebRTC data connection, that is peer-2-peer most of the times. I say most of the times because if one of the users is behind a dynamic NAT router or restrictive firewall, it won't be possible, and you will need a TURN (relay) server. Anyway, it is less supported than WS.
4) You should not "pair websockets". The WS connections just input commands to your logic, and your logic broadcast events to whoever it wants. Despite of being a 1vs1 game, probably you want to inspect the flow of events for further debugging or analysis. So consider WS as a transport, not as an entity.
5) Very, very, very broad question. But assuming that you are going to use WS, and that your application will be so successful that you will need multiple servers... assume that it is impossible to predict that two users will connect to the same server, so you should consider a message bus that allow to play users from one server with the users in other server. An EDA (Event Driven Architecture) would make sense.
I have a game that is going to use a server to handle multiplayer. The game is turn based but with turns taken simultaneously. Initially I thought I should use a separate thread for each user but I realised that I could simplify by just tracking each user based on their IP. Is this possible or would it lead to issues with dynamic IPs or people playing from the same location?
This could lead to problems because some ISPs, such as AOL, aggregate traffic for multiple users through a single IP. If you track both the client's IP and the client's port number, though, that should be sufficient.
Writing a simple multi client <-> server system in Corba.
I am stuck on unique identification of the client. Is there a mechanism in Corba, like some POA policy that would allow a unique user id to be generated by the server and carried along with all that clients communication.
Basically I have the system setup so I manually do this unique user ID. Client connects, server generates a key which is sent to the client and stored on both ends. A similar setup that you might employ in many environments. What I am asking is if Corba has its own mechanism for this that I can leverage.
CORBA doesn't have any inbuilt client ID mechanism that you can use, unfortunately. The main reason why CORBA never specified it is because it's difficult to define what a "client" really is: is it a process or a thread? Is it an entire tier or a single application instance? What about clients in the same process as the server? In addition, certain developers might want different behavior spanning any of those options.
Personally, I think that your approach of having the server dictate an ID for the client is fine, but keep in mind that it's basically a "session ID" approach, and that can be tough to scale horizontally. Make sure that you absolutely, positively need to ID your clients, because something as simple as client authentication via IIOP/TLS might not do the trick just fine.