size of socket.recv buffer

David Bolen db3l at fitlinxx.com
Mon Feb 25 23:13:25 EST 2002


"Mike C. Fletcher" <mcfletch at geocities.com> writes:

> OS-level buffer is now full, OS TCP stack signals server to stop sending 
> packets, as it can't deal with any new data until the OS-level buffer is 
> read/recv/cleared [I'm assuming TCP does this explicitly, I normally do 
> with my own networking code]

Actually, it's more a lack of a message than an explicit signal to
stop sending.  The two TCP stacks have a "window" (in terms of deltas
between the packet sequence numbers currently flowing between the
endpoints) that was negotiated between them as to how much data they
are willing to let the sender get ahead of the receiver.  Both ends
include sequence information in each packet (whether a data packet or
just an ACK).  As the receiver consumes data from the front of the
window, the sender is able to send more data on the tail end of the
window simply by knowing how far ahead in the sequence he is allowed
to be based on the window size.  So when the receiver begins to back
up (whether it lost earlier data, or can no longer queue up the
information higher up in the protocol stack), the front end of the
window won't move, and the sender is forced to wait since there is no
room in the window for it to push more data onto the network.

This is more efficient than an explicit "squelch" sort of command,
since you don't have to wait for a network round trip for the command
to be received (nor deal with failures to deliver that command) before
the data stops - and thus you avoid just having to retransmit data all
over again once the receiver does in fact have room to deal with it.
It also ensures that you always have a window size worth of data
already sent between sender and receiver even when the system is
blocked due to queueing, so that when things begin to open up, you
don't have to wait for another round trip delay to get new data on the
receiver (although you do to have the new data from the sender start
arriving at the receiver).

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list