If you are lucky. They still may be merged by sender if retransmission occurs, or on receiving side, if receiver waits too long before reads, and this is up to OS scheduler to control.

NDELAY option is used to improve interactive latency, it will not make TCP obey message boundaries.

On Wed, Jul 13, 2016 at 11:43 AM Baojun Wang <wangbj@gmail.com> wrote:

Suppose TCP_NODELAY sock opt can prevent Nagle join small packets?

On Wed, Jul 13, 2016 at 11:10 AM Andrey Sverdlichenko <blaze@ruddy.ru> wrote:
On Wed, Jul 13, 2016 at 3:14 AM Ruben Astudillo <ruben.astud@gmail.com> wrote:

Right on the nail. I played a bit with tcpdump/wireshark to see I was
just sending 0 length ACKs and multiple 4 byte messages joined on a
single packet. Seems TCP buffers tiny packets using a strategy called
Nagle's algorithm and thus joined all my packets on a bufferzone until a
threeshold. Then it sent them all at once, making the other end crazy.

This looks a bit scary. It should not matter if replies are merged or not.
By any chance, don't your code use recv with some large max buffer size, but expect to get only 4 bytes because this is how much receiver sends each time? If so, change it to read 4 bytes only, and handle the case when less than 4 bytes are out. TCP do not preserve message boundaries and you can expect reads to return data in arbitrary sized chunks.

Regards,
Andrey
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.