网络仿真器与可靠传输

1. Description

In this project you will implement a network emulator and add reliable transfer to your file transfer in the previous assignment. As with the first programming assignment, you are to work in teams and write your code in C or C++.

1.1. Network Emulator

For this programming assignment you will create a network emulator, which delivers packets between sender(s) and requester(s) you created for the first programming assignment. Your senders and requesters will have additional requirements to support the network emulator.

The network emulator will receive a packet, decide where it is to be forwarded, and, based on the packet priority level, queue it for sending. Upon sending, you will delay the packet to simulate link bandwidth, and randomly drop the packet to simulate a lossy link.

There will be three priority levels, and there will be a separate sending queue for each priority level. Each queue will have a fixed size. If the outbound queue for a particular priority level is full, the packet will be dropped. Higher priority packets arealways forwarded before lower priority packets.

---

1.2. Reliable Transfer

To acheive the reliable transfer, the requester will advertise a window size to the sender with the request packet. The sender will send a full "window" of packets and wait for ACKs of each packet before sending more packets. After a certain timeout, the sender will retransmit the packets that it has not received an ack for.

2. Details + Requirements

2.1. Forwarding Encapsulation/ Packet structure

In order to implement priority levels and forwarding, you will encapsulate the packet type from programming assignment one inside a new packet.

---

                       --------------------------------------------------------------------------- ... –---

                      |  8 bit   | 32 bit src | 16 bit src | 32 bit dest | 16 bit dest | 32 bit | payload|

                      | priority | IP address |  port      | IP address  |    port     | length |        |

                       --------------------------------------------------------------------------- ... –---                                                     

Essentially, you are adding an 8-bit priority, a 32-bit source IP address, a 16-bit source port, a 32-bit destination IP address, a 16-bit destination port and a 32-bit length to the front of the packet layout from 分布式文件传输. Compare this with how UDP datagrams are encapsulated inside IP datagrams (which are then encapsulated in a layer 2 protocol, such as Ethernet). The length field of the outer packet is set to: inner packet header size + inner packet payload size.

Note that:

• Valid values for priority levels are:

1.     0x01 - highest priority

2.     0x02 - medium priority

3.     0x03 - lowest priority

• For the ack packet the packet type will be A (capital a) and the sequence field will contain the sequence number of the packet that is being acked.
• All the packets sent by the requester should have priority 1.
• The priority of the END packet is same as the other packets in the flow.

---

2.2. Logical Functions of Emulator

The logical functions of the emulator consist of路由，排队和发送功能, 以及logging. Each sub-function is detailed below. 

The logical functions depend on the static forwarding table provided to the program through a file. The file should contain lines in the format below, with space as delimiter between the various fields:

<emulator> <destination> <nexthop> <delay> <loss probability>

• emulator is a "<Host name> <Port>" pair that identifies the emulator for which the current entry is associated with,
• destination is a "<Host name> <Port>" pair that identifies the destination of the packet,
• next hop is a "<Host name> <Port>" pair that identifies the next entity to forward the packet to,
• delay value is in milliseconds, and
• loss probability is in percentage.

Here is an example：

路由is based on a static forwarding table that you provide to your program through the file described above. The destination of an incoming packet is compared with the destination in the forwarding table to find a match. If a match is found, the packet is queued for forwarding to the next hop. If a match is not found, the packet is dropped and the event is logged (see logging below).

The emulator reads this file once it starts running and then only refers to its version of the file in memory for every packet. The emulator ignores lines in the table that do not correspond to its own host name and port. Note that emulator, sender, and requester are all uniquely identified with a "<Host name, Port>" pair and thus multiple of them can run on the same host.

The 排队功能should examine the priority field on the packet and place the packet in the appropriate queue. All the three queues are of fixed size. This queue size is specified on the command line to the emulator at start up. If a queue is full, the packet is dropped and this event is logged .

The 发送功能 accepts packets from the three queues defined above and simulates network link conditions for each destination. Packets bound for a destination are first delayed to simulate link bandwidth. The delay is defined in the forwarding table and is specified in milliseconds. After a packet has been delayed, it may be dropped to simulate a lossy link based on the loss probability provided in the forwarding table, and the event is logged. If a packet is not dropped, it is then passed to the network.

fnction is integral to all functions of the emulator. A packet may be dropped in the emulator in the routing function, the Logging Any and all packet drop events must be logged to a file. Loss events must provide a textual reason for the loss (e.g., "no forwarding entry found", "priority queue 1 was full", "loss event occurred.") Each log event must include the source host name and port, the intended destination host name and port, the time of loss (to millisecond resolution), the priority level of the packet, and the size of the payload.

---

2.3. Forwarding Summary

The order of processing should be similar to the following. Your program can simply follow the steps below in an infinite loop and no threading is required for this assignment. Note that logging is not an explicit part of this sequence.

1.     Receive packet from network in a non-blocking way. This means that you should not wait/get blocked in the recvfrom function until you get a packet. Check if you have received a packet; If not jump to 4,

2.     Once you receive a packet, decide whether packet is to be forwarded by consulting the forwarding table,

3.     Queue packet according to packet priority level if the queue is not full,

4.     If a packet is currently being delayed and the delay has not expired, goto Step 1.

5.     If no packet is currently being delayed, select the packet at the front of the queue with highest priority, remove that packet from the queue and delay it,

6.     When the delay expires, randomly determine whether to drop the packet,

7.     Otherwise, send the packet to the proper next hop.

8.     Goto Step 1.

---

2.4. Reliable transfer

The procedure is as follows:

• Upon receipt of a request packet, the sender sends a full window of packets at the rate specified by the user.
• The sender keeps this set of data in a buffer, and keeps a timeout for each of the packets. If it does not receive an ack for a packet and its timeout expires, it will retransmit that packet. The timeout is fixed and is specified by the one of the sender's parameters.
• If an ack is not received after re-transmitting the packet 5 times, the sender will print an error stating that it gave up on the packet with that specific sequence number, and continue with the next packets.
• Once all packets of that window have been acked the sender sends another window of packets.
• The requester should have a buffer and make sure that it prints the data in the file in the order of the packets' sequence numbers. It should also make sure that it does not print duplicate packets into the file.
• The requester acks every packet that it receives, even if it has already written that packet to the file.

---

2.5. Specification

he network emulator should be invoked in the following way:

 emulator -p <port> -q <queue_size> -f <filename> -l <log>

• port is the port of the emulator.
• queue_size is the size of each of the three queues.
• filename is the name of the file containing the forwarding table in the format specified above.
• log is the name of the log file.

The network emulator must implement the routing, queueing, sending, and logging logical functions described above. You must be able to forward through one or multiple emulators (ex. sender to emulator1 to emulator2 to requester). If you have implemented your emulator correctly, this is automatically satisfied.

Note that your emulator should NOT drop END packets. This is because testing is made harder when END packets get dropped.

Note that the following requirements for your sender and requester are in addition to requirements stated for programming assignment 1.

You will have to modify your sender to be invoked as follows:

 sender -p <port>-g <requester port> -r <rate> -q <seq_no> -l <length>   -f <f_hostname> -h <f_port> -i <priority> -t <timeout> 

• f_hostname is the host name of the emulator.
• f_port is the port of the emulator.
• priority is the priority of the sent packets.
• timeout is the timeout for retransmition of lost packets in "miliseconds".

The behavior of the sender should be modified to:

1. Always start at sequence number 1
2. Increment the sequence number by 1 for each packet, instead of by the packet length,
3. Print out observed percentage of packets lost. The loss rate that the sender prints out is not necessarily the same as the loss rate that we identify in the forwarding table since the sender might miss some ACKs. This loss rate is computed based on number of retransmissions divided by total number of transmissions (normal + retransmission)

You will have to modify your requester to be invoked as follows:

 requester -p <port> -f <f_hostname> -h <f_port> -o <file option> -w <window>

• window is the requester's window size.

The (inner)length field of the request packet will be filled with this window size so that the sender can extract and use this value for sending.

You will also have to modify your requester to:

1. Verify that the destination IP address in the packet is indeed its own IP address, and
2. Suppress display of individual DATA packet information.