MulticastSocket for multiplayer game

Question

I am studying the structure for my server-client communications in my multiplayer game.

I came to the conclusion that UDP is the best choice due to the "shoot and forget" way of using it that will not block the application if a packet is lost. I will also use TCP to send reliability needing packets, like during login procedures and exchange of informations like change of server, change of map, updates etc. It will also run an IRC based chat. (all the commands actually are IRC-style custom messages).

I was wondering what is the best way to send the interaction messages (moves, spells, objects, actions etc) between server and clients.

Reading some documentation I came to the MulticastSocket.

My question is:

Is better to send a continuous flow of information to all the clients starting a thread for each player (as I do in TCP communications) where each DatagramSockets will listen to a queue sending each new message to its client. This will mean that all the maps and all the movements (supposing there can be 50 players all-over the maps) will be sent to all the players, and each packet has to be larger to contain all those informations. Or is better to use a thread for each map, active only if some player are inside that specific map, using a multicast communication, sending a message to only the players that are inside that map, listening with a MulticastSocket.

I read about problems with firewall or routers using multicast, but I can't figure out what those problems can be (different from normal UDP).

The application should be used by anyone with few configuration problems.

Answer 1

Looking at your scenario above you need to decided if your application absolutely needs TCP connection as TCP connection requires one thread per TCP connection, no exceptions (unless using nio).

Now to target the UDP section of the program, you have two basic choices:

a) You spawn one thread for receiving datagram packets for all players.

In this case, all players send their datagram packets to a single receiver which then decides what to do with the data. This data may be sent to various queues for other threads for processing. Data can be sent back to all players using a single thread or multiple threads (per player).

PROS:

• Low resource usage
  
• Low program (synchronization) overhead.

CONS:

• Possible network slowness (due to masses of packets going towards the same socket)
• Higher chance of packet drop (again due to masses of packets going to the same socket)
• Serial processing
• Disconnect events are messy and hard to deal with

b) You spawn one thread per player and listen on a different port per player.

In this case, all players get their own handler threads which may process the data directly or send it to a central processing queue. By doing this, data can be processed in parallel, allowing for faster processing speeds with a higher resource usage. Synchronization will also require special attention, uses of atomics and re-entrant read/write locks may be needed. Writing back out to the socket should generally occur on another "per player thread".

PROS:

• Parallel Processing
• Modular (have all the handling code per player in one thread, start thread on player join)
• Disconnects are easier to handle and don't cause problems with other players.
• Fast network response, concurrent packet receiving.

CONS:

• High resource usage (a lot more objects)
• High synchronization overhead
• High thread count (may be as many as 2 ~ 4x threads to players ratio)

In either case, by using TCP you will need at least one thread per player. The question is are you willing to use a lot more resources for a smoother, swifter response from the server.