Differences between revisions 2 and 3
Revision 2 as of 2006-05-07 16:39:22
Size: 2761
Editor: 63-162-81-9
Comment:
Revision 3 as of 2006-05-08 04:56:14
Size: 2879
Editor: d220-238-73-98
Comment:
Deletions are marked like this. Additions are marked like this.
Line 35: Line 35:
pygame.events.post(e)
events = pygame.events.get()
Line 38: Line 36:
for e in events:
    if e.type == NET:
        if e.what == NET_DATA_IN:
            print e.channel
            print e.data
        if e.what == NET_CONNECT:
            print e.ip
            print e.port
            print e.sequence_id
            print e.channel
            pass
#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)

Simple Networking For Pygame

Write a simple network library which integrates with the pygame event queue.

Basic requirements:

  • Seamless reconnection
  • Support TCP and UDP
  • use select based non blocking IO
  • network library is iterated manually (so we use our own event loops)

Potential API:

  • connect(uri, onConnection, onLostConnection)
  • send(conn, data)
  • recv(conn, num_bytes)
  • listen(uri, onConnection, onLostConnection)
  • poll()

Things not to worry about:

  • Object serialization

NOTES, api part 2?

I think I like the url idea. We could not worry about connections at all by using urls. Optional carring about connections could be implmented.

Two or three example games should be implemented to test the API. Something turnbased. Something with lots of action. Something with lots of connections (eg > 100 players).

UDP and ENet are interesting things to consider for the api. UDP is connectionless.

All bits of data could be strings. Serialisation should be done outside of it... however perhaps we can add a safe basic serialisation so that people don't use pickle.

The event queue api could event be used for some of it.

#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)

COMMENT

The pygame queue integrated networking library is a great idea.

I would suggest supporting client-to-client (peer-to-peer) networking, and adding functionality to find other networked machines running the same application.

Using 'connection-less' http and urls introduced some limitations: How does the server initiate contact with the client (assuming it keeps track of clients)? It could use http, but firewalls on many workstations/play-stations/LANs block incoming http requests.

Creating and maintaining connections would make the library more generally useful, I think, than using independent one-transaction connections like http. It would allow asynchronous notifications both ways, and would allow peer-to-peer networking.

http://pitchersduel.iuplog.com/default.asp?item=89521 A very rough proposal on simple networking in python/pygame

dkeeney

Proposal

I'm interested in taking on this project, and I've started to write up my ideas on my website. Please take a look and let me know what you think.

http://www.mumstudents.org/~bda/soc/NetworkingForPygame.html First draft of my proposal

Bryce Allen

SummerOfCode/PythonLibraries/SimpleNetworkingForPygame (last edited 2008-11-15 14:00:58 by localhost)

Unable to edit the page? See the FrontPage for instructions.