Due for Week Group of 3 (max) Percentage awarded for comments, coding practice, layout style, naming convention, completed task.

Transcription

1 EE4607 Project Goals Details Due for Week Group of 3 (max) Percentage awarded for comments, coding practice, layout style, naming convention, completed task. Task Create a SDL implementation of the TCP Process according to RFC 793 Your implementation of TCP must be able to: Open a TCP connection Close a TCP connection Handle Dropped Packets. Other TCP Requirements: The TCP window size is TWO segments. BUFFERING is necessary You must identify essential timers from the RFC and implement them. You must identify the essential Flags and implement them. What you do not have to worry about CRC, Security, there are NO options to be set in TCP. URGENT pointer is not needed. How to test your implementation In parallel to you developing your SDL code, two teams have been instructed to create two SDL layers. The teams cannot be contacted as they have no access to , web or telephony devices. TeamOne in a secret location is working on producing a SDL implementation of the Lower layers Data Link Layer and the Network Layer, and they have implemented a Crazy router which can drop packets at random and deliver packets out of sequence. TeamTwo also in a separate secret location is working on creating a higher Layer protocol and have decided to implement a FTP program that will send a file that is broken into 50 datagrams. These 50 datagrams are presented to the TCP level via an API. To ensure interoperability the size of each of these datagrams is fixed to 64bytes (8 Octets). TCP must be able to handle this information. Both teams will release SDL blocks with code on a regular basis. The first code to be released will be two Dummy blocks. They will simply generate a Data Packet {Higher Layer} that your TCP process should be able to accept. The lower layer will pump a TCP SYN segment into your TCP layer

2 Network Model Application Application TCP TCP LowerLayers CrazyRouter LowerLayers The Network model shown above. TCP Introduction Transmission Control Protocol (TCP) is a means for building a reliable communications stream on top of the unreliable packet Internet Protocol (IP). TCP is the protocol that supports nearly all Internet applications. The combination of TCP and IP is referred to as TCP/IP and many people imagine, incorrectly, that TCP/IP is a single protocol. The basic method of operation involves wrapping higher level application data in segments wrapping the segments into IP datagrams associating port numbers with particular applications associating a sequence number with every byte in the data stream exchanging special segments to start up and close down a data flow between two hosts using acknowledgments and timeouts to ensure the integrity of the data flow TCP Signalling Many applications rely on the connection-oriented services (such as HTTP, FTP, and pure IP) which are offered by TCP. When these applications are launched, the TCP stack on the local device must establish a connection with the TCP stack on the destination device. The handshake process is based on three steps. (In this project, the device that initiates the handshake process is called Device 1, and the destination device, or the target of the connection, is called Device 2.) Device 1 sends its TCP sequence number and maximum segment size to Device 2. Device 2 responds by sending its sequence number and maximum segment size to Device

3 Device 1 acknowledges receipt of the sequence number and segment size information. That s it. Pretty simple. By looking inside the handshake packets, you can see what a TCP header actually contains during the handshake process and understand how to troubleshoot this process. TCP Header TCP segments are constructed from 32 bit words and include a 20 byte (5 word) header. The basic layout is shown below. Figure 1TCP Header source port number The source (and destination) port numbers are used for demultiplexing the data stream to applications. It is entirely possible for there to be multiple simultaneous TCP data streams between two hosts. A TCP data stream is uniquely identified by a group of four numbers. These are the two hosts addresses and the two port numbers. The source port number is the one to be used as destination in any reply to the segment. destination port number This is the "target" port number on the remote system

4 sequence number This 32 bit number identifies the first byte of the data in the segment. acknowledgment number This 32 bit number is the byte number of the next byte that the sender expects to receive from the remote host. The remote host can infer that all bytes up to this number minus one have been safely received and the remote host's local copies can be discarded. header length This 4-bit field specifies the header length in 32 bit words. Clearly the maximum value is 15 words (60 bytes) allowing for 10 (40 bytes) of options. flag bits This group of 6 bits identify various special states in the protocol. Several of the bits may be set simultaneously. The bits are discussed in more detail later. URG ACK PSH RST SYN FIN Indicates that the Urgent pointer is valid. I.e. there is urgent data. The acknowledgment number is valid. This will usually be set. The data should be passed to the application as soon as possible. This will typically involve flushing buffers. Reset the connection. This involves marking the sequence numbers as invalid. The synchronize bit is used to establish initial agreement on the sequence numbers. The sender has finished sending data. This fact will, normally, be passed on to the application as close. window size This is, basically, the amount of space that the receiver has available for the storage of unacknowledged data. The units are bytes unless the window scale factor option is used. The maximum value is checksum This covers both the header and the data. It is calculated by prepending a pseudo-header to the TCP segment, this consists of 3 32 bit words which contain the source and destination IP addresses, a byte set to 0, a byte set to 6 (the protocol number for TCP in an IP datagram header) and the segment length (in words). The checksum field of the TCP segment is set to zero and the following algorithm applied to the prepended segment treated as a sequence of 16 bit (unsigned) words

5 unsigned long cksum = 0; unsigned short *sptr; while(sptr points to part of prepended segment) cksum += *sptr++; cksum = (cksum >> 16) + (cksum & 0xffff); cksum += (cksum >> 16); cksum = (short)(~cksum & 0xffff); Note The inclusion of the IP addresses in the checksum calculation means that TCP cannot easily be carried on lower level protocols other than IP (version 4). urgent pointer This is part of TCP's mechanism for sending urgent data that will overtake the normal data stream. If the URG flag bit is set this field indicates the position within the data of the last byte of the urgent data. There is no way of indicating where the urgent data starts. options There are a number of options defined in various RFCs. The most useful is the Maximum Segment Size (MSS) specification facility. The format of options will be discussed later. Flow Control Flow control is associated with the current byte sequence numbers at each end of the data flow. Whenever a segment is sent it includes the sequence number of the last byte sent. A segment will also include the sequence number of the next byte that the sending host expects to receive, this is called the acknowledgment number (ACK). A host receiving a segment can assume that the remote host has safely received all bytes up to and including byte ACK-1, local copies may now be discarded. The difference between the number of the last byte sent and the acknowledgment number is known as the window. The maximum size of the window is advertised by a host as part of every TCP segment the host sends, a host can quench the flow of data from a remote host by advertising a window size of zero. Once a zero window size advertisement has been received a host can no longer send data. A host may not, under any circumstances, send data with byte sequence numbers greater than the sum of the remote acknowledgment number and the remote window. Under normal circumstances the remote window can be thought of as a buffer where out-ofsequence segments are held temporarily awaiting the filling in of gaps in the sequence when delayed data turns up. Window size is not negotiated. It is up to the sender not to over-run the receiver's buffers. A small sender buffer constraint will only mean that the sender cannot take full advantage of the receiver's buffering capabilities. The following portion of a byte stream is broken into segments as indicated below. It is here assumed that sequence numbering starts at zero

6 The building up of a copy of the byte stream by the receiver is shown below. The dotted box shows the receiver window. The following steps are shown 1. Segment 1 has arrived at the receiver which acknowledges it by sending an ACK segment with ACK=1000 and WIN=1600. Since ACK+WIN=2600 the sender can send segments 2,3 and 4. Segments 2 and 3 are sent. 2. Segment 3 has arrived but segment 2 has been delayed. The receiver sends another ACK segment with ACK=1000 and WIN=1600. The sender sends segment Segment 4 has arrived but segment 2 is still outstanding. Again the receiver sends ACK=1000, WIN=1600. However the sender cannot send segment 5 since it would take the sent sequence number to 2800 which is greater than ACK+WIN. The sender cannot do anything further unless 1. Segment 5 is split into smaller segments to use up the remaining part of the window. This leads to the silly window syndrome. 2. There is a time out. 3. Segment 2 reaches the receiver and the receiver announces a new ACK value. 4. The delayed segment 2 now reaches the receiver which sends ACK=2400 and WIN=1600 allowing the sender to send up to The initial values of the sequence numbers are exchanged during the connection establishment sequence. The flow control mechanism shown above is usually called a sliding window protocol. The numbered packets used by X.25 are also handled in this fashion, - 6 -

7 however in X.25 the numbering is applied on a per packet basis rather than a per byte basis. A receiver is not required to explicitly and separately acknowledge every incoming segment. A receiver may typically wait up to 200 ms before sending an acknowledgment, this can be troublesome for interactive applications. Acknowledgments can, of course, be included in the return data flow. If a receiver has advertised a window size of zero as a flow quenching mechanism, it will subsequently "open" the window by sending a further ACK with the updated window value, this is known as a window update, it need not necessarily carry any data. A particular problem arises if the window update is lost, this problem is handled by the sender sending periodic probes as determined by the persist timer. Such probes will include the next character which the receiver can discard by not acknowledging. Opening a TCP connection A TCP connection is opened by a three-way handshake to establish a common view of the sequence numbers. A connection will be initiated by an active client, the other end of the connection is described as the passive client, although in terms of the client/server software model this is likely to be a server. The passive client should be in a state known as LISTEN which simply means that it is expecting an incoming connection request. The three way exchange involves the active client sending a SYN segment with the sequence number set to an arbitrary value (J). The passive client responds with a SYN segment with the acknowledgment number set to J+1 and the sequence number set to a further arbitrary value (K). The active client responds to the SYN segment by sending an ACK segment with the acknowledgment number set to K

8 The "arbitrary" initial sequence number is required (by RFC 793) to increment approximately every 4 µs, this avoids delayed segments from a previous connection getting mixed up with a new connection. The initial sequence number will wrap in about 4½ hours. Once a connection is established the sequence numbers can wrap much more quickly depending on traffic and line speed. Closing a TCP connection The orderly close down of a TCP connection requires the four way exchange illustrated in the diagram below. At the active end the application initiates the closure sequence, possibly by a close() system call on a socket. At the passive end receipt of the FIN segment causes the software to pass an "end-of-file" indication to the server software. It should be noted that the exchange is really two independent exchanges and it is possible to close the connection in one direction but not the other. This is known as a half close. The following example (due to Stevens) demonstrates the use of the halfclose

9 TCP link states The behaviour of a TCP connection can be shown using a state transition diagram such as that shown below. The dashed lines show the normal transitions for a server and the heavy lines show the normal states for a client. The TIME_WAIT state is also sometimes known as the 2MSL state

10 Alternative Version of TCP States

11 SDL Related Tips and Tricks Add On Document to Follow