> What is a full size packet? RFC 1122 (4.2.3.4) says: > the TCP can send a full-sized segment (Eff.snd.MSS > bytes; see Section 4.2.2.6).
There is an algorithm in Section 4.2.2.6 how Eff.snd.MSS is calculated. > That is another good reason to remove the unbuffered send. So far I still think we should retain the unbuffered send. Actually the buffered send (if a non-blocking mode is not activated in the TCP socket, that is by default) is also affected by RFC 1122 from a userland side. Moreover, from a user point of view there is almost no difference between the buffered send (in blocking mode) and the unbuffered send (that can not provide non-blocking operation). As I understand, TCP_QUICKACK socket option (at least in Linux kernel 2.4.4+) can be enabled on the remote TCP receiver side that disables delayed ACK. (In case of NuttX TCP receiver the delayed ACK can be disabled if CONFIG_NET_TCP_DELAYED_ACK option is disabled.) This seems only a reliable way to prevent 0.5 second delays if TCP sender works in a blocking mode. On Thu, 2021-10-14 at 20:27 -0600, Gregory Nutt wrote: > The language in the RFC is not clear. What is a full size > packet? Is that > the MSS which could potentially vary from segment to segment > depending on > the sizes of the headers. Is that the receive window size which > could also > vary? Not clear. > > I don't think there is any general way to always send an even number > of > full-size packets... whatever that means. That is another good > reason to > remove the unbuffered send. > > The algorithm came from uIP 1.0 from around 2001. Might be > interesting to > see what uIP in Contiki did with that in later years. > > More discussion here: > https://groups.google.com/g/nuttx/c/bh01LHix7nM/m/bL8242BQCwAJ Johnn > y is a > pretty knowledgeable guy a references a couple of other RFCs there.
