mankin@GATEWAY.MITRE.ORG (04/08/88)
Hi, 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 handshakes. 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.