#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