Re: [GNUnet-developers] p2p 'massively multi-player games (MMGs)'

[Christian Grothoff]

On Friday 23 March 2007 16:30, donnar wrote:
> Hi Marcos,
>
> there is currently a discussion on the TORCS-devel list if it is possible
> to use Croquet or something else for a low latency game:
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=31887625&forum_id=37
>74
>
> <quote>
>
> "The implementation which I plan has different sort of messages, but just
> the very frequent car updates are interesting in terms of performance, I
> need at least:
>  - Player Identification (you need to know to who the following data
> belongs) (1 byte)
>  - The car position in space (max 12 bytes).
>  - The car orientation in space (max 12 bytes).
>  - The car velocity in space (for inter/extrapolation) (max 12 bytes).
>  - The steer angle (for proper graphics and interpolation) (max 4 bytes).
>  - The engine rpm for proper sound (max 4 bytes).
>  - Vertical wheel position relative to the car body (max 16 bytes).
>  - The ping (2 bytes)
>  - Maybe I missed something
>
>  So for the first shot I think between 30 and 100 bytes (without TCP packet
>  header etc.).
>
>  >> I don't think Croquet would fit with TORCS. TORCS
>  >> really just needs a simple UDP base network library.
>
>  Wrong, for internet play you cannot use UDP, you can not pass any
> realistic infrastructure with this. My implementation will rely on TCP,
> like most commercial games on this genre.
>
> </quote>
>
> Do you think it can be handled by a p2p network like GNUnet within the
> necessary response time ? Or is there only the chance to use p2p for high
> latency games, i.e. chess ?


I don't think P2P or not is the crucial question here -- how you decide to 
route messages (how many hops can you afford) is more important.  Also, using 
GNUnet in particular (may not apply to all P2P systems) will add some 
overheads (additional headers, encryption, buffering, etc.).  However, 
especially after tuning the system, network delay should dominate so that 
encryption and buffering should not matter.  Also, the headers should be 
acceptable -- either you send rarely enough that latency not total traffic is 
the bottleneck, or you can group multiple messages to reduce the header cost.

Overall, I'd say you need to first answer how you intent to organize your 
topology and do routing / discovery / join / leave etc.  Then you can check 
if GNUnet provides some of the needed functionality or how much work it would 
be to add it.

My 2 cents

Christian