Marc Lehmann wrote: >> That contradicts this: >> >> http://www.gnu.org/s/libc/manual/html_node/Closing-a-Socket.html#Closing-a-Socket >> >> Specifically the bit that says "Stop trying to transmit data from this >> socket. Discard any data waiting to be sent.". > > You surely mean the bit saying "If there is still data waiting to be > transmitted over the connection, normally close tries to complete this > transmission." :) > > You quote from the wrong part of that page, namely shutdown. That has > obviously no relevance to close.
Quoting from my original message: "If I call shutdown()/close() immediately after the write()..." I am calling shutdown before close, thus the reference to the behaviour of shutdown. > Besides, nothing is said about blockign vs. non-blocking. If you think > a while you will realise that it doesn't matter whether the socket was > blocking or not, as the write behaviour is exactly the same when you write > any data. I have thought for a very long while on this, and the behaviour is very different. In the blocking case, the write will only return when the write is complete. In the non-blocking case, the write returns immediately, giving you the option to run shutdown()/close() immediately, which in this case is causing data to be discarded. As it turns out, setting SO_LINGER explicitly seems to have solved this on MacOSX at least. Not tried Linux yet, that's next. > There isn't any such event, and you do not use it. Design your protocol to > send an acknowledgment and wait for it, then close the socket. > > It's really simple. > > what you described does _not_ include an acknowledgment - what you > described is simply closing the socket after sending data, you do not wait > for an ack. > > Design your protocol that way and your problem will be gone. When you say "ack", an ack from what layer? If I expect the other side to send me a message saying "I ack your goodbye, goodbye", all I've done is turned the problem around, and now the other side is writing "goodbye", followed by "shutdown/close", with data loss on the other side. Existing protocols like HTTP don't wait for an ack, how do they do it? Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
