The WSAAsyncSelect system is driving me crazy!! I debugged my program so deeply and the bug MUST be in winsock somewhere (but I sure hope not). Here's what happens: A connection between the client and server is established. Then there is communication fine for some time. Here are the symptoms of the weird problems: 1) Usually it starts after some time when both client and server don't send each other any data, it's like there is a timeout even though they ARE connected!! 2) Sometimes the client or the serves get a FD_CLOSE message indicating the other side had closed the connection but nope, he didn't. From that point nobody gets the data that the other sends. 3) It usually happens when there is slow connection (other programs use the internet in a big amount). 4) at some point (mentioned at number 1) nobody gets the data that the other sends (even though nobody gets an error in sending the data), and this happens not only after false FD_CLOSE message like I said in number 2. Oh and it couldn't be that the data DID arrive to the other side but somehow the program ignored it, because I checked it and even the network event notification doesn't arrive, it's like at some point they just disconnect from eachother with no reason. 5) When the client sent to the server some data and no network notification arrived, I put a breakpoint in the window message loop of the server and just called recv (to check if maybe the data DID arrive and for some reason no network notification arrived to the window proc) and it returned -1 with error set as WSAEWOULDBLOCK. Oh and I don't know if it is correct to do the following but I did: I used sereval calls to recv inside a single FD_READ message, is it right? and if not, could THAT lead to all the problems mentioned??? Please solve the problem, I MUST make that program work well!!

ok now THIS is too weird:
I found a function called setsockopt and i saw 2 usefull things for me in there:
first is the TCP_NODELAY option: if i wan't the messages to be sent immediately without no "nagel algorithm" what params should I give the function?
second is the SO_KEEPALIVE which i guess makes the connection not to self close if both client and server sides are idle for some time (which is how much by the way?), what params do I need to give to setsockopt to make this option work?
I tried some posibilities and nothing works...
oh and: on the server side, should i call this function on the accepted socket or on the listening socket? and if on the listening then before or after bind?

Quote:Original post by UriKiller
Oh and I don't know if it is correct to do the following but I did:
I used sereval calls to recv inside a single FD_READ message, is it right? and if not, could THAT lead to all the problems mentioned???

I wouldn't recommend this. I can't give you any hard facts on the problems it could cause, but FD_READ is posted once for a) new data arriving b) a recv() call that didn't collect all the data. This could very easily lead to FD_READs being posted when there is no data to collect.

EDIT: I'm not thinking clearly; the last part of my post didn't make any sense, but the gist of it is: try only calling recv() once per FD_READ [grin]

ok but what about the keepalive stuff? how to make the connection not to close after some idle time?

You should precise which underlying protocol you're using, if the two machines are on the same network, or the packets going through internet. You should also double check with others computer if it isn't a hardware problem/misconfiguration.

You told to us: the bug is hard to find. It will be even harder for us to track it if we don't have enough information.

I had the the exact same problem on my java client/server. I just put a thing on my client to send a small message every 30 seconds to the server, because for some odd reason if I put the server on another computer I would get a timeout every 1 minute or so.

But there is a proper way to make it not timeout every minute, and I don't succeeded and using that way (which is setsockpot ()).
I am using asynchronus sockets of tcp/ip (IPPROTO_TCP), SOCK_STREAM. AF_INET.
for some reason the timeout doesn't happen on LAN.