RE: [pygame] Re: [OLPC-Games] PyQNet project on Launchpad

["Noah Kantrowitz" <noah@xxxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-pygame-users@xxxxxxxx [mailto:owner-pygame-users@xxxxxxxx]
> On Behalf Of Casey Duncan
> Sent: Monday, July 28, 2008 4:46 PM
> To: pygame-users@xxxxxxxx
> 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