#LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 221 \textclass report \begin_preamble \input{preamble} \end_preamble \language english \inputencoding auto \fontscheme times \graphics default \paperfontsize 11 \spacing double \papersize letterpaper \paperpackage a4 \use_geometry 1 \use_amsmath 1 \use_natbib 1 \use_numerical_citations 1 \paperorientation portrait \leftmargin 1.5in \topmargin 0.9in \rightmargin 1in \bottommargin 1in \headsep 0.17in \footskip 0in \secnumdepth 4 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle fancy \layout Chapter Assessment on how INET processes TCP/IP packets \begin_inset LatexCommand \label{cha:A3-Assessment on TCP} \end_inset \layout Standard \begin_inset ERT status Collapsed \layout Standard \backslash thispagestyle{empty} \end_inset \begin_inset ERT status Collapsed \layout Standard \backslash renewcommand \backslash figurename{Fig.} \end_inset The last section was about the UML tool. This section is about how Linux's TCP suite, INET, Handles TCP packets. This section will give a slight overview of the TCP/IP layers and then in the next section go into more detail over some of the major structures in the INET. These next two sections are helpful to understanding the kernel modifications, and how the Linux kernel handles the TCP protocol. The INET (Linux implementation of the TCP IP suite) is purely the same as the RFC's and some explanation of the differences are needed. \layout Section Overview of TCP \layout Standard The TCP is the transport communication protocol. In the protocol stack it is four (transport) right above the Internet Protocol (IP). The TCP guarantees the arrival of the packets. The way the Linux kernel uses TCP is the packet arrives at the network card and the information (digital signals) is transferred to memory. The Linux kernel creates a structure in memory (called a sk_buff) which has pointers to the newly received digital transmission now in memory. Each transmission is a packet â a part of the original transmitted data with the headers attached. Each TCP packet consist of three different types of headers (Ethernet, IP, TCP) and the data . The need for TCP and other transport layer protocols is to allow the partitioni ng of data. \layout Standard If a user is downloads a modestly size file, say the latest UML root_fs from sourceforge (the file would be roughly 16 megs). Transferring all this file in one big packet (one set of headers) would be cumbersome. If another user else wants to use the bandwidth, they would have to wait until the transmission of 16 megabytes is complete. With a transport layer protocol, like TCP, the users share bandwidth. \layout Standard The data is partition into small packets (roughly 1500 bits a piece) each having their own set of headers. The TCP protocol was developed for the department of defense. If a network connection was broke and other routes were available, the department of defense wanted a way to ensure the data's arrival. These headers tell the packet where to go and ensures the packet gets there. This is what the Ethernet and IP headers do. The Ethernet and IP headers contain sets of address (kind of like street address) to tell the packet where to go. \layout Standard he data packets are divided into pieces, and the Internet is not all the same bandwidth and reliability. Some packets will arrived mixed up, corrupted, twice or not at all. The TCP headers contain information to manage the arrival of the packets and makes sure the application receives the data in order. \layout Section TCP Header and Sk_buff \layout Standard Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:TCP Header} \end_inset shows the TCP header and Fig.\SpecialChar ~ illistrates the TCP header structure in the Linux code. The total length of the TCP header is 20 bytes; four bytes for each row. Eight bits equal one byte; the TCP header is 160 bits. Of those 160 bits, 64 bits are used for the sequence and acknowledgment numbers (32 bits for the sequence and 32 bits for the acknowledgment number). The Seq and Ack numbers are how the TCP keeps packets in order. \layout Standard \begin_inset Float figure placement H wide false collapsed true \layout Standard \align center \begin_inset Graphics filename Figures/a1tcpHeader.eps display none \end_inset \layout Caption \begin_inset LatexCommand \label{fig:TCP Header} \end_inset Tcp header \end_inset \layout Standard The header has all sorts of information. In the kernel, TCP header is accessed by a pointer in the sk_buff (stands for socket buffer). The sk_buff is the most important structure in the networking of the kernel because it references the incoming network packet and a cental hub for routing information. In Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig: headers of skbuf} \end_inset is a code sniped of the sk_buff: \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \paragraph_spacing single \align left struct sk_buff { \newline \SpecialChar ~ \SpecialChar ~ /* These two members must be first. */ \newline \SpecialChar ~ \SpecialChar ~ struct sk_buff * next; /* Next buffer in list */ \newline \SpecialChar ~ \SpecialChar ~ struct sk_buff * prev; /* Previous buffer in list */ \newline \SpecialChar ~ \SpecialChar ~ struct sk_buff_head * list; /* List we are on */ \newline \SpecialChar ~ \SpecialChar ~ struct sock *sk; /* Socket we are owned by */ \newline \SpecialChar ~ \SpecialChar ~ struct timeval stamp; /* Time we arrived */ \newline \SpecialChar ~ \SpecialChar ~ struct net_device *dev; /* Device we arrived on/are leaving by */ \newline \SpecialChar ~ \SpecialChar ~ /* Transport layer header */ \newline \SpecialChar ~ \SpecialChar ~ union { \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct tcphdr *th; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct udphdr *uh; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct icmphdr *icmph; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct igmphdr *igmph; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct iphdr *ipiph; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct spxhdr *spxh; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ unsigned char *raw; \newline \SpecialChar ~ \SpecialChar ~ } h; \newline \SpecialChar ~ \SpecialChar ~ /* Network layer header */ \newline \SpecialChar ~ \SpecialChar ~ union { \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct iphdr *iph; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct ipv6hdr *ipv6h; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct arphdr *arph; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct ipxhdr *ipxh; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ unsigned char *raw; \newline \SpecialChar ~ \SpecialChar ~ } nh; \newline \SpecialChar ~ \SpecialChar ~ /* Link layer header */ \newline \SpecialChar ~ \SpecialChar ~ union { \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ struct ethhdr *ethernet; \newline \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ \SpecialChar ~ unsigned char *raw; \newline \SpecialChar ~ \SpecialChar ~ } mac; \newline \SpecialChar ~ \SpecialChar ~ struct dst_entry *dst; \newline \SpecialChar ~ \newline \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{fig: headers of skbuf} \end_inset header section of the sk_buff \end_inset \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Tabular \begin_inset Text \layout Standard \paragraph_spacing single \align left struct tcphdr { \newline \SpecialChar ~ \SpecialChar ~ __u16 source; \newline \SpecialChar ~ \SpecialChar ~ __u16 dest; \newline \SpecialChar ~ \SpecialChar ~ __u32 seq; \newline \SpecialChar ~ \SpecialChar ~ __u32 ack_seq; \newline \SpecialChar ~ \SpecialChar ~ #if defined(__LITTLE_ENDIAN_BITFIELD) \newline \SpecialChar ~ \SpecialChar ~ __u16 res1:4, \newline \SpecialChar ~ \SpecialChar ~ doff:4, \newline \SpecialChar ~ \SpecialChar ~ fin:1, \newline \SpecialChar ~ \SpecialChar ~ syn:1, \newline \SpecialChar ~ \SpecialChar ~ rst:1, \newline \SpecialChar ~ \SpecialChar ~ psh:1, \newline \SpecialChar ~ \SpecialChar ~ ack:1, \newline \SpecialChar ~ \SpecialChar ~ urg:1, \newline \SpecialChar ~ \SpecialChar ~ ece:1, \newline \SpecialChar ~ \SpecialChar ~ cwr:1; \newline \SpecialChar ~ \SpecialChar ~ #elif defined(__BIG_ENDIAN_BITFIELD) \newline \SpecialChar ~ \SpecialChar ~ __u16 doff:4, \newline \SpecialChar ~ \SpecialChar ~ res1:4, \newline \SpecialChar ~ \SpecialChar ~ cwr:1, \newline \SpecialChar ~ \SpecialChar ~ ece:1, \newline \SpecialChar ~ \SpecialChar ~ urg:1, \newline \SpecialChar ~ \SpecialChar ~ ack:1, \newline \SpecialChar ~ \SpecialChar ~ psh:1, \newline \SpecialChar ~ \SpecialChar ~ rst:1, \newline \SpecialChar ~ \SpecialChar ~ syn:1, \newline \SpecialChar ~ \SpecialChar ~ fin:1; \newline \SpecialChar ~ \SpecialChar ~ #else \newline \SpecialChar ~ \SpecialChar ~ #error "Adjust your defines" \newline \SpecialChar ~ \SpecialChar ~ #endif \newline \SpecialChar ~ \SpecialChar ~ __u16 window; \newline \SpecialChar ~ \SpecialChar ~ __u16 check; \newline \SpecialChar ~ \SpecialChar ~ __u16 urg_ptr; \newline }; \newline \SpecialChar ~ \newline \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{fig:IP-error messages} \end_inset IP tunnel error messages \end_inset \layout Section Establishing a TCP connection \layout Standard The sequence and acknowledgment numbers mentioned earlier manages the arrival and order of the packets. The Linux kernel labels each packet that is sent with a beginning sequence number on each side. This sequence number is incremented by a known value. If the packets become out of sequence, the receiver can tell by the sequence number. \layout Standard The initial sequence number is determined by the sender. It creates a packet (sk_buff) and sends it down the protocol stack and out to the Internet. The TCP header has a section of one bit FLAGS. There are six flags: URG, ACK, PSH, RST, SYN, and FIN. The initial packet send by the sender not only has the initial sequence number, but also has the SYN flag set. When the receiver gets the initial packet. It processes the packet and sends its own sequence number and places the just received sequence number in the acknowledgment field. The sender then sets two flags in the TCP header: SYN and ACK. \layout Standard How the INET starts the connection is discussed in Section\SpecialChar ~ \begin_inset LatexCommand \ref{sec:BSD-and-INET} \end_inset and a back trace is done in Tables\SpecialChar ~ \begin_inset LatexCommand \ref{table:SendBacktrace} \end_inset and\SpecialChar ~ \begin_inset LatexCommand \ref{table:RecvBacktrace} \end_inset . \layout Standard When the receiver receives the SYN and ACK packet. It sends a packet with the ACK flag marked to acknowledge the SYN/ACK packet. Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:ConnectionState} \end_inset is a finite state diagram of the TCP establishing a connection. \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename Figures/connectionState.eps display none \end_inset \layout Caption \begin_inset LatexCommand \label{fig:ConnectionState} \end_inset Tcp state diagram \end_inset \layout Standard This complex flowchart is intimating at first. This diagram is from the RFC for the TCP protocol \begin_inset LatexCommand \citep{Institute1981} \end_inset . The next section goes through this diagram and talks about the first three packets used to establish a connection, called the three-way handshake. The example will be a simple web request. \layout Standard The three-way hand shake is used to establish the connect between two computers. The finite state diagram start at the âbeginâ label. The finite state diagram is for each side of the connection; one state diagram represents the sender and the other represents the receiver. For a connection there are two starting positions on the finite state diagram for each side of the connection shown in Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:TCP sending Sync} \end_inset . \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename Figures/tcp1.eps \end_inset \layout Caption \begin_inset LatexCommand \label{fig:TCP sending Sync} \end_inset Sending the initial syn message \end_inset \layout Standard Starting with the sending side, the \begin_inset Quotes eld \end_inset begin \begin_inset Quotes erd \end_inset label at the upper left. The TCP socket is in closed state. The user (at the computer) decides to open a web page, send some email, telnet, or something requiring a TCP connection. The socket receives a system call from the user level \begin_inset LatexCommand \citep{Hall2001} \end_inset . The socket then creates a packet and sets the SYN flag. From the âCLOSEDâ state we move to the âSYN SENTâ state since a packet with a SYN flag was sent. The flags in the TCP header correlate the the SYN, ACK, FIN, and RST shown on the diagram. When a packet is sent with one of these flags. Traverse the state diagram from one state to another based on the flags on the packets send. Also populate the 32-bit sequence number field with an 'm' value (any value between 0-2^32). \layout Standard A SYN packet is sent and the connection is in the SYN SENT state. From the line connecting the CLOSED and the SYN SENT state there is a label with two words \begin_inset Quotes eld \end_inset active open / syn \begin_inset Quotes erd \end_inset . The right side of the front slash is what the sender is sending. The left side is either a state, in this case active open, or what was received from the other machine. Now the sender is sitting at the SYN SEND state. It receives a packet with the SYN ACK flags set in the TCP header from the receiver. The sequence number we sent is now in the 32-bit acknowledge field with 1 added to 'm' (m +1). The socket is following our state diagram too (or programmed to) and then sends a packet with an ACK message. Now on the finite state diagram follows the line labeled \begin_inset Quotes eld \end_inset SYN + ACK/ ACK \begin_inset Quotes erd \end_inset is at ESTABLISHED as shown in Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:TCP SynAck} \end_inset . The connection is established. \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename Figures/tcp2.eps display none \end_inset \newline \begin_inset Graphics filename Figures/tcp3.eps display none \end_inset \layout Caption \begin_inset LatexCommand \label{fig:TCP SynAck} \end_inset SynAck message \end_inset \layout Standard The receiver starts the same place, the beginning label. Now the receiver needs to be in a listening state. The services (Apache, email, or telnet) are communicating to the kernel space through a socket. This socket needs to bound (this is where BIND comes in) to a port number. So when a packet with the correct port number comes in knows where to go. If the TCP socket is not listening for this packet, it just zooms right by into the bit bucket. When the TCP socket is listening for the packet, it receives the packet and sends it up to the application (or service). \layout Standard Main point is the socket needs to be in a listening state to receive packets going to a specific application. So from the CLOSED state, the socket does a âpassive openâ by order of a system call originating from the applications. So the TCP state moves from CLOSED state to LISTEN state by a \begin_inset Quotes eld \end_inset passive open \begin_inset Quotes erd \end_inset . The socket is now listening for any packet that comes in with the correct port number. \layout Standard When the receiver gets the initial packet with the SYN flag set. It generates its own sequence number and places the received sequence number in the acknowledge field. The socket then sets the SYN ACK flags and sends the packets. Now the TCP socket moves to the SYN RECVD state as shown in Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig: established state} \end_inset . \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename Figures/tcp4.eps \end_inset \layout Caption \begin_inset LatexCommand \label{fig: established state} \end_inset Three way handshake moving to an established connection state \end_inset \layout Standard The sender will then send the receiver an ACK packet saying it has received the SYN ACK packet. The sender's socket then moves to the ESTABLISHED state. These three packets are used for establishing a connection, for the sender's and receiver's TCP sockets to exchange sequence numbers and prepare for the actual data transfer. \layout Subsection Inet code processes SYN and SYN ACK \layout Standard In the INET code, the INET socket on the server side is already created and the socket is in a listen state. When the socket is put into connection another INET socket is forked and placed in listening mode. \layout Standard \begin_inset Float table placement H wide false collapsed false \layout Standard \begin_inset Tabular \begin_inset Text \layout Standard Function \end_inset \begin_inset Text \layout Standard Description \end_inset \begin_inset Text \layout Standard t \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none cp_v4_rcv \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none all packets are received at this function \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none tcp_v4_do_rcv \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none starts the processing \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none tcp_rcv_state_process \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none NET socket state (sock->state) is set to TCP_LISTEN. processes the state, checks to see if the socket is in a listening state, then checks the header flag (done in a case statement). \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none tcp_v4_conn_request \end_inset \begin_inset Text \layout Standard requests a connection. Populates the dst_entry with the header \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none tcp_v4_send_synack() \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none sends the synack packet. Calls the correct functions to build a TCP/IP packet (i.e., ip_build_and_send_pk t). Goes through the correct channels to send a packet, calls ip_output --> ip_finish_output2 --> eventually dev_queue_xmit \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{table:BackTrackSyn} \end_inset Backtrace of a syn packet arriving \end_inset \layout Standard Looking in Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{table:BackTrackSyn} \end_inset , the packet comes into tcp_v4_rcv and eventually tcp_rcv_state_proces where the packet is sorted to the correction function based on the socket in the TCP_LISTEN state and the SYN flag being set. tcp_ve_send_synack( ) is called and the synack is sent to the client. \layout Standard When the client receives the synack, as shown in Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{table:BackTrackSynAck} \end_inset , tcp_rcv_state_process again sorts the packet based on the the state, TCP_LISTE N. An acknowledgment packet is sent via tcp_send_ack () and the state is moved from TCP_LISTEN to TCP_ESTABLISHED. \layout Standard \begin_inset Float table placement H wide false collapsed true \layout Standard \begin_inset Tabular \begin_inset Text \layout Standard Function \end_inset \begin_inset Text \layout Standard Description \end_inset \begin_inset Text \layout Standard tcp_v4_do_rcv \end_inset \begin_inset Text \layout Standard C \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none alls tcp_rcv_state_process \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none tcp_rcv_state_process \end_inset \begin_inset Text \layout Standard \family roman \series medium \shape up \size normal \emph off \bar no \noun off \color none The state on the INET socket (sock->state) is set to TCP_SYN_SENT and calls tcp_rcv_state_process. The timer is reset (tcp_reset_xmit_timer), sequence numbers are set, the state is moved to Established in the state diagram (tcp_set_state(sk, TCP_ESTAB LISHED)), the window is set(tp->snd_wnd = ntohs(th->window)), an Ack message is sent back (tcp_send_ack) \end_inset \end_inset \layout Caption \begin_inset LatexCommand \label{table:BackTrackSynAck} \end_inset Backtrace of a syn ack packet arriving \end_inset \layout Section Connection established \layout Standard The transfer of requests and data between the server and client occurs after the connection is established as shown in Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:TCP transmission} \end_inset . \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename Figures/tcp5.eps \end_inset \layout Caption \begin_inset LatexCommand \label{fig:TCP transmission} \end_inset Packet transmission \end_inset \layout Standard Now both the sender and receiver are on the ESTABLISHED state. When the sender sends a request and the receiver responds. The state does not change until the connection is being closed. \layout Standard This example will use web requests for the packet transfer. The request and the web data is not more than 1500 bytes each (roughly the maximum number of bits a packet can send at any one time). So the webpage requested does not have any packets and for this example, and the packet will not be fragmented and reassembled. The sender (web client) sends one request and the receiver (web server) sends just one packet of web information back. \layout Standard When the sender sends the request. It uses its sequence number (which is returned in the acknowledge, incremented by one). Our sequence number is (m + 1), m being the original number sequence number. \layout Standard With the exception of sending data, as a general rule, add one to the sequence number to packets with the SYN, both [SYN ACK], FIN, and [FIN ACK] flags set. This means the only time not to add one to the incoming sequence number is when the ACK flag is set. Fairly simple. Side note, almost half the packets have only the ACK field set, the other half add one too the incoming sequence number. Generally adding one to the sequence number and then placing it in the acknowledge field tells the other side, a packet has arrive. The adding one to the incoming sequence (outgoing acknowledge) is used by the socket to keep track that the packet has been received. \layout Standard Here is another example up in the diagrams. Sender sends a packet with sequence number 1000 and acknowledge of 3000. Receiver receives the packets and takes the sequence number 1000 and places it in the acknowledge field and adds one, becomes 1001. The acknowledge field is now the sequence field, so the receiver is sending the sender his sequence number of 3000 (untouched) and an acknowledge of 1001. This is how the acknowledge and sequence numbers work for setting up and closing a connection. For sending and receiving data requests, the TCP does something a little different to change the incoming sequence number. \layout Standard Sending and receiving data the TCP uses the size of the data (or the size of the payload) to increment the sequence number. My guess is this is to save a spot on payload size and just put it in the sequence number, considering there is not such field for payload size. The incoming sequence number is updated based on the size of the data payload. Below, there is a more extensive picture of the TCP header with where the payload would be located. Generally, TCP packets are setup as: Ethernet header, IP header, TCP header, then data payload as shown in Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:tcp_ip_packet header} \end_inset . \layout Standard \begin_inset Float figure placement H wide false collapsed true \layout Standard \align center \begin_inset Graphics filename Figures/packetheader.eps \end_inset \layout Caption \begin_inset LatexCommand \label{fig:tcp_ip_packet header} \end_inset More extensive header of the ip, tcp, and payload \end_inset \layout Standard The data payload is where the server to client data request and data responses are kept. Again, the three way handshake (three packets opening a connection) and four way close do not contain payloads; these packets are used merely for establishing and closing a connection. \layout Standard A quick example of how the incoming sequence number is updated. The sender sends a web request. A typical command would be, \begin_inset Quotes eld \end_inset GET / HTTP/1.0 \backslash r \backslash n \begin_inset Quotes erd \end_inset to request a webpage. The size of the request is 190 byes (actual size of a request taken from an ethereal capture of the network driver). Again, this web request is going to be in the payload. Let us continue with the example above and start with a sequence number of 1001 and an acknowledge number of 3001. When the web request is received by the sender. The receiver looks at the size of the payload (web request). The payload is 190 bytes. The receiver adds 190 to the incoming sequence number, sets the ACK flag, and places the incoming sequence number in the outgoing acknowledgment making it 1192 with an outgoing sequence number of 3001 (untouched). \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename Figures/packetTransfer.eps \end_inset \layout Caption \begin_inset LatexCommand \label{fig:transfer of packets} \end_inset Transfer of packets showing the syn and ack numbers changing \end_inset \layout Standard The sender will then send the request up to userland and the application (in our case a web server) will process the request. Make a system call to send data out as a packet. The sender then sends another packet (two in a row) with the data requested (webpage). For this example, the webpage is only 598 byes (from an ethereal network driver capture) and is only one packet since the entire size of the packet containing the data requested is under 1500 bytes. The sender sends the webpage data. The PSH and ACK flags are set. \layout Standard The requested data is received by the receiver. The receiver then looks at the size of the payload (size of the webpage data) which is 598 bytes. The incoming sequence number is 3001. The sender takes the incoming sequence number and adds 598 for a total of 3599 and sets the ACK flag with an acknowledge field of 3599. The example can be illistrated in Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:transfer of packets} \end_inset . \layout Standard There are a minimum of four packets transferred when requesting a webpage, and a minimum of ten packets including the TCP overhead packets of opening a closing a connection in Linux. Sending the actual request requires four packets: two ACK's, one request, and one data packets. A good rule of thumb is: the only time the packet are updated (in a simple transfer) is when something other than an ACK (only ACK) packet is received. If the packet is received to setup a connection or close a connection. Only one is added the the incoming sequence number than transferred to the outgoing ACK packet in the acknowledgment field. For data, the size of the payload (either the data request or the actual data) is increment to the incoming sequence number and then placed in the acknowledgment field of the outgoing ACK packet. \layout Subsection Inet transferring data \layout Standard Sending a request or data is talked about in Sections\SpecialChar ~ \begin_inset LatexCommand \ref{sub:Sending-a-packet} \end_inset and \begin_inset LatexCommand \ref{sec:BSD-and-INET} \end_inset . \layout Standard When the request or data is received on the other side the packet is retrieved with a soft interrupt is fire (do_softirq). The packet is placed on the backlog and processed (process_backlog). In the netif_receive_skb, the packet is tagged for the correct protocol and ip_rcv is called (since the packet is tcp_ip). Ip_rcv assigns the correct IP version and points the iphdr (IP header pointer) to the correct spot in memory and validates the checksum. ip_rcv_finish creates the correct dst_entry, and the ip_option is populated. ip_local_deliver_finish determines the transport and calls the TCP protocol. tcp_v4_rcv sets the cache buffer on the skb, validates the checksum, figures out which INET socket, and sends up to tcp_v4_do_rcv for processing. tcp_v4_do_rcv mainly calls tcp_rcv_establish (sends acks) and tcp_rcv_state_pro cess (tcp engine manager and sends packets up to the user). This is also talked about in Section\SpecialChar ~ \begin_inset LatexCommand \ref{sub:Receiving-a-packet} \end_inset . \layout Standard Aftering being processed by the tcp, tcp_data_queue sends packets up to the user by placing them in a queue. An interrupt is called and wakes up sock_recvmsg. The data is sent up to the application layer through (assumming) sock_read and system_read. \layout Section Closing the Connection \layout Standard Closing a connection entails three packets being sent. This part the INET code did not follow standards, because it does not match what the incoming packets suggest. Below is a modified finite state diagram with how the INET does this process. This section is going to talk about what the INET does oppose to the actual published way of closing a connection. \layout Standard There are thee packets involved (published way there are 4). The sender sends a packet with the FIN and ACK flags set. Data transfer is done so there is no data in these packets. Once the receiver receives the FIN ACK packet, the receiver adds one to the incoming sequence number and sends and with the incremented incoming sequence number in the outgoing acknowledgment field, also sets the FIN ACK flags on the outgoing packet. \layout Standard Once the receiver's FIN ACK packet is received by the sender. The receiver increments the incoming sequence number by one and sets the outgoing packet with the just the ACK flag. The sequence and acknowledgment numbers are switched and the packet is sent. The connection on the sender's side is then closed to the receiver. \layout Standard Once the receiver gets the last ACK packet. The connection is closed on both sides. So the transfer of data through sockets can be partitioned into three parts: opening the connection, transferring the data, and closing the connection. \layout Standard \begin_inset Float figure placement H wide false collapsed true \layout Standard \align center \begin_inset Graphics filename Figures/tcp6.eps \end_inset \layout Caption \begin_inset LatexCommand \label{fig:Inets modified close} \end_inset Inet's modified close \end_inset \layout Subsection Inet closing a connection \layout Standard The backlog suggests, the application receives all the data it needs and does a system call (sys_close) to close the socket. The sys_close function calls sock_close, sock_release, and inet_release (releases the INET socket). tcp_close is called and sends the FIN packet ( tcp_send_fin). \layout Standard When the server receives the FIN packet and processes the packet in tcp_rcv_stat e_process where the the application on the server side closes the connection. \layout Section Window \layout Standard Up to this point, there has been a minimum of ten packets fired between the sender and receiver for one packet of information. About half the packets are acknowledges stating the packet has been received. The connection stays open for a set time called \begin_inset Quotes eld \end_inset Keep alive \begin_inset Quotes erd \end_inset . The INET code has timers. The finite state diagram indicates the state can timeout and reset. Once a packet is fired (such as a SYN packet or a web request) a timer inside the INET code starts which schedules for the packet to be resent in the future. If the packet arrives the socket cancels the scheduled event. \layout Standard The timers and the sequence in which packets arrive are all part of a bigger concept called \begin_inset Quotes eld \end_inset flow control \begin_inset Quotes erd \end_inset . Flow control makes sure the packets arrive at a given rate but also in the correct order, removing any duplicates and removing any erroneous packets. The sequence and acknowledge numbers are used for keeping the packets in order. Another field called the window. The window tells the other side how many packets that can be sent before an ACK packet is sent. For example, our small webpage request only had one packet. Assume another download of a bigger webpage. When the connection is established (three-way handshake), the window is sent in the SYN ACK. The window is the amount of data that are allowed to be sent before receiving an acknowledgment. The INET has mechnisms built into it to figure out how many packets and amount of information the computer can handle before problems occur. The sender or client is the one who sets up the initial window. The window is used for flow control. It controls the amount of data that can be sent by both sides. Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:window} \end_inset is a small diagram to illustrate. \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename Figures/tcp7.eps \end_inset \layout Caption \begin_inset LatexCommand \label{fig:window} \end_inset Window flow contro \end_inset \layout Standard In Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:window} \end_inset , the window is three packets. Only three packets can be sent before receiving an acknowledgment. When the acknowledgment for one of the packets is received another packet can be sent. If the window is three, only three packets can be sent without having an acknowledgment. \layout Section Checksum \layout Standard The previous sections talked about how the connections are opened and closed and how flow control is done. This section talks about assuring the accuracy of the TCP header. There is another field called the checksum. In Fig.\SpecialChar ~ \begin_inset LatexCommand \ref{fig:checksum} \end_inset is a diagram of the one's complement addition of the fields in the TCP header \begin_inset LatexCommand \citep{Comer2000} \end_inset . \layout Standard \begin_inset Float figure placement H wide false collapsed false \layout Standard \align center \begin_inset Graphics filename Figures/checksum.eps \end_inset \layout Caption \begin_inset LatexCommand \label{fig:checksum} \end_inset Checksum fields \end_inset \layout Standard The checksum is calculated with one's complement sum of the source IP, destinati on, zero, protocol, and the TCP length. When the packet arrives the same computation verifies the packet arrived in tact. \the_end