This preview shows page 1. Sign up to view the full content.
Unformatted text preview: t error, not a hard error. Normally the queue is full because the application
or the operating system is busy, preventing the application from servicing incoming
connections. This condition could change in a short while. But if the server's TCP responded
with a reset, the client's active open would abort (which is what we saw happen if the server
wasn't started). By ignoring the SYN, the server forces the client TCP to retransmit the SYN
later, hoping that the queue will then have room for the new connection.
A subtle point in this example, which is found in most TCP/IP implementations, is that TCP
accepts an incoming connection request (i.e., a SYN) if there is room on the listener's queue,
without giving the application a chance to see who it's from (the source IP address and source
port number). This is not required by TCP, it's just the common implementation technique (i.e.,
the way the Berkeley sources have always done it). If an API such as TLI (Section 1.15) gives
the application a way to learn when a connection request arrives, and then allows the
application to choose whether to accept the connection or not, be aware that with TCP, when
the application is supposedly told that the connection has just arrived, TCP's three-way
handshake is over! Other transport layers may be implemented to provide this separation to the
application between arrival and acceptance (i.e., the OSI transport layer) but not TCP.
Solaris 2.2 provides an option that prevents TCP from accepting an incoming connection request until the
application says so (tcp_eager_listeners in Section E.4). This behavior also means that a TCP server has no way to cause a client's active open to fail.
When a new client connection is passed to the server application, TCP's three-way handshake is
over, and the client's active open has completed successfully. If the server then looks at the
client's IP address and port number, and decides it doesn't want to service this client, all the
server can do is either close the connection (causing a FIN to be sent) or reset the connection
(causing an RST to...
View Full Document
- Spring '12