A socket close operation doesn't always send an event

[bogdanm]

The event function in TCPSocket increments the internal _pending variable and doesn't send an event if the value of _pending s not 1: https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/TCPSocket.cpp#L166

However, it seems that only send and recv set the value of that variable to 0. This means that events will be fired for send and receive operations, but not for close operations (https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/Socket.cpp#L66) unless _pending happens to be 0.

Is this a bug or I'm not using socket events properly?

@marcuschangarm

[0xc0170]

cc @geky @kjbracey-arm

[bogdanm]

Meanwhile I read a bit more on the subject, for example https://stackoverflow.com/questions/6418277/how-to-close-a-non-blocking-socket. It might be that close shouldn't actually send an event at all?

[geky]

I think it should be noted that the event from the close function isn't for a user waiting for the socket to close, but for anyone waiting to recv or send data. With this in mind, it makes sense to me that the close function generates an event if there is a pending recv or send. I believe this is still consistent with the SIGIO signal in posix sockets.

As an optimization, the socket events are coalesced and only occur once between operations on the socket (a6edc26). If a pending recv/send hasn't been checked, no other events are sent, including the close event. Losing the close event shouldn't impact the socket usage since the information would be picked up when the user gets around to checking the state through recv/send.

[kjbracey]

At present I would think you logically can't get an asynchronous event after the close, because it immediately retires the descriptor, so there's no handle to associate any event with. The close as currently coded is a non-blocking synchronous operation. But it should wake anything blocking on other threads as it closes.

There is a more general issue here of "how do I tell all the TCP data has been successfully sent when running non-blocking?" The standard BSD sockets API is kind of flawed here, in that there is no portable mechanism to tell when any given TCP send has been acked (as the TCP spec specified) - send() and recv() only tell you about local queue state - the only way to confirm everything was sent is that close() blocks until everything is acked or the connection fails, and you get a success/error indication. That doesn't work for non-blocking close() though.

And as the netsocket API is currently coded, a blocking close just closes immediately anyway. There's no "wait for TCP to finish" mechanism to the network stack. Depending on the stack implementation, at best, the data will still keep trying to go, but you won't find out if it finished. At worst, it will abort the connection and flush the write queue.

It feels like there should be some support for blocking close, maybe. (And the implementation of that might lead to some sort of asynchronous TCP close success/failure notification?)

Mind you, even successful ack doesn't necessarily mean the other application read it. Clean TCP shutdown is hard. Usually protocols end up relying on data-layer handshake rather than the TCP handshakes. So maybe it's not worth worrying about.

But a minimum, I think we should specify that the close() request to the network stack shouldn't abort and flush the write queue, so the simple blocking sequence send(), close() isn't totally broken. Do the lwIP and esp8266 implementations manage this?

[bogdanm]

Thanks for the clarifications! It's clear that I read the code wrong and close wasn't supposed to send an event in the first place, which is good news :) This should be fixed once #3374 gets merged.

[bridadan]

Closing because #3374 was merged.