Re: TCP wait_for transmit question

[Balraj Singh <balraj.singh@xxxxxxxxxxxx>]

This is what the write buffer is supposed to do and it definitely
improves overall performance.  It allows the app and tcp to not be in
lock step.  The app can dump a chunk of data to be sent in the write
buffer, when tcp gets acks that open up the window it has data ready
to be sent.  This buffer also needed to implement Nagle's algorithm.

This is what was implemented:

When the app does a write:

    if (write buffer is not empty) {
        if (adding pkt to buffer will make the total bytes buffered
more than a configured max value) {
          block till buffer becomes available, then attempt a write again
        } else {
           add pkt to buffer and return
        }
    } else {
        if (window is available) {
            send pkt and return
        } else {
            add pkt to write buffer and return
        }
    }


and when an ack clears some window:

   if (there are pkts in write buffer) {
       remove and send pkts from buffer upto available window;
       wake up any threads waiting for buffer to become available
    }



On Wed, Jul 11, 2012 at 7:40 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> Haris just raised an interesting point on IRC.  He wants to limit the amount 
> of data sent on TCP write, which is normally done via TCP.Pcb.write_wait_for 
> <bytes>.
>
> This function calls the User_buffer.TX, which clamps it to the TX transmit 
> window, which we ideally want to keep full at all times.
>
> Do we need another function to wait for space to be free in the 
> TX.User_buffer (if it's greater than max_size), which will more closely match 
> the UNIX write(2) semantics?  That is, write works until the transmit buffer 
> is full, providing the TCP stack with more leeway to schedule on-the-wire 
> packets.
>
> -anil