[Haskell-cafe] Unexpected behaviour with send and send-buffer setting
Simon Yarde
simonyarde at me.com
Wed Sep 4 04:03:03 CEST 2013
> On 4 Sep 2013, at 00:49, Gregory Collins <greg at gregorycollins.net> wrote:
> If the underlying write operation returns EWOULDBLOCK then the "send" function calls into the GHC IO manager with "threadWaitWrite", which registers interest in the file descriptor using epoll() and blocks the calling Haskell thread until the socket is writable.
If I'm following along correctly.. I was mistaken in thinking that send would never block because sockets are set to non-blocking, whereas the implementation of send re-introduces blocking behaviour through threadWaitWrite and efficient use of epoll (instead of continually polling with the attendant system call overhead).
> On Tue, Sep 3, 2013 at 6:56 PM, Simon Yarde <simonyarde at me.com> wrote:
> 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?
Now I've learned that send *can* block the current thread to avoid overwhelming the receiver (but uses different mechanisms than send()), I understand my app need simply wait for a send to proceed before generating the next chunk.
Does that sound anywhere close?
> On 4 Sep 2013, at 00:58, Joey Adams <joeyadams3.14159 at gmail.com> wrote:
> '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 having the receiver tell the sender how many more bytes it is currently willing to accept. This is done with the "window size" value in the TCP segment header [1].
>
> [1]: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure
If the receiver's buffer is full (reporting window size 0?), does send block until the receiver can accept more bytes, or return 0 bytes sent? Put another way; is there a scenario in which send could return 0 bytes sent?
> On 4 Sep 2013, at 00:13, Brandon Allbery <allbery.b at gmail.com> wrote:
> I would suggest reading a book on TCP/IP networking.
I've studied Beej's Guide To Network Programming, Wikipedia entry, TCP spec, man pages.. I'll gladly take any recommendations that could help me understand system resource usage and configuration.
Many thanks Brandon, Gregory, Joey.
More information about the Haskell-Cafe
mailing list