COMS3200 Comptuer Networks I Assignment 2: RUSHBSwitch - Network Router in the Application Layer
COMS3200 Assignment 2 2023S1
100 total marks, 25% overall course mark
1 Preface
1.1 Notes
•This document is subject to change for the purposes of clarification. Changes made since the original
release will be highlighted in red.
•Please post any questions on the course Ed stem page.
1.2 Revision History
•4 May, 2023: Version 1.0 Released.
2 Part A: Problem Solving Questions
This section is worth 25% of the assignment.
The question set is located on Blackboard under Assessment =⇒Assignment 2 =⇒Part A: Problem solving
questions.
There is no time limit to submit these answers. Due to the widespread brute-forcing of answers on the previ-
ous assignment, only two resubmissions are permitted but working is not required. Only the last submitted
attempt will be marked.
3 Part B: Wireshark Questions
This section is worth 25% of the assignment.
This section covers DHCP, IP, DNS and ARP.
The question set is located on Blackboard under Assessment =⇒Assignment 2 =⇒Part B: Wireshark
questions and the capture file is located under Assessment =⇒Assignment 2 =⇒Part B: Packet capture
File.
There is no time limit to submit these answers. For the same reasons as specified within part A, only two
resubmissions are permitted. Only the last submitted attempt will be marked.
4 Part C: Socket Programming
This section is worth 50% of the assignment.
4.1 Goals
You will implement a simulation of a network router in the application layer in Python 3 or C.
This will operate as part of a larger communication system named RUSHB.
This system has a strong emphasis on transmitting data using structured packets, address allocation and
efficient routing algorithms.
4.2 Programs
RUSHB is comprised of two main programs: RUSHBAdapter and RUSHBSwitch. From here onwards, RUSH-
BAdapter processes are referred to as adapters and RUSHBSwitch processes are referred to as switches.
Adapters accept input from stdin and transmit this to one corresponding switch over UDP.
Switches can take three forms: local, global and mixed. Local switches open a listening socket on UDP to serve
adapters and can connect to global and mixed switches over TCP. Global switches open a listening socket on
TCP to service incoming connections with other switches, and can also create outgoing connections to other
global/mixed switches. Mixed RUSHBSwitch processes open a listening socket on both UDP and TCP for serv-
ing incoming connections from adapters and global/mixed switches respectively, and can also create outgoing
connections to other global/mixed switches. This is illustrated in the diagram below:
Code for the RUSHBAdapter is provided, and you do not need to create it yourself. You are required to imple-
ment the RUSHBSwitch only.
All adapter and switch processes maintain a virtual IP address used to distinguish each other apart. Adapters
and local switches will maintain virtual local IP addresses and global switches will maintain virtual global
IP addresses. Mixed switches will maintain a virtual local IP for their local side (facing adapters only) and a
virtual global IP (facing other switches only). It is important to note that these addresses are virtual and are
not indicative of their real IP addresses. All processes will be run on Moss.
2
4.3 Packet Structure
All communications to and from adapters and switches follow the required packet structure detailed below:
Bit 0816 24 Mode Value
Source IP Discovery 0x01
Destination IP Offer 0x02
Offset Mode Request 0x03
DataAcknowledge 0x04
Data 0x05
Query 0x06
Ready 0x07
Location 0x08
Distance 0x09
More Fragments 0x0A
Last Fragment 0x0B
Every packet contains Source IP, Destination IP, Mode, Offset and Data fields. The value in the Mode field
is dependent on the packet type. The use cases of each packet type will be detailed in coming sections. The
Data field is of variable length and can be omitted entirely in some situations.
4.4 RUSHBSwitch
4.4.1 High-Level Overview
The switch acts like a network router. It can take three forms: local, global and mixed. Local switches open
a listening socket on UDP to serve adapters and can connect to global and mixed switches. Global switches
open a listening port on TCP to service incoming connections with other switches, and can also create outgoing
connections to other global/mixed switches. Mixed open listening sockets on both UDP and TCP for servicing
incoming connections from adapters and switches respectively, and can also create outgoing connections to
global/mixed switches. By connecting adapters to local and mixed switches, we can simulate a local area
network, and by connecting global and mixed switches, we can simulate large scale wide area networks with
geographical proximity.
Switches use virtual IP addresses to identify themselves. Local and global switches have one IP address and
mixed switches have two IP addresses; one for their local UDP side and one for their global (TCP) side.
4.4.2 Invocation
The switch takes the following commandline arguments in order:
•Its type (local/global)
•Its IP address(es) with CIDR notation
•Its latitude
•Its longitude
where the latitude and longitude are positive nonnegative integers no greater than 32767.
3
The below commands are used to start a local switch:
$ python3 RUSHBSwitch .py local ip_address / cidr latitude longitude
$ ./ RUSHBSwitch local ip_address / cidr latitude longitude
for example:
$ ./ RUSHBSwitch local 192.168.0.1/24 50 20
The below commands are used to start a mixed switch:
$ python3 RUSHBSwitch .py local local_ip_address / cidr global_ip_address / cidr latitude longitude
$ ./ RUSHBSwitch local local_ip_address / cidr global_ip_address / cidr latitude longitude
for example:
$ ./ RUSHBSwitch local 192.168.0.1/24 130.102.72.10/24 50 20
The below commands are used to start a global switch:
$ python3 RUSHBSwitch .py global ip_address / cidr latitude longitude
$ ./ RUSHBSwitch global ip_address / cidr latitude longitude
for example:
$ ./ RUSHBSwitch global 130.102.72.10/24 50 20
If the incorrect number of arguments are given, or any argument is invalid in any way, the switch will exit
immediately.
As soon as the switch process starts it should open the necessary TCP and UDP ports. The ephemeral port
should always be used, and the port assigned by the kernel should be immediately displayed to stdout on its
own line. Mixed switches should display their UDP port first.
4.4.3 Commandline Interface
After opening the required ports, local and global (but not mixed) switches will be able to create outgoing
connections to other switches. This is done by typing the below command into stdin :
connect
- If all connections are taken, then the switch will stop responding to incoming connections.
5
4.4.7 Location Exchange
As soon as the Greeting Protocol is finished, the client switch will send the host switch a Location packet
(Mode = 0x08). The Source IP field will be the allocated IP address of the client switch; the Destination IP
field will be the global IP address of the host switch and the Offset field will be 0. The first two bytes of the
Data field will be the latitude of the client switch and the second two bytes of the Data field will be the longi-
tude of the switch. The Data field must be four bytes long.
The host switch will then reply to the client with a Location packet. The Source IP field will contain the
global IP address of the host switch; the Destination IP field will contain the allocated IP address of the client
switch and the Offset field will be 0. The first two bytes of the Data field will contain the latitude of the
host switch and the second two bytes of the Data field will contain the longitude of the host switch. Again,
the Data field must be four bytes long.
Below are depicted two packets you may see as part of a location exchange:
130.102.72.8 130.102.78.1
130.102.78.1 130.102.78.8
0x000000 0x08 0x000000 0x08
0x04D2 0x11D7 0x0539 0x01A4
Latitude 1234
Longitude 4567Latitude 1337
Longitude 420
4.4.8 Distance Relaying
Whenever a switch receives a Location packet, it will inform all other neighbouring switches of the Euclidean
distance (rounded down) from the new switch to the respective neighbour.
The switch will send a Distance packet (mode = 0x09) to every connected switch except that which sent it
the Location packet. The Source IP field will contain the global IP address of the switch which received the
Location packet; the Destination IP field will contain the global or assigned IP (whichever applicable) of the
neighbour which the packet will be sent to and the Offset field will be 0. The first four bytes of the Data
field will contain the assigned IP of the switch which sent the Location packet and the second four bytes will
contain the distance from the switch which sent the Location packet to the neighbouring switch specified in
the Destination IP field.
Switches must maintain a record of the shortest path to every other known switch. When a switch receives a
Distance packet, if the distance to the switch specified in the Data field is less than its current record, then
that record will be updated to the new shortest distance. That switch will then also send a Distance packet
to each neighbouring switch except those specified in the Source IP and Data fields. The Data field will con-
tain the same target IP, but will contain the distance from the target IP to the respective neighbour (i.e. the
original distance plus the distance to the respective neighbour).
If the distance specified in the packet is greater than or equal to the existing distance record, or if the distance
is greater than 1000, the switch will do nothing.
Below is depicted a packet you might see as part of a distance relay after the location exchange depicted
in the previous section:
130.102.72.1
130.102.78.2
0x000000 0x09
130.102.72.8
0x00001034
Distance 4148
6
4.4.9 Data Forwarding
Data is sent from adapters to switches and other adapters in Data packets (Mode = 0x05). Upon receiving
a Data packet, the switch will have to forward it to other switches/adapters until it reaches the destination
specified in the Destination IP field. These conditions must be followed when deciding which connection to
forward the packet to:
•If the packet is intended for an adapter which the switch is connected to, it will forward the packet to
that adapter.
•If the switch is aware of the existence destination IP address, it should forward the packet to whichever
connection is on the shortest geographical path to the destination.
•If two or more neighbouring switches are on paths of the same shortest length to the destination, the
switch amongst these with the longest matching prefix of the destination IP address should receive the
packet.
•If the switch is unaware of the existence of the destination IP address, it should forward the packet to
whichever of its neighbouring connections has the IP address with the longest matching prefix with the
destination IP address.
4.4.10 Transmitting Data to Adapters
If a local/mixed switch receives data to transmit to a connected adapter, it must first send the adapter a Query
packet (Mode = 0x06). The Source IP field contains the local IP of the switch; the Destination IP field contains
the IP address of the adapter and the Offset field is 0. The Data field is omitted entirely.
When an adapter receives the Query packet it will respond with a Ready packet (Mode = 0x07). The Source
IP field contains the IP address of the adapter and the Destination IP field contains the local IP address of
the switch. Again, the Offset field is 0 and the Data field is omitted entirely.
Once the switch has received the Ready packet, it will transmit the data to the adapter using Data pack-
ets (Mode = 0x05). The Source IP field contains the IP address of the adapter which originally sent the data.
The Destination IP field contains the IP address of the receiving adapter and the Data field contains the data.
If the switch receives more data to forward to the adapter, it can forward it to the adapter immediately so long
as it has not been 5 seconds since the last Ready packet was received. If it has been more than 5 seconds, the
adapter must be sent another Query packet and the switch must await another Ready packet before forward-
ing the data to the adapter.
Below is depicted some packets which may be seen as part of an adapter query:
130.102.72.2 130.102.72.1 130.102.72.2 130.102.72.2
130.102.78.8 130.102.78.2 130.102.78.1 130.102.78.8
0x000000 0x05 0x000000 0x06 0x000000 0x07 0x000B88 0x05
Hello World Hello World
Data packet
received by switch
130.102.72.1
for adapter
130.102.72.2Switch
130.102.72.1
sends Query to
130.102.72.2Adapter
replies Ready
to the switchSwitch forwards
the original
Data packet to
the adapter
7
4.4.11 Data Fragmentation
In the event that a switch receives a Data packet with a total size greater than 1500B (including the header),
and the switch is not the intended recipient of the data, it must fragment the data across multiple packets
such that no packet exceeds a total size of 1500B (including the header). Each fragment except the last will
have the mode 0x0A (More Fragments) and the last fragment will have the mode 0x0B (Last Fragment). The
Offset field of each fragment will take the value of the offset within the original data where that fragment’s
data begins. Each More Fragments packet must contain as much of the data payload as possible. The Source
IP and Destination IP fields will contain the addresses of the original packet. These fragments can then be
forwarded instead of Data packets as per Sections 4.4.9 and 4.4.10 to the required neighbouring switch or
adapter.
For example, if a switch were to receive a packet with 3000B of data, then it would forward two More Frag-
ments packets with 1476B of data each and the Offset values 0 and 1476 respectively. Following this it would
send a Last Fragment packet with 104B of data and an offset of 2952.
More Fragments and Last Fragment packets are able to be forwarded the same as Data packets in Section
4.4.9.
Some fragments you may see in the example described above are depicted below:
130.102.72.3 130.102.72.3 130.102.72.3 130.102.72.3
130.102.78.8 130.102.78.8 130.102.78.8 130.102.78.8
0x000000 0x05 0x000000 0x0A 0x0005C4 0x0A 0x000B88 0x0B
A x 3000 A x 1476 A x 1476 A x 104
Original Data packet
received from
130.102.72.3
en route to
130.102.78.8First fragment to
forward to
130.102.72.8Second fragment to
forward to
130.102.72.8Last fragment to
forward to
130.102.72.8
4.4.12 Displaying Received Data
If a switch receives Data, More Fragments or Last Fragment packets intended for it (i.e. the Destination IP
field is equal to their global or local IP), the below is displayed to the switch’s stdout :
Received from
: where is given by the Source IP field of the packet and is given by the Data field of the packet. If the data in question arrives in several fragments, the above message is displayed only after all fragments are received and the original data has been reassembled. 4.4.13 Miscellaneous Notes •The switch will ignore any packets with an invalid Mode field. •If the switch receives a Data packet or Fragment intended for a nonexistent switch or adapter, it will still forward it based on the rules in Section 4.4.9. •Switches and adapters will never exit, and so you do not have to handle receiving EOFover a socket. •If a switch receives EOFfrom stdin , it should stop handling commands but should still process incoming packets and will not exit. •We will assume that all switches will have a different IP address and CIDR such that no two switches or adapters will have the same IP address. 8 4.5 RUSHBAdapter 4.5.1 High-level Overview The adapter connects to one local switch process over UDP. It takes input from stdin to transmit from the switch and displays data received from the switch to stdout . You are not required to implement the adapter, and it will be provided to you. 4.5.2 Invocation The adapter is started using the below command: $ python3 RUSHBAdapter .py port where port is the UDP port number of the local/mixed switch it will connect to. 4.5.3 Greeting Protocol and IP Address Allocation As soon as the adapter is able to open a connection with the desired switch, it will engage in the same Greeting protocol as described in Section 4.4.5. The IP address the switch will allocate to it is calculated in accordance with Section 4.4.7. 4.5.4 Commandline Interface and Sending Data After finishing the Greeting Protocol, the adapter will be able to send data to switches and other adapters. This is done by typing the below command into stdin : send where is the IP address of the adapter to send the string to. Everything after is considered as part of . The adapter will send this data in a Data packet to its switch. The Source IP field will contain the IP address allocated to the adapter by the switch and the Destination IP field will contain the IP address specified in the command. The Offset field will be 0 and the Data field will contain the message specified in the command. If too few arguments are given, or the IP address is malformed in any way, then the adapter will ignore the command and send nothing to its switch. Adapters will always send their switch all the data given by the command in one packet. There is no maximum packet size and it will not do fragmentation. 4.5.5 Querying for Data Receipt A switch which intends to forward data to a connected adapter will first query that adapter if it is ready to receive data. This process is detailed in Section 4.4.10. 4.5.6 Displaying Transmission Results When an adapter receives a Data packet from a switch, or has received all fragments which comprise a frag- mented Data packet, it will display the below to stdout : Received from : where is the IP address of the adapter which sent this adapter the string . 4.5.7 Miscellaneous Notes •The adapter will ignore any packets with an unrecognised Mode field. •Once a switch has received a Ready packet from an adapter, it will not have to send another Query packet to that adapter until 5 seconds elapse. •No extra packets except those described previously should be sent between adapters and switches. •Threadsafety is crucial to the correct operation of the switch. 9 4.6 Miscellaneous Requirements •Your code must be runnable on Moss. •If you choose to use C, you must also submit a Makefile. Your code must compile with the $ make com- mand, and must compile to the C99 standard. Code which does not compile will receive a mark of 0. •All your files (.py, .c, .h, makefile) must be within the same subdirectory. •The pipe() ,select() ,poll() and epoll() C syscalls are expressly forbidden. •The Python pipes and select modules are expressly forbidden. 4.7 Miscellaneous Notes •It is highly recommended you use C for this assignment. •All packets follow Nework Byte Order, which is always big endian. This will almost definitely be opposite to your machine’s endianness, and is different to Moss’ endianness. •Style is not assessed but it is still highly recommended that you follow some consistent style guide (e.g. KNF, PEP 8 etc). 4.8 Marking Breakdown Marks will be awarded according to the following breakdown: Validating commandline arguments 3 marks Greeting Protocol 9 marks Location Exchange and Distance Relaying 8 marks Data Forwarding 7 marks Switch Routing 8 marks Complete Communication 15 marks Total: 50 marks. 10 5 Integrity All code submissions will be checked for similarity and plagiarism. All code in your submission which was not written by you (or was written by you for a previous assignment) must be correctly referenced in IEEE format in your code. This includes code written by generative AI. 6 Submission You must submit all source code files in a zip file. This zip file must not contain subdirectories. This zip file must be named A2_sxxxxxxx.zip , where the sxxxxxxx is your student ID. This zip file must be submitted to the course Blackboard page under Assessment =⇒Assignment 2 =⇒Part C: Code Submission. 7 Resources These resources may be of use to you: •Joyce, P. (2022). Sockets. In: C and Python Applications. Apress, Berkeley, CA. https://doi-org.ezproxy.library.uq.edu.au/10.1007/978-1-4842-7774-4_6 •Socket Programming HOWTO, available at: https://docs.python.org/3/howto/sockets.html •Socket Programming with Multi-threading in Python, https://www.tutorialspoint.com/socket-programming- with-multi-threading-in-python •The Linux Manual Pages 11
