limits on sockets

[Chris Torek]

In article <1990Feb21.205708.13533 at granite.cr.bull.com>
freedman at granite.cr.bull.com (Jerome Freedman) writes:
>1) a read (or write) on a socket involves a buffer in which the data
>to be read/written is contained. This buffer can be adjusted, according
>to TFM, but what are the limits of the adjustment.

This is up to the implementation.  Typical limits are 32767 or 65535.
The underlying protocol (TCP, AF_UNIX, XNS, Appletalk, etc.) may impose
other limitations as well.

>What is the default size?

This is up to the implementation.  Typical implementations have secret
configuration parameters, such as global variables called `tcp_sendspace',
`tcp_recvspace', etc.

>2) Suppose I get more data (TCP socket) then I have buffer for
>how can I avoid dropping bytes on the floor when I read.
>3) What if I am writing data (TCP socket - in fact all questions
>refer to TCP sockets)

TCP is a reliable stream protocol.  If you ask to read 10 bytes, and
there are 100 bytes, you get 10 of the 100 and the remaining 90 hang
around.  If you ask to write 1000 bytes and there is room in the
outgoing buffer for only 100, your process `hangs' until all the bytes
are written 100-at-a-time (or fewer, if the TCP peer does not permit
sending a 100 byte segment).  The protocol includes `yucky stuff' that
lets the sender and receiver tell each other how much they can handle
at any time; any correct implementation will not overrun the space.
(An incorrect implementation can, of course, lose data; but then, an
incorrect implementation can do *anything*, so why worry about that?)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris