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

["René Dudfield" <renesd@xxxxxxxxx>]

Hi,

here's some more stuff to consider...

http://wiki.secondlife.com/wiki/Eventlet
http://pypi.python.org/pypi/greenlet

There is a python wrapper for enet too (in the version control, part of enet).

libevent api:
http://www.monkey.org/~provos/libevent/
http://code.google.com/p/pyevent/


cheers,


On Tue, Jul 29, 2008 at 11:06 AM, René Dudfield <renesd@xxxxxxxxx> wrote:
> hello,
>
> below are a collection of notes for game networking...
>
> For the pygame 1.9+ release we would really like to get networking
> library routines in :)  Something that's simple, and has been used
> successfully in at least 2 games( 1 by the author, and 1 by someone
> else) would be nice.  Getting your library ready for ludumdare.com
> (august 8-10), and pyweek.org (sept 31st) would allow other people to
> try it out by making games.
>
>
>
>
> Channels in UDP are cool.  They allow you to separate data which cares
> about order or sequence.  Here's a description from a game UDP
> networking library...  note enet is used by the cube engine.
> http://enet.bespin.org/Features.html
>
> For udp please consider being tcp friendly...
> http://www.psc.edu/networking/projects/tcpfriendly/
>
>
> Seeing network events in the pygame event queue would simplify things
> for people. So networking then becomes like any other event.
>
> #pygame.network.send(data, channel, lossy)
> pygame.network.send("hello network.", CHANNEL_CHAT, 0)
>
> for e in pygame.event.get():
>   if e.type == NETWORK:
>       if e.what == NETWORK_DATA_IN:
>           print e.channel
>           print e.data
>           print e.sequenceid
>           print e.peer
>           if e.channel == CHANNEL_CHAT:
>               # we write the incomming text to our chat window.
>               chatwindow.write_text(e.peer, e.data)
>
>
>
>
> OSC is an important consideration too. OSC is the new midi.  It's a
> pretty good UDP based protocol for real time use. It's widely used in
> the music world as a networked replacement for midi, and a little bit
> in the game world.
>
> http://en.wikipedia.org/wiki/OpenSound_Control
>
> It does things quite well for real time use. Things like bundling
> messages together. So if you send a bunch of messages they can be
> played back in time. This is obviously very useful for music, but also
> for games... where timing is important for many games.
>
> This idea from OSC(bundling timed events) can be used to replay events
> with the same time that they appeared in one machine on another
> machine.  However OSC can be implemented separately if needed(and has
> already been made
> http://www.ixi-audio.net/content/body_backyard_python.html ).
>
>
> Another thing to consider is sending video data.  Video data can be
> quite large :)  Especially when you get into the 10gbit area.
>
>
> Here's a discussion on quake 3 networking...
> http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
>
> Noah code:
> https://coderanger.net/svn/school/2007/fall/egd/magnoball/pygamenet.py
>
> Simon Wittabers twisted implementation of simple networking.
> http://code.google.com/p/pygnet/
>
> Notes from 2006 pre-gsoc about simple networking for pygame.
> http://wiki.python.org/moin/SummerOfCode/PythonLibraries/SimpleNetworkingForPygame
>
> Concurrent programming using an actor component based model.  (note
> the website is ancient... but there is actually an active community
> there with 5 or gsoc students)
> http://kamaelia.sourceforge.net/Home
> http://yeoldeclue.com/cgi-bin/blog/blog.cgi  (this blog by the author
> has more current info on it)
>
> sjbrowns networking tutorial using twisted:
> http://sjbrown.ezide.com/games/writing-games.html
>
> raknet is one of the top game networking libraries... written in C++
> Good to look at for features, and ways they do things.
> http://www.jenkinssoftware.com/
>
> http://www.pygame.org/tags/network
> http://www.pygame.org/tags/multiplayer
>
>
> Tunneling over http, and using serial ports is something else to
> consider :)  As is communication via camera(in) and video(out) screen
> ;)
>
>
>
> anyway... just some notes for reading.
>
>
> cu,
>
>
>
> On Tue, Jul 29, 2008 at 9:55 AM, Noah Kantrowitz <noah@xxxxxxxxxxxxxx> wrote:
>>> -----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
>>
>>
>