2-player game, client and server at localhost

[Christopher Subich]

Michael Rybak wrote:
> CS> There's the key.  How are you processing network input, specifically 
> CS> retrieving it from the socket?
> 
> A "sock" class has a socket with 0.00001 timeout, and every time I
> want anything, I call it's read_command() method until it returns
> anything. read_command() and send_command() transfer user's actions in
> special format so that it takes 10 bytes per transfer.

So when you want player input, you explicitly halt the program until you 
receive it, inside a while loop?  No wonder your programs aren't 
behaving well, then.

Network processing Is Not Slow.  Unless you're sending near the maximum 
capacity of your line, which you're obviously not[1], the slowness is 
architectural.

[1] - The TCP packet contains at most 28 bytes of overhead, so combine 
that with 10 bytes of data and you're looking at 38 bytes/packet.  A 
33.6 modem can handle 4.2kB/sec, cut that in half for a safety margin 
for 2.1kB/sec.  That will handle about 55 updates/second, which you 
shouldn't be reaching if you're "just sending updates when a player does 
something."

Why are you messing with sockets directly, to begin with?  It looks like 
you want an asynchronous socket interface, so that you don't explicitly 
loop and wait for data from the nyetwork for updates.

In addition to making Julienne fries, Twisted is an excellent framework 
for asynchronous network IO.  For a naive, non-threaded implementation, 
you'd schedule your update code as a timed event, and you'd define a 
Protocol for handling your network stuff.  When you receive data, the 
protocl would update your application's state, and that would be picked 
up automagically the next time your update event ran.

In a threaded implementation, you'd run your update code to a thread 
(DeferToThread), and your network code would post updates to a 
synchronous queue, read by your update code.