Heyya, I''m working on a network game. Currently I''m using TCP and blocking sockets (with no multithreading). And now it seems that when I send or recieve my application freezes for a while. I assume this is because I''m using blocking sockets, or? So my question is, is it stupid to use blocking sockets in a fps? Will non-blocking sockets be better? Oh, and I also noticed that when reaching a certain bandwith limit latency went crazy, seems the server/client failed to recieve all packets or they got stacked up on some queue. And this started at 10KB/s, and I''m trying this by connecting to localhost (and with my friend over a 100mbit network). I''m not using multicasting or anything. I''ve tried disabling the nagle algorithm without any improvements. Thanks in advance.

Yes, the lock-up is because of the blocking sockets. Basically a socket request like send will return once it''s finished sending the data, so it takes a little while and the game will stutter. A receive call will wait until data is abailable, then receive it, thereby locking up the application for a much longer period of time if no packets are in there.

Non-Blocking (asynchronous) sockets basically send your application a message via windows messages to notify you when data arrives, so there is no waiting on the data, and similar when it sends, it notify''s you when it''s available to send (or something like that).

Blocking with threads: I would say this would probably be your best bet, as the thread can block as much as it wants and the normal app will just keep happily chugging along, also, since everything spawned from these packets will be run in this thread, it will take advantage of those extra CPU''s that some people are running .

Non-blocking != asynchronous. You can have blocking asychronous sockets or non-blocking, non-asynchronous sockets. Asynchronous sockets is a Winsock feature, while blocking/non-blocking is common to all sockets implementations.

OP: Without knowing how you''ve structured your game, I wouldn''t be able to suggest what would make your game perform best. I will say that while multi-threaded blocking sockets is remarkably easy to work with, it can actually hurt your real-time performance (depending on the costs of context switches and synchronization primitives on your operating system, as well as how you perform synchronization).

If you''re using Winsock, consider using overlapped I/O with callbacks. It''s a relatively non-invasive way to switch from blocking without changing the control paths of your application.

Heyya,
thank you for the replies.
I''m going to look into overlapped I/O. You don''t happen to have any tutorials?

I don''t know of any overlapped I/O tutorials on the web. However, Lewis Napper covered overlapped I/O in his book "Winsock 2," and the source code for most of the samples is available on his webpage ( http://www.sockaddr.com/ExampleSourceCode.html ).