Sign in to follow this  
tufflax

[Python] Blocking vs non-blocking sockets

Recommended Posts

Hey! I'm working on a muliplayer (over the internet) turn based strategy game. And, I have a question: Blocking sockets + threads or non-blocking sockets? No threads is simpler, but I don't know if non-blocking sockets can be a problem. For example: What if I try to recv (receive) a message (my own game messages) and I haven't gotten all of it yet? Like if I try to recv(3) to read the header, and then try recv(something else) to read the rest of the message, and I haven't got it yet. Is that possible? Since it's a turn based game I want ALL messages to arrive safely at the other side. What I think I would do with blocking sockets is this: Have a thread reading messages all the time and put them in a queue, so that the game loop can just check if there are any complete messages ready to be handled. What I think I would do with non-blocking sockets is this: Read messages, then handle them, in a loop until I get back nothing (socket.error). I'm just worried about receiving incomplete messages, as mentioned above. Which one of these strategies is best? Or is there another one that is better? I certainly don't care about performace (speed wise). I just want simple and error free code. EDIT: I just came up with something: If it's possible to receive incomplete messages, which I guess it is (I bet I shouldn't rely on things working the way I want to), I could do this: I know the length of the message I'm about to receive, so if I've gotten part of it, I know more should come soon. So, I can try to read again and again, until I've got it all. How about that? But, maybe the threads version is not that bad? Maybe even less and prettier code? Hm... [Edited by - tufflax on January 1, 2008 12:22:34 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by tufflax
No threads is simpler, but I don't know if non-blocking sockets can be a problem. For example: What if I try to recv (receive) a message (my own game messages) and I haven't gotten all of it yet? Like if I try to recv(3) to read the header, and then try recv(something else) to read the rest of the message, and I haven't got it yet. Is that possible?

Yes. Check the return value from a call to recv; it will tell you whether the call would block or whether an existing, blocked call is in process.

Quote:
Since it's a turn based game I want ALL messages to arrive safely at the other side.

Guaranteed delivery is orthogonal to blocking or non-blocking sockets. It's a function of the data transmission protocol.

For a turn-based strategy game, go with blocking sockets and TCP (not UDP). TCP guarantees delivery, while the blocking nature of the socket should simplify your network layer.

Share this post


Link to post
Share on other sites
Thanks for your answer.

Yes, maybe I should have pointed that out: I'm going to use TCP, not UDP. But, I didn't think of the thing I wrote in my edit in the first post.

And what I meant by incompete (should have made this clearer too >_<) is that part of the messages hasn't come in YET.

But if I go with the thing in my edit in the first post, network lag would slow down the whole application.

So, threads is not a big deal, huh?

Share this post


Link to post
Share on other sites
It is required that you continue reading until you get your entire message. How you choose to go about that is up to you. If you're only dealing with 1 or 2 sockets then threads are one reasonable way to make that easier, providing you know how to write threadsafe code.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this