The Norwegian text is authoritative, this translation is provided for your convenience.

Transcription

1 Contents 1 INF3190 Home exam 2 in English Formalities Exercise Details You shall deliver the following: Regarding the points allocation: Specific code requirements Oracle sessions and admin queries Deliverable Electronic delivery INF3190 Home exam 2 in English The Norwegian text is authoritative, this translation is provided for your convenience. 1.1 Formalities Graded assignment worth approx 20% of final grade. Must be completed individually. Evaluated according to how well the requirements listed under "Exercise" are fulfilled. 1.2 Exercise The goal of the exercise is to implement MIPTP, a transport protocol for reliable data transfer over MIP, and a simple application that uses MIPTP. MIPTP is based on the oblig; if you have implemented home exam 1, it should automatically be possible to send data between any pair of hosts using MIPTP. Without home exam 1 MIPTP only works between directly connected neighbours. That s fine, but perhaps a bit boring :) You shall write three programs: 1. A transport daemon, which runs permanently on all hosts. This daemon can: Receive data, a port number and a destination MIP address over IPC using a Unix-domain socket from an application running on the same physical host (using socket functions such as send/recv). The daemon adds a header to the data and sends the entire 1

2 MIPTP packet through its local MIP daemon to the MIPTP daemon running on the destination host. Receive MIPTP packets from the MIP daemon and pass data on to an application listening on a local Unix-domain socket via blocking recv (or similar). Packets are ignored ("dropped") if there is no application waiting for data from the network. The port numbers discriminate between several applications on the same host. For simplicity s sake we will assume that source and destination applications use the same port number for a given transfer. The transport daemon is given a timeout value in seconds as a command line argument. If the transport daemon is run in debug mode (also a CLI argument), each communication event is to be logged to the console along with relevant status information (packets sent/received, current window sizes, etc.) 2. A file transfer server, that receives files over IPC from its local MIPTP daemon and writes them to the filesystem with incremental filenames (e.g. receivedfile1, receivedfile2,... ). Each transfer starts with two bytes that contain the size of the file. One port number that the server will listen on is specified as a command line argument. NB: the port number used by the server must match that of the client. This means listening on two ports enables the reception of two files simultaneously. The file transfer server shall not communicate directly with the MIP daemon, only with the MIPTP daemon. 3. A file transfer client, that reads a file from the filesystem and sends the size of file in bytes (max ) as a two byte long message followed by the actual file (over IPC to the local MIPTP daemon, which sends it along). The filename, destination MIP address and port number are specified as command line arguments. The file transfer client shall not communicate directly with the MIP daemon, only with the MIPTP daemon. It must be possible to transfer to files from the same source host to the same destination host simulatenously using two clients and server instances Details The MIPTP daemon prepends the MIPTP header before data is sent over the network. The header contains two "Padding Length" (PL) bits, a port 2

3 number and a packet sequence number. The MIPTP header looks like so: The header is in big endian format, just like everything else in MIPTP (and MIP). If a MIPTP packet contains no data, then it is only an acknowledgement packet ("ACK"). It asserts having received all packets up to the specified sequence number. "Payload Length" in the MIP header of an ACK packet has the value 1. Since the largest possible packet that can be sent over Ethernet has the length 1500 bytes, the largest possible data payload that can be sent in a MIPTP packet is 1492 bytes (1500 minus the length of MIP and MIPTP headers). The length of the MIPTP payload in bytes can be computed using the value specified in the MIP "payload length" header field: it is (MIP payloadlength - 1) * 4. Example: a packet of total length 16 bytes (including 4 bytes MIP header and 4 bytes MIPTP header) has a MIP payload length value of 3, and contains (3-1) * 4 = 8 bytes of data after the MIPTP header. Since the length of all MIP packets must be divisible by 4, problems can arise if the length of the MIPTP payload does not result in such a packet. If the size of the payload is not divisible with 4, one must add 1, 2 or 3 bytes at the end of the packet that are not really part of the payload. These bytes are zeroed and are called "padding". The PL field (2 bits) contains the length of padding in the packet. For example, a 16 byte packet that contains only 5 bytes of payload data contains 8 bytes following the headers. Of these 8, the last three are "padding". They are to be zeroed, and the value of the PL field shall be 3 (binary 11). A MIPTP sender implements the Go-Back-N strategy using a fixed window size of 10 packets to transfer data. The sequence numbers represent packets, i.e. packet 1 is numbered 0, packet 2 is numbered 1 and so on. If no ACK packet is received within a given time out, all packets that have not previously been acknowledged are assumed to be lost and they are retransmitted. A MIPTP receiver passes on data in order to the application listening on the port specified in the packet header. If packets arrive at the MIPTP daemon in the wrong order, this signifies packet loss or reordering in the 3

4 network. The MIPTP receiver shall in such cases not acknowledge anyting and may discard these packets. NB: it is possible that the operating system may reorder packets when sending in rapid succession. This can be avoided by waiting a short while (e.g. 10ms) using sleep in between each packet transmission You shall deliver the following: 1. A design document containing: A cover page stating your candidate number, title of the exercise, course code and semester. We must not receive names or usernames. Detailed answers to the following questions: What problem occurs in case two files are sent simultaneously from two different sources to the same destination using port 30? Why? How can this problem be solved? How is the problem solved on the Internet, e.g. with respect to a web server which listens on the same port (80) irrespective of where connections are coming from? How can the time out value be computed automatically, so that it need not be specified as a command line argument? How the program is designed. Preferably a (flow) diagram demonstrating the order of execution. Documentation of how to run and stop the programs. A list of source files. Any other peculiarities. 2. The source code, commented as necessary, as well as a README file briefly documenting how to run the programs. Document all variables and definitions. For each function in the program, document the following: What the function does What in and out parameters mean and are used for Which global variables the function modifies What the function returns 4

5 1.2.3 Regarding the points allocation: No points will be awarded for oblig code that is to be reused as is (i.e. the ping applications). Bonus points: It is not very efficient that the receiver drops packets that arrive in the wrong order. Bonus points will be awarded if rather than dropping them, the receiver instead inserts such packets in the appropriate position within a receive buffe. Further bonus points will be awarded if this is combined with a Selective Repeat mechanism instead of Go-Back-N to improve the performance of the system Specific code requirements Your code shall be compiled and tested on the same VM as used in the oblig Oracle sessions and admin queries Check the FAQ, ask on Piazza and make good use of the oracles. Admin queries go to inf3190-admin@ifi.uio.no 1.3 Deliverable The design document shall be edited using some appropriate tools, e.g. L A TEX, OpenOffice, Word, etc. The document must contain all required details, as well as the cover page. Before delivery the document must be converted to PDF format. The document does not necessarily need to be long, but must contain sufficient information to fulfill the requirements described in the "exercise" section above. What matters is to document understanding of the themes the assignment touches on, in addition to the actual execution. We expect a clean and structured document. 1.4 Electronic delivery Exams are anonymous. Use the idchecker.sh script to scan for your name and username. The entire deliverable should be handed in electronically. Collect all files (Makefile, source code, README, design doc, etc) in a one directory named 5

6 after your candidate number. Compress the directory into a tarball and submit it on Devilry. We recommend you download your delivery and test that it contains the correct files and generally is functional. You should also deliver drafts in good time before the deadline in case of last minute technical issues or mistakes. Delivery deadline: Friday April 27Th, 23:59. This is a hard deadline, any delivery made later will be given the grade F, fail. Self-reported sick leave is not admissible. You are expected to read and understand the UiO exam rules. 6