[lkml]   [2001]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Client receives TCP packets but does not ACK
    On Sun, 17 Jun 2001, Dan Podeanu wrote:

    > Is there any logical reason why if, given fd is a connected, AF_INET,
    > SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd);
    > to the peer, over a rather slow network (read modem, satelite link, etc),
    > the data gets lost (the remote receives the disconnect before the last
    > packet). According to socket(7), even if SO_LINGER is not set, the data
    > is flushed in the background.

    suppose A writes B, and A closes its fd. suppose that B writes to A and
    it arrives at A before the A->B data has left the buffer. in that case A
    will RST and drop the data in its buffer, so you've lost the data you
    thought you had transmitted.

    > Is it Linux or TCP specific? Or some obvious techincal detail I'm missing?

    it's TCP.

    the linux specific behaviour (and the recommended behaviour now) is that
    above if the B->A traffic arrived before the close, but wasn't read by the
    application on A, then the RST will be sent immediately. this generally
    results in folks discovering their broken applications much earlier than
    on other stacks. it's basically a race condition as to when the B->A data

    the above is the reason apache uses at least 4 system calls to tear down a
    connection... with http/1.1 and pipelining it's totally valid for the B->A
    traffic to be sent regardless of what's happening in the A->B direction.
    (ditto for multiplexed protocols... and to some extent SMTP pipelining.)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:55    [W:0.021 / U:53.536 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site