Problem with winsock2.0
-
I'm having a couple of little problems with a listening socket connection. I've worked with winsock before but that was a long time ago. Essentially this is the procedure. App-A is the sender, App-B is the receiver. App-B is running constantly listening for a connection. App-A(which is not always running) connects to App-B when required and sends a message, and closes the connection afterwards. The problem I'm having is this. if App-A executes too quickly, App-B gets an WSAECONNRESET error on calling "recv" I can get around this by slowing App-A down with for loops/sleep commands and other such hacks, but would prefer not to do this. The other problem I get is if App-A abnormally terminates, App-B sits in a loop constantly receiving the last message sent by App-A. This isn't a large concern as I'm deliberately causing App-A to fail as a stress test which is unlikely to occur. I'm guessing either App-A needs to wait and ensure the message has been received before closing down, or App-B needs to queue messages somehow. Any tips?
When I die I'd like to go peacefully in my sleep like my father, not screaming in terror like his passengers!!!
-
I'm having a couple of little problems with a listening socket connection. I've worked with winsock before but that was a long time ago. Essentially this is the procedure. App-A is the sender, App-B is the receiver. App-B is running constantly listening for a connection. App-A(which is not always running) connects to App-B when required and sends a message, and closes the connection afterwards. The problem I'm having is this. if App-A executes too quickly, App-B gets an WSAECONNRESET error on calling "recv" I can get around this by slowing App-A down with for loops/sleep commands and other such hacks, but would prefer not to do this. The other problem I get is if App-A abnormally terminates, App-B sits in a loop constantly receiving the last message sent by App-A. This isn't a large concern as I'm deliberately causing App-A to fail as a stress test which is unlikely to occur. I'm guessing either App-A needs to wait and ensure the message has been received before closing down, or App-B needs to queue messages somehow. Any tips?
When I die I'd like to go peacefully in my sleep like my father, not screaming in terror like his passengers!!!
Hi, are you using multiple sends and recv(s) ? My idea is that use single send(send whole data) and do multiple recv() fn. Once recv fn gets all bytes of data, send a single ACK to server. Thereafter you can close your server socket connection. Bye.
Nice things do nice works
-
Hi, are you using multiple sends and recv(s) ? My idea is that use single send(send whole data) and do multiple recv() fn. Once recv fn gets all bytes of data, send a single ACK to server. Thereafter you can close your server socket connection. Bye.
Nice things do nice works
Thanks for the help, but I've figured it out, and the answer simply foolish :wtf:. I wasn't closing the connection correctly, hence the lack of buffer flushing As for the repeat message, it wasn't repeating. The message was being stored in a buffer with a static pointer, and because I neglected to check the data size returned from recv I was assuming the data pointed to was the latest message, but recv was in fact returning 0.
When I die I'd like to go peacefully in my sleep like my father, not screaming in terror like his passengers!!!