- When a user application
sends data to
another user application, the
data is
first stored in a
send buffer inside Operating System kernel:
- When the send buffer contains
more than MSS bytes
or when the send time expires,
the TCP module will
send the data
in a TCP segment to the receiver:
The receive data is stored in a receive buffer inside the Operating System kernel of the receiver computer
- The receiving application
can use the read() system call
to empty the
received data
from the receive buffer:
- Flow control
is a mechanism to ensure that the
transmission
rate of the sender
do not exceed the
capacity
of the receiver.
- Fact:
- If the transmission rate
exceeds
the capacity of the receiver,
then
sooner or later,
there is
no buffer space left
to store arriving packets
When this happens, newly arriving packets are discarded
- If the transmission rate
exceeds
the capacity of the receiver,
then
sooner or later,
there is
no buffer space left
to store arriving packets
- Here's an analogy of what happens when the
receiver processing rate
is lower than the
transmission rate:
The bucket has a hole that let water drain at 1 Gal / min
A pipe fills the bucket with water at 2 Gal /min
Sooner or later, the bucket will overflow
- Flow control
in TCP is implemented with the
Advertised Windowsize
in the TCP header:
(Discussion on the TCP header: click here )
- Using the Advertised Window Size:
- The Adv. Win. size is
the maximum number of bytes
that the receiver
is willing to
buffer
The sender should honor the receiver's request and refrain from sending more data than the given adv. win. size
Example:
Notes:
- The client tells the server not to send more than 300 bytes
- The server tells the client not to send more than 900 bytes
- The Adv. Win. size is
the maximum number of bytes
that the receiver
is willing to
buffer
- Factors
that determine
the Advertised Window Size:
- The size
of the receive buffer
that the TCP connection has reserved
The receive buffer size is fixed at connection establishment
- The amount of data currently buffered in the receive buffer
- The size
of the receive buffer
that the TCP connection has reserved
- The receive buffer:
- The receive buffer
is located inside
the Operating System (kernel).
- The receive buffer is filled when a data segment is received
- The receive buffer is emptied (a little bit) when data is read by the user process
- The user program
can set the
maximum receive buffer size
by using
the setsockopt()
system call
From the setsockopt man page:
The SO_SNDBUF and SO_RCVBUF options adjust the normal buffer sizes allocated for output and input buffers, respectively. The buffer size may be increased for high-volume connections or may be decreased to limit the possible backlog of incom- ing data. The maximum buffer size for UDP is determined by the value of the ndd variable udp_max_buf. The maximum buffer size for TCP is determined the value of the ndd vari- able tcp_max_buf.(Use setsockopt before you create a socket :-))
- The default receive buffer size in
Solaris
is 1 Mbytes
cheung@shangchun(2012)> ndd /dev/tcp tcp_max_buf 1048576
- The receive buffer
is located inside
the Operating System (kernel).
- The following types of data
can be store in the
receive buffer:
- Deliverable data:
- Data that has been acknowledges
I.e., all preceeding data have been received
The application can readily read the data (because the data can be delivered in the order that was transmitted)
- Undeliverable data:
- Data that was received, but not been acknowledged because some preceeding data has not been received
The application cannot read the data because the data would be read out of the order that was transmitted)
- Deliverable data:
- Computing the Advertised Window Size:
- Clearly, the Advertised WindowSize
should be set to:
Advertised Window = SizeRecvBuffer - (LastByteRecv - LastByteRead)
- The effect of
flow control is
only evident
when a
speedier sender
transmits to a
slower receiver !!!
- The following example of
flow control
uses a receive buffer size of 100 K bytes.
Flow control Example:
- Initially, the send and receive buffer are empty.
Receiver advertises a window of 100 K bytes.
- Sender sends many packets quickly, faster than the receiver can
process...
the receive buffer starts to fill and soon the advertised window drops to 50 K bytes:
- The situation continues and the receive buffer fills further
The ACK packets from the receiver will now have a lower the advertised window, e.g., 1 K bytes:
- Sooner or later, the
receive buffer fills up
The receiver returns an ACK packets with the advertised window = 0 bytes !!!
This causes the sending TCP to stop transmitting more data..... and prevented the sending TCP to overflow the receive buffer of the receiving TCP.
NOTE:
- This will not stop the
sending application
from sending more data....
The sending application process can still send more data...
but the data sent will remains in the send buffer !!! (as given in the above figure)
- This will not stop the
sending application
from sending more data....
- If the sending application process
continues sending, the
send buffer will
fill up
A subsequent write() call will cause the sending application process to block:
Now the faster sending applicationprocess has been successfully throttle...
- Initially, the send and receive buffer are empty.
- The default bahavior
of write() is
blocking
- When the send buffer fills up, the write() operation will cause the application to block (wait)
- Non-blocking write() operations:
- The following UNIX system call will
change the behavior of
write()
to non-blocking:
fcntl(socket, F_SETFL, fcntl(recvfd, F_GETFL)|O_NDELAY);
The write() operation will return −1 when the send buffer is full (otherwise, it will return the number of bytes written)
- The following UNIX system call will
change the behavior of
write()
to non-blocking:
- Important fact:
- A receiving TCP protocol module
will only send an (ACK) packet
if it has
received a TCP segment....
- Rephrased:
- A receiving TCP protocol module will not send an (ACK) packet if it has not receive any TCP segment....
The rephrased statement is pretty obvious --- why would you acknowledge nothing :-)
- A receiving TCP protocol module
will only send an (ACK) packet
if it has
received a TCP segment....
- Unforeseen consequence
of Flow Control:
- Since the advertised window size = 0
at the sender, the
sender
cannnot send any packet...
- Consequently, the
the receiver
may not send any packet
to the sender
- Consequently, the Adverised Window Size of the sender will remain ZERO
We have a "dead-lock" situation:
- Since the advertised window size = 0
at the sender, the
sender
cannnot send any packet...
-
If the advertised window size = 0
at the sender
and the sender has some data
in the send buffer,
the sender will
periodically send a
one byte TCP segment
to the receiver to
trigger a response
from the receiver:
The acknowledgement for the byte size probe TCP segment will contain the new (non-zero) value of the advertised window size that the sender can use to pace its transmissions