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. -- http://mail.python.org/mailman/listinfo/python-list
