Hi all, we are currently trying to write a multiplayer RPG (geez, how unique!) and have a question / problem concerning our network code... First off, i know u will tell me to move from TCP to UDP. Okay, fine, we might do that. But we would like to have this issue solved, even if it is for general curiousity (and compensating our lack of experience in network coding). We are using nonblocking sockets and have realized that if we sent data (we are deactivating the nagle algo and setting the send buffer to zero like its proposed in the microsoft article http://support.microsoft.com/support/kb/articles/Q214/3/97.ASP?LN=EN-US&SD=msdn&FR=0 ) and the socket is busy, we receive a WSAEWOULDBLOCK message and our data is not queued or resent automatically (maybe due to setting the send buffer to zero, but please read on). The question is, what is the general handling for an application to deal with WSAEWOULDBLOCK ? Do you have to take care yourself of resending the data when the socket is free to send data again ? Or is it just our fault cause we set the send buffer to zero (read above mentioned article for details, and why we did this) ? i would really appreciate any comments on this issue... thanks, Icedragon. PS: we are coding this in 32-bit assembly just if you are curious...

retry until it doesn't block.

I think threading & blocking is more efficent, because you don't have to poll to send a packet (in the event of 'wsaewouldblock')


i'm not sure if changing the send buffer would solve the problem; even if it did, it wouldn't guarantee you would never get a wsaewouldblock.

...
Does a blocking send block until it receives an ack? if thats the case it really sucks! and i understand why blocking is bad.

Edited by - Magmai Kai Holmlor on November 12, 2000 8:52:22 PM

thx for your suggestion...
i think you are right, from what it looks we just have to try sending it until the send completes successfully (no WSAEWOULDBLOCK). I just found it wierd that almost no book or tutorial i read about tcp coding showed that u have to deal with it this way, but i fear this is because u dont have this kind of problems on UNIX/LINUX systems (blocking sends & receives) and the most material u get (internet and bookstore) is about BSD sockets...

Concerning your question on blocking sends:
as far as i know, the send returns when it was able to write the data in the sendbuffer. I quote this from the winsock 1.1 specification:

"Note that the successful completion of a send() does not indicate that the data was successfully delivered.
If no buffer space is available within the transport system to hold the data to be transmitted, send() will block unless the socket has been placed in a non-blocking I/O mode."

Hope i could help you a bit in return,

Icedragon.


btw. if someone is interested, our homepage is
Realms of Infinity







Edited by - IceDragon2000 on November 13, 2000 5:56:38 AM

now from what u pointed out,
i made desperate attempts to find related info on how to deal with the WSAEWOULDBLOCK event in tcp nonblocking connections. I will try to rephrase what i found and i would be glad if someone here can confirm this, or point me to the truth:

When receiving WSAEWOULDBLOCK from sends, the application will be notified with the FD_WRITE event when winsock is able to process sending again, so the application has to react on it with calling the send again.
The FD_WRITE message only occurs once at startup/connect, and then anytime a send returns the WSAEWOULDBLOCK error.

Is this correct, or did i just get it all wrong again ?

thx for any help in advance,

Icedragon.