Sign in to follow this  

Logic for handle multiple clients in my TCP server written in java

This topic is 2051 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] first of all, this is my first post!
second, i read the FAQ's, but my doubts are still there [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img]

So I'm programming a server for a multiplayer game in Java, but I don't know the proper way to handle the client connections.

The game is like a tiny mmo inspired inspired by Transformice. For those who do not know, Transformice is a MMO flash and tcp based game. It has around 60.000 concurrent players / day average and I wonder how they handle this amount of connections. Right now, my server spawns a thread for every client connection and I read in the FAQ's this is not good but also I thought same before read it.

So basically the question is, how i manage my server to keep as many client connections as hardware / network is capable to (Without spawning a new thread for each client connection because i think this is not suitable for a mmo game).

As far as i know JVM can't handle that huge amount of threads, so this can't be the right way.

also I'm such a noob in networking. I started to learn it few months ago.
Someone gives me some light?

Regards. Edited by Sytto

Share this post


Link to post
Share on other sites
[quote name='Sytto' timestamp='1336249083' post='4937658']
hi [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] first of all, this is my first post!
second, i read the FAQ's, but my doubts are still there [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img]

So I'm programming a server for a multiplayer game in Java, but I don't know the proper way to handle the client connections.

The game is like a tiny mmo inspired inspired by Transformice. For those who do not know, Transformice is a MMO flash and tcp based game. It has around 60.000 concurrent players / day average and I wonder how they handle this amount of connections. Right now, my server spawns a thread for every client connection and I read in the FAQ's this is not good but also I thought same before read it.

So basically the question is, how i manage my server to keep as many client connections as hardware / network is capable to (Without spawning a new thread for each client connection because i think this is not suitable for a mmo game).

As far as i know JVM can't handle that huge amount of threads, so this can't be the right way.

also I'm such a noob in networking. I started to learn it few months ago.
Someone gives me some light?

Regards.
[/quote]

First of all, Transformice is not an MMO, (each game has a very low number of players so you don't need to deal with MMO scale networking for this type of game).

What you should do is have one master server for the "lobby" and then run multiple game servers, They can but doesn't have to be on the same machine but needs different ports and should be handled by their own instance of the server application.

Have the master server keep track of how many instances of the game server each node is running and launch new ones as needed on the least busy node, (You can have game servers report their nodes status to the master server for this purpose)

For the game servers 1 or 2 threads are enough, (having one thread that only waits for new connections and one that runs the game can simplify things slightly)

Share this post


Link to post
Share on other sites
[quote name='Washu' timestamp='1336253793' post='4937665']
You should be using, last I recall, the NIO sockets.
[/quote]

thank you very much, didn't know about this!

[quote name='SimonForsman' timestamp='1336253844' post='4937666']
First of all, Transformice is not an MMO, (each game has a very low number of players so you don't need to deal with MMO scale networking for this type of game).

What you should do is have one master server for the "lobby" and then run multiple game servers, They can but doesn't have to be on the same machine but needs different ports and should be handled by their own instance of the server application.

Have the master server keep track of how many instances of the game server each node is running and launch new ones as needed on the least busy node, (You can have game servers report their nodes status to the master server for this purpose)

For the game servers 1 or 2 threads are enough, (having one thread that only waits for new connections and one that runs the game can simplify things slightly)
[/quote]

I'm not sure if I understand your post. Do you mean that rather than spawning a new thread per client connected, I run some kind of game server node for handle the new client connected ? Or do you mean these game server nodes should be able to handle more than one client ? Because that is what really I was wondering. I can't figure out a way for handling multiple clients without spawning a new thread for each connection.
Maybe I'm a little bad for these things [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] also thank you very much for your answer too!

Regards.

Share this post


Link to post
Share on other sites
[quote name='Sytto' timestamp='1336256848' post='4937678']
[quote name='Washu' timestamp='1336253793' post='4937665']
You should be using, last I recall, the NIO sockets.
[/quote]

thank you very much, didn't know about this!

[quote name='SimonForsman' timestamp='1336253844' post='4937666']
First of all, Transformice is not an MMO, (each game has a very low number of players so you don't need to deal with MMO scale networking for this type of game).

What you should do is have one master server for the "lobby" and then run multiple game servers, They can but doesn't have to be on the same machine but needs different ports and should be handled by their own instance of the server application.

Have the master server keep track of how many instances of the game server each node is running and launch new ones as needed on the least busy node, (You can have game servers report their nodes status to the master server for this purpose)

For the game servers 1 or 2 threads are enough, (having one thread that only waits for new connections and one that runs the game can simplify things slightly)
[/quote]

I'm not sure if I understand your post. Do you mean that rather than spawning a new thread per client connected, I run some kind of game server node for handle the new client connected ? Or do you mean these game server nodes should be able to handle more than one client ? Because that is what really I was wondering. I can't figure out a way for handling multiple clients without spawning a new thread for each connection.
Maybe I'm a little bad for these things [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] also thank you very much for your answer too!

Regards.
[/quote]

You'll most likely have multiple nodes, each node runs a number of game servers, (each game server hosts 1 game with X players), the game server should have 1 thread for all clients, possibly 2 if you want to use blocking sockets (not really recommended), If you're allowing players to create games themselves you'll have the master server tell the least populated node to launch a new game server, (This can quite easily be done using ssh) before directing the player to it, if players can't create games then you just launch new game servers when the currently running ones are full).

as for the game server handling multiple connections its fairly easy.
loop through the connections and deal with them one at the time. use non blocking sockets to avoid having reads and writes stall the application. (If you use blocking sockets you have to be very careful and always check how much data you can attempt to read before you try to read it and you can't ever write more data than what you can fit in the sockets output buffer)

When reading data you should take all the data that is currently on the socket and place it in your own buffer, extract any complete "packets" from it and handle those, save any data belonging to incomplete packets in the buffer (The next time you read from the same socket you'll get the rest of it.

When writing data you have to do the opposite, keep your own buffer of data to be sent, try to write it all to the socket, check the return value from the write function (it indicates how many bytes was actually written) and remove that number of bytes from your buffer then move on to the next socket in the list.
The important thing is to never stop to wait for a socket.

If your server runs at a fairly low update rate you can increase the size of the recieve buffer using the setRecieveBufferSize method (allthough its only a hint to the underlying implementation, if you have a problem with it filling up and can't increase it enough you might benefit by moving the socket reads to their own thread to get data to your own buffers faster. (Your own buffers aren't limited in size by the platform in the same way) but usually its not necessary (a game shouldn't generate that much data on a single socket) Edited by SimonForsman

Share this post


Link to post
Share on other sites
Standard non-NIO sockets do not have a non-blocking write (OutputStream may block). Only workaround here is a thread pool, which can, in worst case, grow to same size as number of sockets.

That alone makes it intractable.

They also lack select()-like timeout functionality, so they must be constantly polled for both, read and write.

NIO has its own warts, but manages to workaround these limitations. NIO is mostly integrated in old interfaces these days, so it's slightly easier to use, at least for basic functionality.

Share this post


Link to post
Share on other sites

This topic is 2051 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this