quote:Original post by granat
Messy ? Why ?

Non-blocking sockets are almost never necessary, and a good thing, too: their lack of performance makes them a poor architecture choice.

When a socket is set as non-blocking, every Winsock call on that socket will return immediately, whether it was able to do anything or not. This is useful because it lets your program do other things while the network is busy. The problem is, sometimes the program doesn't have anything to do. This leads to a commonly-seen construct that might be called "spin until the network becomes ready".

About the only time you should use non-blocking sockets and/or select() is when you are porting BSD sockets code to Winsock or when your code must also work under BSD sockets. In all other cases, there are better alternatives.





------
GameDev'er 4 ever.

[edited by - Khelz on June 21, 2002 9:42:39 AM]

In-effective is not the same as messy code.

If you''re running in a busy loop anyway there''s nothing wrong with using non-blocking sockets. And remember, games typically run in a busy loop (game servers are a different thing of course).

Now you could of course implement a blocking/threaded or asynchronous (win32 only) system even in the client. However, due to locking and stuff, you usually won''t be able to process incoming packets immediately anyway, so the benefits are questionable - you have to wait until rendering is finished, for example.
Now if you timestamp incoming packets by using a threaded/asynchronous system and make good use of those timestamps it may be worth it.

Personally, I use non-blocking in the client (which busy loops anyway), and blocking/non-threaded in the server (because that''s portable).

cu,
Prefect

Return to the Shadows