On Tue, Sep 3, 2013 at 6:56 PM, Simon Yarde <simonya...@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 allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
