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

Brandon Allbery allbery.b at gmail.com
Wed Sep 4 01:13:22 CEST 2013

On Tue, Sep 3, 2013 at 6:56 PM, Simon Yarde <simonyarde at me.com> wrote:

> I've found that setting the send buffer size causes send to truncate the
> ByteString to the buffer size, but that successive sends continue to
> succeed when the buffer should be full.

I see no actual flow control here. That the receiver is blocked does not
mean the receiver's *kernel* has not received the packets and buffered
them. Also note that send is not synchronous; it cannot know that the
receiver has hit its buffer limit --- and the kernel may well have already
sent the previous packet, so the send buffer is in fact empty at that
point, with the pending packet either in flight or in the receiving
kernel's (interrupt time or normal; they are usually distinct. Or, with a
sufficiently fancy network card, its own) network buffers.

In short, you have not thought through all the possible ramifications, nor
considered that the kernel handles packets and buffering independently of
your program, nor considered the effects of the non-instantaneous network
between sender and receiver. It may or not behave differently when sender
and receiver are on the same machine. Do not assume that the kernel will
short-circuit here and leave out all the intermediate buffering! The only
part you're guaranteed to avoid is the interface with the network hardware.

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?

I would suggest reading a book on TCP/IP networking.

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/e9c7886e/attachment.htm>

More information about the Haskell-Cafe mailing list