Receiving Packets

The code flow diagram in Figure 12-30 shows the path taken — starting from the familiar tcp_v4_rcv function — when packets are received.

Figure 12-30: Receiving packets in TCP connections.

After control has been passed to tcp_v4_do_rcv, a fast path is selected (if a connection already exists) rather than entering the central dispatcher function — this is in contrast to other socket states but is logical because the transmission of data packets accounts for the lion's share of work in any TCP connection and should therefore be performed as quickly as possible. Once it has been established that the state of the destination socket is TCP_ESTABLISHED, the tcp_rcv_established function is invoked to split the control flow again. Packets that are easy to analyze are handled in the fast path and those with unusual options in the slow path.

Packets must fulfill one of the following criteria to be classified as easy to analyze:

□ The packet must contain only an acknowledgment for the data last sent.

□ The packet must contain the data expected next.

In addition, none of the following flags must be set: SYN, URG, RST, or FIN.

This description of the ''best case scenario'' for packets is not Linux-specific but is also found in many other Unix variants.30 Almost all packets fall within these categories,31 which is why it makes sense to differentiate between a fast and a slow path.

Which operations are performed in the fast path? A few packet checks are carried out to find more complex packets and return them to the slow path. Thereafter the packet length is analyzed to ascertain whether the packet is an acknowledgment or a data packet. This is not difficult because ACK packets do not contain data and must therefore be of exactly the same length as a TCP packet header.

30This approach was developed by Van Jacobsen, a well-known network researcher, and is often referred to as the VJ mechanism.

31Today's transmission techniques are so sophisticated that very few errors occur. This was not the case in the early days of TCP. Although more faults arise on global Internet connections than in local networks, most packets can still be handled in the fast path owing to the low error rates.

The fast path code doesn't bother with processing ACK segments but delegates this task to tcp_ack. Here, obsolete packets and packets sent too early owing to faulty TCP implementations at the receiving end or to unfortunate combinations of transmission errors and time-outs are filtered out. The most important tasks of this function are not only to analyze new information on the connection (e.g., on the receiving window) and on other subtleties of the TCP protocol, but also to delete acknowledged data from the retransmission queue (discussed below). This queue holds all sent packets and retransmits them if they are not acknowledged by means of an ACK within a certain time period.

Because it has been established during selection of the packet for fast path handling that the data received immediately follow the previous segment, the data can be acknowledged by means of an ACK to the sender without the need for any further checks. Finally, the sk_data_ready function pointer stored in the socket is invoked to inform the user process that new data are available.

What is the difference between the slow path and the fast path? Owing to the many TCP options, the code in the slow path is more extensive. For this reason, I won't go into the many special situations that can arise because they are less of a kernel problem and more of a general problem of TCP connections (detailed descriptions are available in, e.g., [Ste94] and [WPR+01]).

In the slow path, data cannot be forwarded directly to the socket because complicated packet option checks are necessary, and these may be followed by potential TCP subsystem responses. Data arriving out of sequence are placed on a special wait queue, where they remain until a contiguous data segment is complete. Only then can the complete data be forwarded to the socket.

Continue reading here: Sending Packets

Was this article helpful?

0 0