Socket advice needed

[vbrozik (Václav Brožík)]

@cameron

shutdown closes one side of the bidirectional TCP communication. In
the OP’s case, the sending side. All the sent data will arrive, and the
receiver will then see EOF on the dtaa stream.

Thank you for confirming that. Some information I have found gave me uncertainty of what exactly it does.
So shutdown() just initiates sending the FIN flag, closing the sending direction of the TCP connection. The shutdown() call also allows closing the receiving direction. I am not sure if this applies to TCP (not sure how it should behave after that).

In case of unidirectional communication (the receiver does not send anything back) we do not need to wait for any reaction after we sent all the data, then I guess there is no point in using shutdown() and we can use close() directly, right? …but maybe we are giving up an option to be notified about a communication failure at the end of the communication? Does close() block till last ACKs?

@barry-scott

The Nagel algorithm delays sending packets

Yes, but Nagle’s algorithm is mainly important when you are repeatedly sending short data (shorter than the maximum segment size). Though, if I am not mistaken, Nagle’s algorithm is able combine a last part of bulk data (which was not enough to fill a new TCP segment) with the first part of the following bulk data. So it will delay (and buffer) the last (incomplete) segment of bulk data.

[barry-scott]

@vbrozik

Yes, but Nagle’s algorithm is mainly important when you are repeatedly sending short data (shorter than the maximum segment size). Though, if I am not mistaken, Nagle’s algorithm is able combine a last part of bulk data (which was not enough to fill a new TCP segment) with the first part of the following bulk data. So it will delay (and buffer) the last (incomplete) segment of bulk data.

It also comes into play on the last part of the block of data you send.
So if you send 10,000 bytes it will fill lots of packets and they will be
sent, but the last bit left over will wait just in case you send some more.
This may not matter in your app. But given you want a way to flush it
seems that this does matter to you.

[cameron (Cameron Simpson)]

By Barry Scott via Discussions on Python.org at 09Aug2022 17:46:

@vbrozik

Yes, but Nagle’s algorithm is mainly important when you are repeatedly sending short data (shorter than the maximum segment size). Though, if I am not mistaken, Nagle’s algorithm is able combine a last part of bulk data (which was not enough to fill a new TCP segment) with the first part of the following bulk data. So it will delay (and buffer) the last (incomplete) segment of bulk data.

It also comes into play on the last part of the block of data you send.
So if you send 10,000 bytes it will fill lots of packets and they will be
sent, but the last bit left over will wait just in case you send some more.

Only briefly, surely. I was pretty sure that Nagle waited
opportunisticly for some more data but with a finite (and short) wait,
so that your data would go out deterministicly (in that it will be
received by the receiver without further intervention) just not quite
immediately.

This may not matter in your app. But given you want a way to flush it
seems that this does matter to you.

I believe Václav is concerned with causality - that the data arrive
without needing further action - and less so with “instant delivery”. An
argument I’ve had with Amazon (and been ignored): I don’t need this
thing delivered as fast as possible, but I want it delivered reliably.

Cheers,
Cameron Simpson cs@cskk.id.au