[Haskell-cafe] network package and SIGVTALRM

[Andrey Sverdlichenko]

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 at 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 at ruddy.ru>
> wrote:
>
>> On Wed, Jul 13, 2016 at 3:14 AM Ruben Astudillo <ruben.astud at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160713/54f5fa40/attachment.html>