Question

A have a application with two threads. Its a network controlled game,

1. thread (Server)

• Accept socket connections and receive messages
• When message is sent, create an event and add it to the queue

Code:

class SingleTCPHandler(SocketServer.StreamRequestHandler):
    def handle(self):
        try:
            while True:
                sleep(0.06)
                message = self.rfile.readline().strip()              
                my_event = pygame.event.Event(USEREVENT, {'control':message})
                print message
                pygame.event.post(my_event)

2. thread (pygame)

• In charge of game rendering
• Receives messages via event queue which Server populates
• Renders the game based on messages every 60ms

This is how the game looks. The control messages are just speeds for the little square.

For the purpose of debug i connect to the server from a virtual machine with:

ncat 192.168.56.1 2000

And then send control messages. In production, these messages will be sent every 50ms by an Android device.

The problem

In my debug environment, i manually type messages with a period of a few seconds. During the time i don’t type anything the game gets rendered many times. What happens is that the message (in server code) is constantly rendered with the previously received value.

I send the following:

1:0.5

On the console where the app is started i receive the following due to line print message in Server code:

alan@alan ~/.../py $ python main.py 
1:0.5

What the game does is it acts as it is constantly (with the period it renders, and not every few seconds as i type) receiving this value.

SInce that is happenig i would expect that the print message which is in while True also outputs constantly and that the output is:

alan@alan ~/.../py $ python main.py 
1:0.5
1:0.5
1:0.5
1:0.5
....

However that is not the case. Please advise (I’m also open for proposals to what to change the subject to if it isn’t explanatory enough)

Answer 1

Your while True loop is polling the socket, which is only going to get messages when they are sent; it has no idea or care what the downstream event consumer is doing with those messages, it is just going to dispatch an event for and print the contents of the next record on the socket queue every .6 seconds. If you want the game to print the current command every render loop, you’ll have to put the print statement in the render loop itself, not in the socket poller. Also, since you seem to want to have the last command “stick” and not post a new event unless the user actually inputs something, you might want to put an if message: block around the event dispatch code in the socket handler you have here. Right now, you’ll send an empty event every .6 seconds if the user hasn’t provided you any input since the last time you checked.

I also don’t think it’s probably advisable to put a sleep, or the loop you have for that matter, in your socket handler. The SocketServer is going to be calling it every time you receive data on the socket, so that loop is effectively being done for you, and all doing it here is going to do is open you up to overflowing the buffer, I think. If you want to control how often you post events to pygame, you probably want to do that by either blocking events of a certain type from being added if there is already 1 queued, or by grabbing all events of a given type from the queue each game loop and then just ignoring all but the first or last one. You could also control it by checking in the handler if it has been some amount of time since the last event was posted, but then you have to make sure the event consumer is capable of handling an event queue with multiple events waiting on it, and does the appropriate queue flushing when needed.

Edit:

Docs:

The difference is that the readline() call in the second handler will call recv() multiple times until it encounters a newline character, while the single recv() call in the first handler will just return what has been sent from the client in one sendall() call.

So yes, reading the whole line is guaranteed. In fact, I don’t think the try is necessary either, since this won’t even be called unless there is input to handle.