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

[Casey Duncan]

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