Who needs UDP?

[sunsett]

@blahblahblahh

Sorry. IMHO, though, its still just plain foolish to be sending redundant data down a TCP stream - it’s artificially increasing your latency, and how many of us work on platforms where there is so little RAM and CPU at either end that we can’t afford to buffer and remove outgoing duplicate messages?

I agree…the RealtimeMessage in JGN 2.0 is handled in both incoming and outgoing queues in order to remove duplicate messages in the outgoing queue so multiple redundant messages don’t get sent, and in situations where multiple messages do get received before the remote machine can process them the extras are also discarded. This puts it off on the developer to handle good synchronization.

If they don’t want jumps in the graphical positioning they need to implement functionality to animate them from their current position to the new position, I think it’s a bad idea to try to handle that in the networking.

UDP is definitely the place where this gives the most benefit, but it also has a place in TCP I believe. Say for example I have two players in an first-person shooter that are connected to a server and sending packets to the server announcing their position in-game. The server validates that information and passes it on to the other players. There is a big possibility of lag spikes on TCP that would cause a bunch of synchronization messages for the same player to be received at once on the client or server. It would be a waste of time and a bottleneck to process all of these messages (and slows down the process of getting back in sync after a lag spike). If I instead disregard all the old ones and take only the most recent I’m back on track without any problems. I do agree that you don’t want the whole issue of players bouncing around the screen in a lag spike though, so you may want to inject a positional synchronization system to take their current position and gradually adjust them to the new position to get back into sync, but that’s outside the scope of this discussion.

To get back to the main topic of this discussion, with positional synchronization I think UDP has major advantages over TCP as you don’t have guaranteed delivery, so if you stop receiving synchronization messages for a minute and then just receive a few at once you can simply grab the newest and disregard the rest. In that case you aren’t even having to process the hundred of messages that were sent, but only those that were able to be received after the connection fault which is going to be the newer information anyway.

[blahblahblahh]

@sunsett

There is a big possibility of lag spikes on TCP that would cause a bunch of synchronization messages for the same player to be received at once on the client or server. It would be a waste of time and a bottleneck to process all of these messages (and slows down the process of getting back in sync after a lag spike). If I instead disregard all the old ones and take only the most recent I’m back on track without any problems.

I still don’t get this - when has this ever been a bottleneck? We’re talking about a gigahertz processor dealing with message frequencies in the 0.01Hz to 0.1 Hz range - the processor will do literally several hundred million things in the time frame individual message are arriving.

IMHO, you are gaining nothing significant to try and be clever about your TCP queue, whilst you are losing a lot that is very significant by not running over an out-of-order protocol.

FWIW, I completely guess that the reason people get away with TCP is simply that POTS-based DSL lines are very predictable, and such high bandwidth that even background email sends, site surfing, daemon updates etc don’t impact the game traffic.