Question about flow control over ethernet with TCP

Computer A uses send() to send a continuous stream of data to Computer
B, via a TCP (connection-oriented, reliable) connection, and Computer
B uses recv() to read it from the socket.

Both are running Fedora Core 3, if that matters.

If Computer B is busy and is unable to keep up with the stream of data
being sent by Computer A, what eventually happens?

Does Computer B fill up some kind of internal FIFO buffer and then
block Computer A from sending any more until space is available?

Or, does Computer A just keep sending and the excess / overflow just
falls onto the floor and is lost?

Or, is it up to the application that is using these sockets to provide
the flow control, similar to XON and XOFF in the old serial protocol?

On Mon, 01 May 2006 15:32:44 -0400, C. J. Clegg <(E-Mail Removed)> wrote:

>
>Computer A uses send() to send a continuous stream of data to Computer
>B, via a TCP (connection-oriented, reliable) connection, and Computer
>B uses recv() to read it from the socket.
>
>Both are running Fedora Core 3, if that matters.
>
>If Computer B is busy and is unable to keep up with the stream of data
>being sent by Computer A, what eventually happens?
>
>Does Computer B fill up some kind of internal FIFO buffer and then
>block Computer A from sending any more until space is available?
>
>Or, does Computer A just keep sending and the excess / overflow just
>falls onto the floor and is lost?
>
>Or, is it up to the application that is using these sockets to provide
>the flow control, similar to XON and XOFF in the old serial protocol?

Do a tcpdump -ni ethX and pay attention to window

Grant.
--
Memory fault -- brain fried

On Mon, 01 May 2006 15:32:44 -0400, C.J.Clegg wrote:

>
> Computer A uses send() to send a continuous stream of data to Computer B,
> via a TCP (connection-oriented, reliable) connection, and Computer B uses
> recv() to read it from the socket.
>
> Both are running Fedora Core 3, if that matters.
>
> If Computer B is busy and is unable to keep up with the stream of data
> being sent by Computer A, what eventually happens?
>
> Does Computer B fill up some kind of internal FIFO buffer and then block
> Computer A from sending any more until space is available?
>
> Or, does Computer A just keep sending and the excess / overflow just falls
> onto the floor and is lost?
>
> Or, is it up to the application that is using these sockets to provide the
> flow control, similar to XON and XOFF in the old serial protocol?

Hi.

There are a few mechanism in the TCP/IP stack to help on those issues.

ICMP Source Quench message (ICMP type 4 )
When a computer is too busy to receive a certain quantity of messages,
it can send ICMP type 4 messages to the other host and by doing so
tell the other host to slow down its number of packets transmitted per
period of time. Obviously, Firewall issues can happen here.


The other mechanism is the "Windows Size" feature.
When the TCP connection is created, both computers do not know how
reliable the network is.

So the Host A send the first packets to host B.
And wait for Host B to replay that all went fine.

We do not want computers to wait just to hear that all went fine.
So next, Host A send to host B two packets. And will wait for an
confirmation that both packets went fine.

And the number of packets sent without confirmation will raise
up to a value preprogrammed in the stack.

Now, let's say an unfortunate event occur. A packet is lost.
or the confirmation packet is lost.

Then the "Windows Size" will be diminished.



Hope it help...

On Sat, 06 May 2006 11:23:32 -0400, noEMA <(E-Mail Removed)>
wrote:

>> Hope it help...

It does, thank you...