Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

One way to implement a client/server relationship is to have the server simulate the whole game based on the clients input and send updates back to each client, while the client is is simulating the game for the player and sending back input and game state messages that the server can use to process the whole state of the game.

My question is, since a ReceiveFrom() call blocks till it receives data and a Select() call blocks for a set period of time, does that mean all clients and servers block for a certain amount of time each frame? I am aware that a call to Select() can be set to zero which would be an effective poll to the read write states of the current sockets, but wouldn't you miss out on new data if it comes in just microseconds later? How is this problem solved now a days? Pro select() method handling? Asynchronously? Separate thread completely? Other?

I may be over thinking this, but I would like to know more information so I can write an effective client/sever relationship. -Haywire

share|improve this question
add comment

2 Answers

I am aware that a call to Select() can be set to zero which would be an effective poll to the read write states of the current sockets, but wouldn't you miss out on new data if it comes in just microseconds later?

No. When a remote computer sends you data, it first goes onto your network adapter which has its own data buffers, and from there into your operating system which again has data buffers. Reading data pulls it from the buffer - it doesn't poll data that is sitting on the wire at that precise moment (which is lucky, since the information on the wire at any instantaneous point of time can be measured in bits, not bytes, certainly not kilobytes).

The only time you can 'miss' data is if you allow the buffer to overflow, which is unlikely to happen unless you are not reading at all or you are being flooded with data. If select says there's no data, but then data comes in microseconds later, select will just tell you the next time that you call it that there is now data available.

share|improve this answer
    
That clears up many questions I had, thank you for that explanation. Do you think that handling read/write requests with select() is the way to go? –  Haywire Spark Aug 10 '12 at 23:22
    
I answered a question on a very similar issue just yesterday: gamedev.stackexchange.com/a/33964/1101 –  Kylotan Aug 10 '12 at 23:41
add comment

Whether your functions block or not, depends on the specific implementation (library/language). It is however safe to assume that the function will block at least as long as it takes to fetch/write the data.

The simplest solution is a second thread that does nothing but reading/writing. Instead of working with that data immediately, push it into a queue so it can be consumed by another thread(like your main game loop). Writing works the same way in the other direction. If the function call is blocking, call it with a small timeout, so you can switch between read/write fast and with minimal delay.

Depending on what you are doing you should really think of using TCP instead of UDP. Unless you really need the speed and a lost packet does not need to be resent, TCP is usually the better choice.

share|improve this answer
    
I know both protocols can be used effectively, but I am going for speed. Is it typical that network code be handled on a separate thread? –  Haywire Spark Aug 10 '12 at 23:19
    
@Adam Litwin: On some OSes and in some types of applications, yes. In other cases, less so. For Win32 games programming, networking is almost always handled on another thread. Please note that I can pretty much guarantee that whatever UDP code you write at your skill level is not going to be any faster than TCP. TCP works just fine in many very large commercial games; just disable Nagle. Unless you're writing the next Halo, you very likely don't need anything UDP offers. Get things working with TCP first, experiment with UDP later if you have hard evidence that you need to. –  Sean Middleditch Aug 11 '12 at 5:57
    
Ok, I'll look into the thread avenue then since I plan to do development for windows. I may not write anything faster than TCP at first, but it will be a learning experience non the less and eventually I will be able to write something better with my accrued knowledge. :) –  Haywire Spark Aug 11 '12 at 11:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.