[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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.
UDP has a lower overhead than TCP, making it advantageous for sending streaming data where intermittent loss is preferable to indeterminate data lag.
That said, using TCP is more user-friendly and "intuitive" as it has a higher level of abstraction as a protocol. But the trade-off -- as is always the case with abstraction -- is less direct control. 

-Casey