Sign in to follow this  

Non blocking sockets in a strategy game?

This topic is 4378 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I'm new in programming with sockets. I develop a Strategy Game ( remake of Settlers 2 ) and it should be work over network too. It should be also platform-independent and so I wanted to use SDLNet. But I think it's too inflexible, because it doesn't support non-blocking sockets and the recv function wait until the full requested length is sent. For example the server expect of the client 20 Bytes and the client send only 10 Bytes and not more, so the server wait, wait and wait... So the client is able to stop the whole server, that's very dangerous, especially for the master server ( there runs the lobby ). I could use many threads, but I hate them and so I often have to kill the threads. So I decided to use Winsock. Now my first question: It's a good idea to avoid threads ( except the main thread of course [rolleyes] ) in such a game? I prefer handle all in the main loop and I think it's possible if I use non-blocking sockets? And my second: In Strategy games I send only small packets ( BTW I use TCP ). Can I count on it that I get the whole message when I receive it? If I expect a message, so I can test whether the required length (for the message) was received. And if not, I can kick the client, because he probably sent bullshit and wanted to "eliminate" my server. [rolleyes] I hope you understand all, my English is not so good. [rolleyes]

Share this post


Link to post
Share on other sites
Quote:
Original post by Carrier
So I decided to use Winsock. Now my first question: It's a good idea to avoid threads

For networking, I'd say yes. Blocking sockets aren't really suited for games.
For other areas of your game, using multiple threads *might* be worth it. If you know what you're doing, and you want to take advantage of dualcore cpu's.

Quote:
In Strategy games I send only small packets ( BTW I use TCP ). Can I count on it that I get the whole message when I receive it?

Nope.
You can't assume that you get the entire message, and you can't assume that you *only* get the message. You might get the message, and then 5 bytes of the following one. Or you might get three messages at once, or you might get half a message.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You can indeed use non-blocking sockets with SDL_net! Unfortunately, I don't remember how exactly you do it, but if you want example code I can give you tomorrow. There is a function called CheckSocket() or something that checks the socket for activity, so you can decide if you want to read it or not. And that's non-blocking.

//Kada2k6 (forgot my password and I'm not home, so sorry for anonymous post...)

Share this post


Link to post
Share on other sites
Quote:

Nope.
You can't assume that you get the entire message, and you can't assume that you *only* get the message. You might get the message, and then 5 bytes of the following one. Or you might get three messages at once, or you might get half a message.


I know but if I know that the message is 10 Bytes and I receive 10 Bytes, I can assume that I get the message ( and not 5 Bytes only of the message e.g. )? I would like to know whether such short messages are split and whether I have to receive it in many fragments.

Quote:

You can indeed use non-blocking sockets with SDL_net! Unfortunately, I don't remember how exactly you do it, but if you want example code I can give you tomorrow. There is a function called CheckSocket() or something that checks the socket for activity, so you can decide if you want to read it or not. And that's non-blocking.


Yes, I know those "Socket Sets". But they are only similar to the select - function. As I said if I receive too much data the recv block until I terminate radically the thread.

---


And if I use non-blocking sockets I dont't need the select function?

Share this post


Link to post
Share on other sites
Using TCP, any message can be split because of lost packets, re-transmission, windows sizes, MTU sizes or buffering. You have to re-constitute appropriate-size messages on the receiving side.

I recently wrote a simple message wrapper layer on top of WinSock that takes care of this problem for you (as well as some other problems). It comes with some documentation and samples. Even if you don't use the TCP socket wrapper code, it has a Buffer utility class which actually does all of the slicing of a stream into separate messages that you'll need. That code actually turns out to be a fairly complex state machine, because it has to handle things like only receiving the first byte of a two-byte message size header, etc.

If you end up using that code, please let me know whether it works, or whether you find any bugs, btw.

Share this post


Link to post
Share on other sites

This topic is 4378 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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