Calling close() on a non blocking socket from within an io watcher
minfrin at sharp.fm
Sat Aug 8 16:01:01 CEST 2009
Marc Lehmann wrote:
>> That contradicts this:
>> 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
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
More information about the libev