COMS3200 Assignment 2 2023S1
100 total marks, 25% overall course mark
•This document is subject to change for the purposes of clariﬁcation. 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
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 ﬁle is located under Assessment =⇒Assignment 2 =⇒Part B: Packet capture
There is no time limit to submit these answers. For the same reasons as speciﬁed 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.
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
eﬃcient routing algorithms.
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.
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 Oﬀer 0x02
Oﬀset Mode Request 0x03
More Fragments 0x0A
Last Fragment 0x0B
Every packet contains Source IP, Destination IP, Mode, Oﬀset and Data ﬁelds. The value in the Mode ﬁeld
is dependent on the packet type. The use cases of each packet type will be detailed in coming sections. The
Data ﬁeld is of variable length and can be omitted entirely in some situations.
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
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.
The switch takes the following commandline arguments in order:
•Its type (local/global)
•Its IP address(es) with CIDR notation
where the latitude and longitude are positive nonnegative integers no greater than 32767.
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
$ ./ 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
$ ./ RUSHBSwitch local 192.168.0.1/24 184.108.40.206/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
$ ./ RUSHBSwitch global 220.127.116.11/24 50 20
If the incorrect number of arguments are given, or any argument is invalid in any way, the switch will exit
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 ﬁrst.
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 :
- If all connections are taken, then the switch will stop responding to incoming connections.
4.4.7 Location Exchange
As soon as the Greeting Protocol is ﬁnished, the client switch will send the host switch a Location packet
(Mode = 0x08). The Source IP ﬁeld will be the allocated IP address of the client switch; the Destination IP
ﬁeld will be the global IP address of the host switch and the Oﬀset ﬁeld will be 0. The ﬁrst two bytes of the
Data ﬁeld will be the latitude of the client switch and the second two bytes of the Data ﬁeld will be the longi-
tude of the switch. The Data ﬁeld must be four bytes long.
The host switch will then reply to the client with a Location packet. The Source IP ﬁeld will contain the
global IP address of the host switch; the Destination IP ﬁeld will contain the allocated IP address of the client
switch and the Oﬀset ﬁeld will be 0. The ﬁrst two bytes of the Data ﬁeld will contain the latitude of the
host switch and the second two bytes of the Data ﬁeld will contain the longitude of the host switch. Again,
the Data ﬁeld must be four bytes long.
Below are depicted two packets you may see as part of a location exchange:
0x000000 0x08 0x000000 0x08
0x04D2 0x11D7 0x0539 0x01A4
Longitude 4567Latitude 1337
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 ﬁeld will contain the global IP address of the switch which received the
Location packet; the Destination IP ﬁeld will contain the global or assigned IP (whichever applicable) of the
neighbour which the packet will be sent to and the Oﬀset ﬁeld will be 0. The ﬁrst four bytes of the Data
ﬁeld 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 speciﬁed in
the Destination IP ﬁeld.
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 speciﬁed in the Data ﬁeld 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 speciﬁed in the Source IP and Data ﬁelds. The Data ﬁeld 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 speciﬁed 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:
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
speciﬁed in the Destination IP ﬁeld. 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
•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 preﬁx of the destination IP address should receive the
•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 preﬁx 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 ﬁrst send the adapter a Query
packet (Mode = 0x06). The Source IP ﬁeld contains the local IP of the switch; the Destination IP ﬁeld contains
the IP address of the adapter and the Oﬀset ﬁeld is 0. The Data ﬁeld is omitted entirely.
When an adapter receives the Query packet it will respond with a Ready packet (Mode = 0x07). The Source
IP ﬁeld contains the IP address of the adapter and the Destination IP ﬁeld contains the local IP address of
the switch. Again, the Oﬀset ﬁeld is 0 and the Data ﬁeld 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 ﬁeld contains the IP address of the adapter which originally sent the data.
The Destination IP ﬁeld contains the IP address of the receiving adapter and the Data ﬁeld 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:
18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52
184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124
0x000000 0x05 0x000000 0x06 0x000000 0x07 0x000B88 0x05
Hello World Hello World
received by switch
sends Query to
to the switchSwitch forwards
Data packet to
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
Oﬀset ﬁeld of each fragment will take the value of the oﬀset 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 ﬁelds 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
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 Oﬀset values 0 and 1476 respectively. Following this it would
send a Last Fragment packet with 104B of data and an oﬀset of 2952.
More Fragments and Last Fragment packets are able to be forwarded the same as Data packets in Section
Some fragments you may see in the example described above are depicted below:
126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11
18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52
0x000000 0x05 0x000000 0x0A 0x0005C4 0x0A 0x000B88 0x0B
A x 3000 A x 1476 A x 1476 A x 104
Original Data packet
en route to
184.108.40.206First fragment to
220.127.116.11Second fragment to
18.104.22.168Last fragment to
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
ﬁeld is equal to their global or local IP), the below is displayed to the switch’s stdout :
: where is given by the Source IP ﬁeld of the packet and is given by the Data ﬁeld 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 ﬁeld. •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 diﬀerent 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 ﬁnishing 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 ﬁeld will contain the IP address allocated to the adapter by the switch and the Destination IP ﬁeld will contain the IP address speciﬁed in the command. The Oﬀset ﬁeld will be 0 and the Data ﬁeld will contain the message speciﬁed 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 ﬁrst 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 ﬁeld. •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 Makeﬁle. 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 ﬁles (.py, .c, .h, makeﬁle) 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 deﬁnitely be opposite to your machine’s endianness, and is diﬀerent 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 ﬁles in a zip ﬁle. This zip ﬁle must not contain subdirectories. This zip ﬁle must be named A2_sxxxxxxx.zip , where the sxxxxxxx is your student ID. This zip ﬁle 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