(After returning from travel, first complete the remaining two Labs in this series ╰(￣▽￣)╭)
After completing Lab 4, congratulations, you have crossed the peak of this course and completed the main implementation of the transport layer TCP protocol. The remaining two Labs look down and implement some functions on the network layer and link layer, as shown in the figure below in the handout.
After implementing the first 4 Labs, we have been able to construct a complete TCP packet by ourselves. To transmit this packet to another terminal, there are several ways in practice:
- TCP-in-UDP-in-IP . Linux provides the interface UDPSocket , the user only needs to submit the load data, and the packaging work of all layers is completed by the system. So we can send our TCP packets in UDP packets using this interface.
- TCP-in-IP . Send TCP packets directly in IP datagrams. Linux provides TUN, the user needs to submit the complete IP package, and the link layer package is completed by the system. Note that the implementation of TCP to IP packet packaging has been provided in the code of the course group, and it has also been used in the test of Lab 4.
- TCP-in-IP-in-Ethernet . Linux also provides TAP, the user directly submits the complete frame of the link layer, and the system is responsible for receiving and sending. This is the way we will use in the Lab of these two sections, that is, to implement some functions on the network layer and link layer by ourselves.
Specifically, what this section wants to implement is an interface NetworkInterface between the network layer and the link layer to solve the problem of sending and receiving data packets. In the next section, we will continue to use this interface to implement the routing function of the network layer.
There is a corresponding relationship between the IP address of the network layer and the MAC address of the link layer. When the source host does not know the MAC address corresponding to the destination IP address of an IP datagram, it should broadcast an ARP request through the ARP address resolution protocol . After the request is received, an ARP reply is generated, notifying itself of its MAC address, and the source host receives the reply and records the corresponding relationship to form an ARP cache. The cache is also time-sensitive. The specific content of the ARP protocol can refer to Wikipedia .
There are 3 interface functions to be implemented this time:
-
Send :
void NetworkInterface::send_datagram(const InternetDatagram &dgram, const Address &next_hop). Packs
an IP datagram into an Ethernet frame . The so-called sending is the same as before, just push the frame into . If the corresponding MAC address is not known, the ARP protocol mentioned above should be used to broadcast the ARP request and store the IP datagram temporarily. Packets requesting a MAC address for the same IP address must be at least 5 seconds apart before being resent.InternetDatagramEthernetFrame_frames_outnext_hop -
Receive :
optional<InternetDatagram> NetworkInterface::recv_frame(const EthernetFrame &frame).
Receive an Ethernet frame, if it is parsed as an IP datagram, take out the content and return; if it is ARP, record the mapping relationship between the IP and MAC address of the source host, if the queried IP address is itself, then generate an ARP reply. The validity period of the record is 30 seconds , and it will be discarded when it expires. -
Time update:
void NetworkInterface::tick(const size_t ms_since_last_tick). Same passive time perception as previous Lab.
The code can be implemented according to the logic, there is no pitfall, just put the link directly:
network_interface.hh
network_interface.cc
Customs clearance screenshot:
