Your networking model sounds similar to mine - synchronization of actor properties using thread safe messages by using the network connection as a message relay. I'm currently using both TCP and UDP for communication. Individual properties are marked as either 'critical' or not along with a priority. critical, low priority messages through TCP (game state control, player chat etc) non-critical, high priority messages through UDP (rotation/heading without projectiles) and a blend between them for all other things. You can do packet confirmation on critical messages sent thru UDP for both speed and reliabilty but not bother with confirmation for things that don't really matter or would otherwise quickly get superseded.
For example for the position of a player, you can send one critical update to the position each second and inbetween those as many non-critical updates as the bandwidth allows for. So you could theoretically only get the critical update each second. Then you can use prediction combined with lerping like Quake3 net code etc to make the motion seem smooth for other players.
The nice thing about this is that marking a packet as non-critical / low-priority allows you to dump it or move it down the queue when a new critical/high-priority message comes in for sending. It's a total win to implement as theoretically your stream of messages could suffer such disruption anyway over UDP, all you're doing is juggling to squeeze out the real-time performance factor.
accurate timing sync + timestamps are critical for the setup, I recommend that you make timestamps an inherent part of your message structure. I connect my server messenger to my client messenger internally without networking and introduce artificial delays to the pumping of the queues and random message drops in order to simulate something approaching an unreliable internet connection. If you do this then your net code is no longer important, you can do the hard part of dealing with sync/delay in your own ecosystem and when it's done, just stream your messages through whatever TCP/UDP you fancy and job done.
To put simply, the networking code in this context becomes a message relay with a fast,unreliable path and a slower,reliable path. You could just use UDP and have a system for re-transmitting lost packets, and re-ordering them and while this can be faster than TCP in some scenarios, that is the fundamental difference between the two, TCP is basically UDP with packet re-transmission and re-ordering. There's no performance hit at all to using both TCP/UDP and the TCP path means any UDP packet reliabilty code can be non-existant or just very simple.
Reply With Quote
Bookmarks