Efficient packet transmission
by Sean H. · in Technical Issues · 01/12/2006 (11:13 am) · 5 replies
I've been studying tcp/ip protocols and programming lately. very cool stuff. but there's a few things I'm not sure about that I'm hoping some experienced network programmer could shed some light on. keep in mind here I'm talking about network programming in general, not torque related.
I'm pretty sure that most real-time games use UDP, implement some form of dead reckoning to smooth things out a bit, use packet order correcting code to ensure packets are processed in order, etc.
but how should packets be efficiently transmitted from server to client group? I'm assuming that either broadcasting or multicasting should be used. if we're operating over the internet, then that just leaves multicasting. is this the protocol that should be used for sending packets from server to client in real-time apps? or should some optimized one-to-one transmission scheme be used?
my next question is, if multicasting is used, how in the world do I check whether an address in the multicast range is currently in use? should I write code to check for this? how exactly does that work?
thanks in advance to anyone who can help me out.
I'm pretty sure that most real-time games use UDP, implement some form of dead reckoning to smooth things out a bit, use packet order correcting code to ensure packets are processed in order, etc.
but how should packets be efficiently transmitted from server to client group? I'm assuming that either broadcasting or multicasting should be used. if we're operating over the internet, then that just leaves multicasting. is this the protocol that should be used for sending packets from server to client in real-time apps? or should some optimized one-to-one transmission scheme be used?
my next question is, if multicasting is used, how in the world do I check whether an address in the multicast range is currently in use? should I write code to check for this? how exactly does that work?
thanks in advance to anyone who can help me out.
#2
01/12/2006 (11:56 am)
Thanks stephen. incidentally, I didn't even realize torque's network library went open source. looks like there's lots of good network programming tutorial material here as well.
#3
Of course, if you don't qualify, then appropriate licenses are available as well:
Indie TNL [li]Commercial TNL
01/12/2006 (12:24 pm)
Actually, TNL has been Open Source for quite a long time. Of course, it has a pretty strict license requirement (Open Source does not mean free to use anywhere!), but if you honestly qualify, it is available for specific use types.Of course, if you don't qualify, then appropriate licenses are available as well:
#4
01/12/2006 (1:21 pm)
The information there is good and all but I would still like someone to answer my original questions. apparently torque implements its own custom protocol. I would still like to know whether multicasting can or should be used for real-time applications and how to find an unused address in the multicast range. or am I just barking up the wrong tree?
#5
Also just to correct an assumption: It's also actually very rare (well, very uncommon at least) to want to have guaranteed ordered delivery for updates in a multi-player game. Forcing guaranteed ordered packets for object updates causes extreme warping, out of synch client/server states, and an extreme vulnerability to packet loss and also greatly increases the impact of high latency connections.
01/12/2006 (1:26 pm)
While on the surface it sounds as if multicasting is a decent solution, it absolutely isn't for any kind of open network (internet) game. As you observed, TNL (and Torque) uses an optimized UDP solution for 1 to 1 communications between server and client for many reasons, not the smallest of which is that it is actually extremely rare for two clients to require the exact same updates at the exact same time.Also just to correct an assumption: It's also actually very rare (well, very uncommon at least) to want to have guaranteed ordered delivery for updates in a multi-player game. Forcing guaranteed ordered packets for object updates causes extreme warping, out of synch client/server states, and an extreme vulnerability to packet loss and also greatly increases the impact of high latency connections.
Torque 3D Owner Stephen Zepp