Thu, 7 Apr 88 17:10:53 EDT
Sockets are not really the provider of session service, though they
are the interface to the service. And they don't provide a protocol.
For sockets to provide a session _protocol_ there would have to
be a session protocol data unit to be sent over TCP
when establishing and tearing down the TCP connection.
But such a protocol is not defined separately in the DoD stack. In
some ways, TCP contains its own session protocol, in the SYN and FIN
It is a bug that 4.2 TCP connections can become ESTABLISHED and
receive data when the upper layer process is incapable of receiving
the data. However, TCP has a good mechanism for dealing
with the situation where its ULP does not consume the incoming data:
it indicates a zero window to its TCP peer, which then must cease
to send, though it may send a periodic probe to see if the window has opened.
A TCP which has been given this zero window needs some way to throttle
the process sending over it. In UNIX, once the send queue gets filled
with the data that can't be sent, the system blocks further writes. There
is no crash. In your case, it looks like the Client sends an 11 byte message
that needs a reply from the Server, so the Client waits without being blocked.
The Recv-Q and Send-Q entries are in bytes. The high-water mark is
an amount queued that determines when to indicate a zero window (receiving)
or block the write (sending). The high-water mark is some multiple
of 1024, often 4096, depending on your version. In 4.3 it is user-settable.
The file descriptor limit which caused your situation is
an implementation matter, nothing to do with the protocol definitions.
In 4.3, the fd limit went up to 100. Even in 4.2-based systems,
one server can establish more than 26 simultaneous connections by
handing off the active sockets to children, then closing its own copies
of the file descriptors.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:55 GMT