 it calls urgent mode, allowing one end to tell the other end that "urgent data" of some form has been placed into the normal stream of data. The other end is notified that this urgent data has been placed into the data stream, and it's up to the receiving end to decide what to do.
The notification from one end to the other that urgent data exists in the data stream is done by setting two fields in the TCP header. The URG bit is turned on and the 16-bit urgent pointer is set to a positive offset that must be added to the sequence number field in the TCP header to obtain the sequence number of the last byte of urgent data.
Unfortunately many implementations incorrectly call TCP's urgent mode out-of-band data. The confusion between TCP's urgent mode and out-of-band data is also because the predominant programming interface, the sockets API, maps TCP's urgent mode into what sockets calls out-of-band data.
Chapter 21: TCP Timeout and Retransmission
TCP provides a reliable transport layer. One of the ways it provides reliability is for each end to acknowledge the data it receives from the other end. But data segments and acknowledgments can get lost. TCP handles this by setting a timeout when it sends data, and if the data isn't acknowledged when the timeout expires, it retransmits the data.
TCP manages four different timers for each connection:
- A retransmission timer is used when expecting an acknowledgment from the other end.
- A persist timer keeps window size information flowing even if the other end closes its receive window.
- A keepalive timer detects when the other end on an otherwise idle connection crashes or reboots.
- A 2MSL timer measures the time a connection has been in the TIME_WAIT state.
Fundamental to TCP's timeout and retransmission is the measurement of the round-trip time (RTT) experienced on a given connection.
When TCP times out and retransmits, it does not have to retransmit the identical segment again. Instead, TCP is allowed to perform repacketization, sending a bigger segment, which can increase performance.
Chapter 22: TCP Persist Timer
If an acknowledgment is lost, we could end up with both sides waiting for the other: the receiver waiting to receive data (since it provided the sender with a nonzero window) and the sender waiting to receive the window update allowing it to send. To prevent this form of deadlock from occurring the sender uses a persist timer that causes it to query the receiver periodically, to find out if the window has been increased.
Chapter 23: TCP Keepalive Timer
No data flows across an idle TCP connection. As long as neither connected host reboots, the connection remains established. The keepalive timer provides a server with the capability to know if the client's host has either crashed and is down, or crashed and rebooted. If there is no activity on a given connection for 2 hours, the server sends a probe segment to the client (the client may also implement keep alive).
Keep alive is not in the TCP spec. The keepalive feature is controversial. Protocol experts continue to debate whether it belongs in the transport layer, or should be handled entirely by the application.
It operates by sending a probe packet across a connection after the connection has been idle for 2 hours. Four different scenarios can occur: the other end is still there, the other end has crashed, the other end has crashed and rebooted, or the other end is currently unreachable.
Chapter 24: TCP Futures and Performance
Chapter 25: Simple Network Management Protocol (SNMP)
Chapter 26: Telnet and Rlogin
Chapter 27: File Transfer Protocol (FTP)
Chapter 28: Simple Mail Transfer Protocol (SMTP)
The exchange of mail using TCP is performed by a Message Transfer Agent (MTA). The most common MTA for Unix systems is Sendmail. SMTP is how to MTAs communicate with each other across a single TCP connection.