[Haskell-cafe] Unexpected behaviour with send and send-buffer setting

[Brandon Allbery]

On Tue, Sep 3, 2013 at 7:58 PM, Joey Adams <joeyadams3.14159 at gmail.com>wrote:

> On Tue, Sep 3, 2013 at 6:56 PM, Simon Yarde <simonyarde at me.com> wrote:
>
>> I'm new to Haskell and have reached an impasse in understanding the
>> behaviour of sockets.
>>
>> The crux of my line of enquiry is this;  how can my application know when
>> to pause in generating its chunked output if send doesn't block and the
>> current non-blocking send behaviour apparently succeeds when the send
>> buffer should be full?
>>
>
> 'send' will eventually block after enough 'send's without matching
> 'recv's.  As Brandon explains, there is more buffering going on than the
> send buffer.  In particular, the receiving host will accept segments until
> its buffer fills up.  TCP implements flow control (i.e. keeps the sender
> from flooding the receiver) by
>

Also note that, if you're using TCP, Nagle's algorithm will be turned on
unless you specifically turn it off; this is explicitly designed to avoid
sending very short packets, by buffering them into larger packets in the
kernel network stack up until some timeout or a minimum threshold size is
reached. (Protocols such as ssh and telnet turn it off for interactivity.)
And if you're using UDP, there's no flow control at all; while packets
won't be aggregated á la Nagle, the network stacks on the sending and
receiving ends can do pretty much whatever they want with the individual
packets. And in either case the socket buffer size is only the "last mile":
there is no way to control what happens elsewhere, and in particular the
interrupt-time received packet handling usually won't know even what socket
is the target, much less what buffer size that socket has set.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130903/825b5e3b/attachment.htm>