> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Casey Duncan > Sent: Monday, July 28, 2008 4:46 PM > To: pygame-users@seul.org > Cc: 'Games for the OLPC' > Subject: Re: [pygame] Re: [OLPC-Games] PyQNet project on Launchpad > > On Jul 28, 2008, at 4:49 PM, Noah Kantrowitz wrote: > >>> [..] > >> https://coderanger.net/svn/school/2007/fall/egd/magnoball/ > >> pygamenet.py > >>> . Also a WiP. > >> PyQNet is split over 8 modules, but the actual number of code-lines > >> in > >> the library (excluding the tests) is pretty small (640 incl. > comments > >> and docstrings), pygamenet is around 591 when you take out the > >> comments. Though PyQNet is likely to grow substantially once I get > >> all > >> the features I want implemented. > >> > >> The difference in size currently is likely because PyQNet is > >> implemented > >> as UDP with ordering and retry controlled by the Python code > >> instead of > >> using TCP-level operations. The UDP operations should allow us to > >> code > >> adaptations into the library to optimize for low-latency game-y > >> operation. > > > > This is a common misconception. The reason to use UDP is not for low- > > latency > > (just set TCP_NODELAY), but to accommodate lossy links. Generally > > this means > > dealing with either bad connections or high congestion. And when I > > say "deal > > with" I mean "detect and die", not just reimplementing > > retransmission on top > > of UDP. As it stands there is no real reason to use UDP for games > > anymore > > unless you really think the vast majority of your users will be on > bad > > connections. I don't think this is the case, even for OLPC (sat > > links are > > slow, but generally not lossy). > > TCP has many semantics that can be undesirable for some games, in > particular "guaranteed delivery" regardless of effective time of > transmission. In many real-time applications (FPS games come to mind), > state data becomes out of date very quickly, thus if the transmission > cannot be completed in a particular time window, it is better not to > receive the data at all. In these games the state updates can become > roughly like a stream.
In any game network protocol I have ever seen, this is simply not true. For example, position is generally not sent as an absolute, but as difference. Aside from periodic resyncs, the moment-to-moment updates generally all do need to be received. > UDP has a lower overhead than TCP, making it advantageous for sending > streaming data where intermittent loss is preferable to indeterminate > data lag. The overheard will be lower than implementing a similar system yourself in UDP. Also dynamic window sizing means that the overhead is generally too small to speak of. --Noah
