COMS3200
代写c++ | 作业security | Network | 作业Data structure | 作业network | quiz | java | oop | 作业Python | assignment代写 | ios | IT代做 – 这个题目属于一个Python的代写任务, 是有一定代表意义的c++/security/Network/Data structure/network/java/oop/Python/ios/IT等代写方向, 这个项目是assignment代写的代写题目
The University Of Queensland
School of Information Technology and Electrical Engineering
Semester One, 202 1
COMS3200 - assignment
Introduction
This assignment introduces the use of network Layer and Link Layer (from OSI Models) as well as socket programming (simulation) on each of these devices: adapters, switches and routers. After finishing the assignment, you will understand how data is sent throughout the internet.
This assignment contains three parts. For Part A and B, you will need to subm IT your answers through Blackboard Quiz. for Part C, you will submit your code via COMS3200 subversion (SVN). All submitted works are marked automatically. It is strongly recommended that you read this spec carefully before you start working, as to avoiding any mistakes.
This assignment is to be your individual work. Using answers (or code) that you did not calculate (or write) is against course rules and may lead to a misconduct charge.
Part A ( 21 marks)
Answer each of the following questions in the associated quiz on Blackboard, following the specified instructions. All answers will be automatically marked.
You have established a new server for COMS3200 Inc, called RUSHBSvr (in assignment 1). It works perfectly and has grown so much in users recently that the company must now upgrade their network.
You, a supervisor of this project, has assigned the task of designing two (2) new networks, a branch in Sydney and a local system for working at home. You also moved the File Server to
somewhere on the Internet to serve as a centralise data centre for your company. Then, you ended up with the network map on next page.
To minimise spending for this system, you set up for only one DNS Server (D2) and one DCHP Server (D1). You claimed that the system will run smoothly without paying more for building extra servers, and it works.
Figure 1. A simple internet map
You are now required to explain to your colleagues how your system works with some
scenar ios given below. You can use these assumptions to support your answers:
- The broadcast MAC address of all the LANs is FF:FF:FF:FF:FF:FF.
- All forwarding tables in the switches and routers are up to date.
- All valid protocols are HTTP, FTP, SSH, DNS, DHCP, UDP, TCP, ICMP, SNMP, ARP, OSPF, and BGP. If there are 2 protocols used at the same time (e.g., SSH and TCP), choose the lowest level (highest layer) only (e.g., SSH).
- D2 is a DNS Server, and D1 is a DHCP Server.
You will have to fill out the table and answer some questions in Blackboard. Each student s
questions will have different values (that is replaced by XXX ... ). Your question values will
be shown in the quiz. Please be careful to double-check before submitting your work to
Blackboard, as you can submit only once.
Task: Answer the questions below on Blackboard.
Question 1: Host A just joined the network and currently does not have an IP address. Please
complete the following table describing the four packets that will be transmitted through the
Server S
L
…
Internet
Host C
R2-LAN 1
AP 2
DHCP Server (D1)
Host B
AP 1
Host A
DNS Server (D2) (^) R1-LAN 1 AP 2 – Internet 2 AP 1 – Internet 1
Switch 2 Switch 1^
Switch 3^
R1-LAN 2
network upon this event (in the order they were sent), assuming that all requests succeed,
and Host A ends up with IP address XXX.XXX.XXX.XXX.
Protocol Opcode
Source
MAC address
Destination
MAC address
Source (or sender)
IPv4 address
Destination (or
target) IPv4 address
Question 2: After ending up with the IP address above, Host A wants to send a standard
DNS query to the DNS Server. Host A has already gotten the IPv4 addresses of the DNS
Server and its gateway router from the DHCP Server. Router 1s ARP table contains all
hosts IP and MAC addresses in the network, and all other ARP tables are empty. Complete
the following table describing the first four packets transmitted through the network upon
this event, and no additional ongoing communications.
Protocol Opcode
Source
MAC address
Destination
MAC address
Source (or sender)
IPv4 address
Destination (or
target) IPv4 address
Question 3: Host A now wants to establish a HTTP connection with the Server S (see the
figure 1 above). You may assume that Host A knows Ss IP address and that all ARP tables
contain all required information to transmit any packet. Complete the following table
describing the packets that are sent to transmit Host As request to initialise the connection,
assuming the request is being sent from TCP port XXXX and the following available port
number in Router 1s NAT table is XXXX. Give the TCP flags as an 8-bit binary number
representing the CWR to FIN flags.
Protocol (^) FlagsTCP TCP PortSource^ Destination TCP Port Source IPv4 address(or sender )^ targetDestination ) IPv4 address(or^ TCP TCP Question 4: In addition to the connection described in question 3, Host Bs port XXXX is also currently connected to S. What are the contents of the NAT table in R1 while these connections remain alive? (if a new port is required, use port XXXX).
LAN IP LAN Port WAN IP WAN Port
Question 5: Suppose X sent a packet with the destination IP address XXX.XXX.XXX.XXX and destination MAC address XX:XX:XX:XX:XX:XX. What network devices (hosts, servers, routers, switches) in the above diagram would receive this packet? If you received the IP
address of 255.255.255.0 and MAC address of FF:FF:FF:FF:FF:FF, thus its the boardcast message.
Question 6: Server S sends a packet with the destination IP address XXX.XXX.XXX.XXX. What network devices (hosts, servers, routers, switches) in the above diagram would receive this packet?
Part B ( 9 marks)
Answer each of the following questions in the associated quiz on Blackboard, following the specified instructions. All answers will be automatically marked.
In this part, you will need to use Wireshark to analyse a packet capture file, named a 2 .pcap.
This packet capture shows a client connecting to a LAN network, then a traceroute command being run from the client. Some of the relevant IETF RFCs may help you in understanding the following questions. In particular:
- RFC 2131 for Dynamic Host Configuration Protocol (DHCP)
- RFC 791 for Internet Protocol (IP)
- RFC 1034 for Domain Name System (DNS)
- RFC 6747 for Address Resolution Protocol in IPv4 (ARP) This is a real-life scenario Wireshark trace and has been updated to the newest protocol. We recommend you to ask any questions you may have for this trace besides the given questions to provide you with more understanding of how LAN networking works. You need to be familiar with using the Wireshark filter feature to answer these questions.
Task: Answer the questions below on Blackboard.
Question 1: The client joined the LAN networking successfully. What is the assigned IP address from the DHCP Server to this client? (1 mark) Question 2: What is the MAC address of the client? (1 mark) Question 3 : What is the netmask of this LAN network? (1 mark)
Question 4 : What is the DHCP Servers IP address? (1 mark) Question 5: What is the MAC address of the DHCP Server? (1 mark) Question 6 : Is this LAN network a subset of a bigger LAN network? (1 mark) Question 7 : What is the target IP address of the traceroute command? (1 mark)
Question 8 : Does the traceroute command run successfully, or give up while waiting for an ICMP response? (1 mark) Question 9 : How many routers are there between the host (where it runs the traceroute command) and the target server? (1 mark) Question 10 (bonus): The client connects to the LAN network through a password enabled wireless connection, what is the security standard used for this Access Point? (1 mark)
Hints:
- For each TTL, traceroute sends the packet 3 times.
- The DHCP Server is attached to another device.
- Please use the Wireshark filter where appropriate.
- Available security standards you can choose are WPA/WPA2 (personal or enterprise), WEP, and WPA3.
Part C ( 70 marks)
Your company is doing well thanks to your RUSHBSvr. Due to a network upgrade in Sydney, your superiors want a new protocol because they feel the current protocols are too cumbersome and complicated. As seen in Figure 1, the RUSHBSvr is now located somewhere else on the Internet, and you are tasked with setting up the protocols needed to exchange data with the server.
To accomplish this part, you will need to implement two virtual protocols: RUSHBAdapter on the link layer, and RUSHBSwitch on network/transport layer protocol. Virtual^ means that your program is simulating those protocols in the application layer; that is, network layer addresses will not correspond to physical interfaces.
Again, this is an individual assignment. You can feel free to discuss aspects of socket programming and the specification with fellow students. Directly helping (or seeking help from) other students with the actual coding of your solution is considered cheating, as well as looking at another students code (even if its in printed or in electronic form). All of your submitted code will be subject to automated checks for plagiarism and collusion on moss and detected plagiarism or collusion will be reported for misconduct proceedings. If youre having trouble, please seek help from a member of the teaching staff. Dont be tempted to copy another students code, and dont commit any code to your repository unless its your work.
Simulation
You need to implement two programs in this part, RUSHBAdapter and RUSHBSwitch, representing the link and network layer RUSHB protocols respectively. You have already implemented the application layer RUSHB protocol, RUSHBSvr. Since this a simulated network, they are all implemented in the application layer of the OSI model of networking in practice (see figure below).
OSI MODEL RUSHB MODEL (SIMULATION)
LINK LAYER Ethernet
LINK LAYER &
NETWORK LAYER
RUSHBSwitch
NETWORK LAYER IP
TRANSPORT LAYER UDP/TCP
RUSHBAdapter
APPLICATION LAYER (^) HTTP/… APPLICATION LAYER (^) RUSHBSvr/… Figure 2. Network layers mapping
RUSHBAdapter and RUSHBSwitch
RUSHBAdapter is supposed to work as an adapter for one process only through TCP (e.g. RUSHBSvr). The process that connects to RUSHBAdapter needs to open a socket under localhost (127.0.0.1) as a listener under an available port (assigned by the kernel). However, in this assignment, your RUSHBAdapter is not required to listen to any processes, instead, it will listen to your stdin (see the figure below).
RUSHBSwitch works like a network router, and it can be local or global. A local RUSHBSwitch can listen to many RUSHBAdapter through a UDP and connect to many global RUSHBSwitches through TCP. In the meantime, the global RUSHBSwitch cannot listen to any RUSHBAdapter, but can connect to other RUSHBSwitches. This is a diagram explaining how RUSHBAdapters and RUSHBSwitches are connected:
Figure 3. End-to-end connection in RUSHB
local global
global local
stdin
stdout
The final goal for this programming assignment is sending and receiving data across the global network without losses and errors. Data can be anything that can attached to the adapter, such as netcat, or RUSHBSvr, or even stdin (as in this assignment). From now, we will refer to RUSHBAdapter as the adapter and RUSHBSwitch as the switch.
[Adapter Invocation]
The adapter takes the following command line arguments (in order):
- the port number of the switch that will connect to in UDP protocol For example, if the switch is listening on an UDP port 5678, then the adapter runs as:
Python python3 RUSHBAdapter.py 5678
java java RUSHBAdapter 5678
C or c++ ./RUSHBAdapter 5678
[Greeting Protocol]
When first executing, the adapter will make a greeting protocol to the switch through a UDP port number to get its local IP address, each of the greeting packets is in the structure below. We will define each block of a packet has a total of 4 bytes (32 bits).
BIT 0 8 16 24
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
RESERVED (all 0s) MODE
ASSIGNED IP ADDRESS
Figure 4. Greeting structure in RUSHB
MODE = 0x01: DISCOVERY
MODE = 0x02: OFFER
MODE = 0x03: REQUEST
MODE = 0x04: ACKNOWLEDGE
Figure 5. MODE instruction in RUSHB
Figure 6. Then greeting process between RUSHBAdapter and RUSHBSwitch
RUSHBAdapter RUSHBSwitch
DISCOVERY
REQUEST
OFFER
ACKNOWLEDGE
We call RUSHBSwitch in the case above is the host, and RUSHBAdapter is the client. It will work as follow:
- In a DISCOVERY message, since the sender has not know its IP address in the host network yet, then SOURCE IP ADDRESS and ASSIGNED IP ADDRESS should be left at 0x00000000 (let the host fill out the assigned IP address).
- The OFFER from the host contains the ASSIGNED IP ADDRESS, and the SOURCE IP ADDRESS is the address of the switch itself, but the DESTINATION IP ADDRESS should be left at 0x00000000 (since the client has not accept the offer yet).
- After receiving the offer from the host, your adapter (or switch for the upcoming part) now send back the request for the assigned IP address. The REQUEST should contains the value of DESTINATION IP ADDRESS and ASSIGNED IP ADDRESS, while SOURCE IP ADDRESS should be left at 0x00000000.
- The host sends back an acknowledgement message with all the fields must be filled.
The client must send a discovery message when first connected to the switch, and the host must send back the assigned IP address if there are spaces for the client to join in the network. After receiving an acknowledgment from the host, the client should remember its IP address and the router IP address for the upcoming event.
[IP Address Allocation]
Your assigned IP addresses with CIDR notation and IP addressing allocation in the subnet must follow the guideline of RFC 1518 and RFC 1519. To be clear, CIDR notation must be valid with the associated IP address. For example, with 192.168.0.1/24, the switch IP address is 192.168.0.1, the next available IP address in this subnet should be 192.168.0.2, and the total hosts can be accepted in this subnet is 254.
If there are more than 254 hosts connected to your switch, your switch should ignore the incoming connections and not giving the [Greeting Protocol] stated in page 7.
[Adapter Commandline Interface]
After finishing the greeting protocol, your adapter should print out (to stdout) the character > followed by a white space, to tell the user that it is ready for user commands.
For example, if you make your program using C99, and you want to type HELLO_WORLD as a command: ./RUSHBAdapter 5678
HELLO_WORLD
The commandline interface for the adapter will only accept the command send with usage:
> send {receiver_ip_address} {message}
Where {receiver_ip_address} is the IP address of the receiver and {message} is the message that you want to send (separated with a white space). For example, if you want to send HELLO_WORLD to the IP address 130.102.71.65, then you would use the command:
> send 130.102.71.65 HELLO_WORLD
To process the user command, your adapter will build a packet with the structure in figure
- For example, your adapter was assigned with IP 192.168.0.2 from the host (from 192.168.0.1) and sends HELLO_WORLD to 130.102.71.64, your adapter need to send to 192.168.0.1 with MODE 0x05 in figure 8 below.
BIT 0 8 16 24
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
RESERVED (all 0s) MODE
DATA
Figure 7. Data structure in RUSHB
BIT 0 8 16 24
192.168.0.
130.102.71.
0x000000 0x
HELLO_WORLD
Figure 8. An example of data packet
Please remember, the network byte order is defined to always be big-endian, and it may differ from your host. After processing a command from a user, your adapter should print out the character > followed by a white space again for the next command.
When your adapter receives an EOF (end of file) from any file or socket descriptors, it should do nothing, not accepting input anymore, and works their jobs normally insteads of early exit.
[Data Communication]
The adapter should also be able to receive the packet from its connected switch (in the network). The switch will ask if your adapter is available to receive the packets before sending them. The querying packet will be sent with the structure in figure 9 with MODE 0x06. For example, the packet will be sent as in figure 10.
BIT 0 8 16 24
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
RESERVED (all 0s) MODE
Figure 9. Querying structure in RUSHB
BIT 0 8 16 24
192.168.0. 1
192.168.0.
0x000000 0x0 6
Figure 10. An example of query packet
Your adapter (or client) will respond with MODE 0x07 to tell the server that it is ready to receive the packets (see figure 11 and 12). This is also applied for the transmission between 2 switches, the sender switch will send the packet with MODE 0x06, and the receiver switch
will reply back with MODE 0x07. However, when an adapter sends a message to a switch, it will not need to ask if it is available.
BIT 0 8 16 24
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
RESERVED (all 0s) MODE
Figure 11. Response structure in RUSHB
BIT 0 8 16 24
192.168.0. 2
192.168.0. 1
0x000000 0x0 7
Figure 12. An example of response packet
Then, the sender will send packets to the client with MODE 0x05. The receiver needs to print out the data it received. For example, if a host from 130.102.71.64 sends HELLO_WORLD after the query protocols established, the sender will send the packet as in figure 11. Please note that even though the switch that sends the message to the adapter has an IP address 192.168.0.1, the source IP address in the packet is still 130.102.71.64, as it is the origin of the packet.
BIT 0 8 16 24
130.102.71.
192.168.0.
0x000000 0x
HELLO_WORLD
Figure 1 3. An example of data packet from a global host
When receive the data packet, your adapter should print out to stdout in this form: Received from {source_ip}: {data}\n
For example, with the packet above, the adapter will print this out with a newline: Received from 130.102.71.65: HELLO_WORLD
There are few things you need to remember for sending and receiving packets:
- Your program should remove the characters > before print out the received message, then, it should print the characters > again for the next user command.
- We send and receive messages through the port number in the localhost (127.0.0.1), and assuming that the port number is in link layer of RUSHB Models.
- Your switch wont have to send the checking packets (mode 0x06 and 0x07) again if the checking protocol already done within 5 seconds. After 5 seconds of the checking protocols, if there is an upcoming packet, your switch has to establish the checking protocol again.
- If any packets that are not in the given protocols or invalid, your adapter and switch should ignore them. Mode 0x06 and 0x07 are available for sending data packets (mode 0x05, 0x0a and 0x0b) only.
[Switch Invocation]
The switch will take the following command line arguments (in order):
- the type that the switch will be (either local or global)
- the IP address with the CIDR notation indicating its subset
- (optional for local) the second IP address with the CIDR notation indicating its subset
- the latitude of the switch in the map
- the longitude of the switch in the map
To simply the calculations, latitude and longitude are denoted as the positive integers, represent the coordinates on a cartesian plane, where latitude is horizontal x-axis and longitude is the vertical y-axis.
Figure 14. End-to-end connection with the areas
The switch invocation will have three modes:
- If you want to run the switch in local mode that initially has one listening socket on a UDP port for adapters (the blue area in figure 1 4 ), with the LAN IP address is 192.168.0.1/24, and at the location is (2, 5), then the execution is:
Python python3^ RUSHBSwitch.py^ local^ 192.168.0.1/24^ 2 5^
Java java RUSHBSwitch local 192.168.0.1/24^ 2 5^
C or C++ ./RUSHBSwitch local 192.168.0.1/24^ 2 5^
local global
global local
- If you want to run the switch in local mode with two listening socket, one is for the local adapters through a UDP port, and another one in a global area that listen in the TCP port for other switches (the red area in figure 1 4 ), with the LAN IP address is 192.168.0.1/24, the global IP address is 44.45.46.0/ 8 , and at the location is (140, 26), then the execution is:
Python python3 RUSHBSwitch.py local 192.168.0.1/24 44.46.46.0/ 8 140 26
Java java RUSHBSwitch local 192.168.0.1/24 44.46.46.0/ 8 140 26
C or C++ ./RUSHBSwitch local 192.168.0.1/24 44.46.46.0/ 8 140 26
- If you want to run the switch in global mode (the yellow area in figure 1 4 ), with the global IP address is 172.64.2.1/ 16 , and the location is (465, 784) then the execution is:
Python python3 RUSHBSwitch.py global 172.64.2.1/16 465 784
Java java RUSHBSwitch global 172.64.2.1/ 16 465 784
C or C++ ./RUSHBSwitch global 172.64.2.1/ 16 465 784
Your program should print out the port number to stdout with a new line. For the switch
listening in both TCP and UDP ports, it should print port on UDP first, and then TCP. It
should also print out (to stdout) the character > followed by a white space, to tell the user
that the adapter is ready for user commands.
There are some examples of the switch invocation:
- The switch is local and listening on a UDP port, the kernel gives it port number 4455 : python3 RUSHBSwitch.py local 192.168.0.1/24 2 5 4455
- The switch is local and listening on both UDP and TCP ports, the kernel gives it a port number 4455 for TCP and 6677 for UDP: python3 RUSHBSwitch.py local 192.168.0.1/24 22.23.24.1/24 2 5 6677 4455 >
- The switch is global and listening on a TCP port, the kernel gives it port number 1234 : python3 RUSHBSwitch.py global 1.2.3.1/24 456 789 1234
[Switch Connection]
With any incoming connection requests from the adapters or other switches, your switch must
be able to run the [Greeting Protocol] that stated on page 7; also, your switch needs to give
each of them the smallest available IP address based on its netmask and the running
connections. For example, if an adapter connecting to your switch with host IP address is
19 2.168.0.1, and there are two adapters currently connecting, then the available IP address
that you will give to the incoming adapter is 192.168.0. 4 as in the figure 15 below.
BIT 0 8 16 24
192.168.0. 1
0x
0x000000 0x
192.168.0. 4
Figure 1 5. An example of the offering message
[Switch Commandline Interface]
The command line for the switch (not applicable for the local switch listening on both UDP
and TCP) accepts the command connect with usage
> connect {port_number}
where {port_number} is the TCP port number of the host switch it want connects to. When
the command executed, your switch will connect to that port. Then, it sends a greeting
protocol as same as the [Greeting Protocol] defined in page 7. The switch receives the
connect command (or first establish the connection) will sends the greeting message first.
Figure 1 6. The greeting protocol between a local switch and a global switch
connect
./RUSHBSwitch
44.45.46.01/
./RUSHBSwitch
192.168.0.1/
OFFER 44.45.46.
REQUEST 44.45.46.
ACKNOWLEDGE 44.45.46.
192.168.0.1 44.45.46.
44.45.46.01 ??
(^) (^) RUSHBSwitch RUSHBSwitch DISCOVERY
REQUEST
OFFER
ACKNOWLEDGE
After finishing the greeting between switches, your switch also needs to send a message to tell its location, in MODE 0x08, and within the structure below.
BIT 0 8 16 24
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
RESERVED (all 0s) MODE
LATITUDE LONGITUDE
Figure 1 7. Location packet in RUSHB
BIT 0 8 16 24
44.45.46.
44.45.46.
0x000000 0x0 8
2 5
Figure 1 8. An example of location packet
The receiver switch will reply them to tell you where it is (see an example in the figure below).
BIT 0 8 16 24
44.45.46.
44.45.46.
0x000000 0x
465 784
Figure 1 9. An example of location packet
When receiving a location packet, your switch should broadcasts the information about the distance of the new neighbour, to the current neighbours (see figure 20). To calculate the distance between you and the new connecting switch, we use this formula:
= +(!")!+(!")! In the example above the distance will be calculated below, and rounded down:
= +( 465 2 )!+( 784 5 )!= 906. 20 906 The broadcast message will be sent in the structure in figure 20 with MODE 0x09, but with the distance added with the distance from the source switch to the destination switch. Suppose you received a packet in figure 19 , you have connected to a router with IP address 47.48.49.01, your IP address is 47.48.49.0 2 in that network, the distance between you and the host is 94 , then the message you will send to 47.48.49.01 will be in figure 21.
BIT 0 8 16 24
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
RESERVED (all 0s) MODE
TARGET IP ADDRESS
DISTANCE
Figure 20. Broadcasts message in RUSHB
BIT 0 8 16 24
47.48.49.0 2
47.48.49.0 1
0x000000 0x0 9
4 4.45.46.
1000
Figure 21. Example of broadcast message
15
If your switch received a packet with MODE 0x09, you also need to broadcast that message
to all your neighbours except the one in SOURCE IP ADDRESS, DESTINATION IP
ADDRESS or TARGET IP ADDRESS. Please remember that you only can broadcast the
message to other switches if they are connecting with you. The switch will not send the
boardcast message to its adapters.
There are few things about commandline and broadcasting message that you need to know:
- For the local switch that listening on both UDP and TCP, it wont accept the connect command, thus if user input a connect request, it should do nothing.
- After a command from a user, your program should prints out the character > followed by a white space for the next input. If it receives any packet with MODE 0x09 with distance larger than 1000, your switch should ignores that packet.
- We assume that all the switch will have a different CIDR IP address, as well as its range, for example, if there exists a switch with IP address 42.43.44.1/8, then, there will be no other switches that has the IP address start with 42 .XXX.XXX.XXX/8, this also be applied for the local networks.
- If your switch receives the same MODE 0x09 packet (same SOURCE IP ADDRESS, DESTINATION IP ADDRESS and TARGET IP ADDRESS) but the distance is larger, then it should ignore that paket (and not sending to neighbours).
In the case of a switch that connects to a local switch listening on both UDP and TCP
(invocation 2 ); after the greeting protocols, local switch then sends a distance packet of its
UDP side to the new connected switch with the target IP address is the IP address of the
switch in the UDP side. The distance field of the packet is the distance from the local switch
to the new connected switch. For example, if switch A connects to switch B (local swtich) as
in the figure below. After the greeting protocols and the location exchange, B then sends a
distance packet to tell A that the distance from A to 10.0.0.1 is 10, suppose that the distance
between A and B is 10.
BIT 0 8 16 24
47.48.49.0 1
47.48.49.0 2
0x000000 0x
10.0.0.
10
connect
./RUSHBSwitch local
44.45.46.01/24 10.0.0.1/ ...
./RUSHBSwitch global
192.168.0.1/ ...
OFFER 44.45.46.
REQUEST 44.45.46.
ACKNOWLEDGE 44.45.46.
192.168.0.1 44.45.46.
44.45.46.01 10.0.0.
DISTANCE OF 44.45.46.
…
DISTANCE OF 10.0.0.
A B
B
A
Figure 2 2. Example of distance packet
When your switch receives an EOF (end of file), your switch (or adapter) need to handle it by stop accepting more user commands, but still works other jobs (such as packet transmisting and packet processing) as normal.
[Fragmentation]
If your switch receives a data packet (MODE 0x05) with the total size larger than 1500 bytes (including header) as in figure 2 2 , it must:
- Splits the packet by smaller chunks with the maximum size of 1500 bytes
- Send the chunks with MODE 0x0a (more fragments coming), and the last chunk with mode 0x0b (last fragment packet) with the structure as same as in figure 2 3. Remember that, before sending any packet with mode (0x0a, 0x0b and 0x0b), it needs to establish the query to ask if the receiver is ready to receive or not (see [Data Communication] in page 9-10).
- Set-up an offset, from the second packet.
BIT 0 8 16 24
192.168.0.
192.168.0. 3
0x000000 0x
A x
Figure 2 3. A 2012 bytes data packet
BIT 0 8 16 24
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
OFFSET MODE
DATA
Figure 2 4. Fragmentation in RUSHB
For the data packet in figure 2 3 , your switch must splits it into 2 packets:
BIT 0 8 16 24
192.168.0.
192.168.0. 3
0x000000 0x0a
A x 1488
Figure 2 5. A 1500-bytes data packet
BIT 0 8 16 24
192.168.0.
192.168.0. 3
0x0005d 0 0x0b
A x 512
Figure 2 6. A 524 - bytes data packet
As you can see, packet in figure 2 6 has an offset of 0x5d 0 ( 1488 in decimal), denotes that
the data in this packet starts at index 1488.
When your adapter receives the message with mode 0x0a it should wait for the next packets
until receives packet mode 0x0b. Then, it prints to stdout the data it received (as normal).
For the example above, your adapter will print out:
Received from 192.168.0.2: AAA………AAAA with 2000 letter As. Fragmentation is applicable for the switches only. Also, the adapters could send any packets with the maximun size of 55296 bytes.
[Forward]
If your switch receives data messages (0x05, 0x0a and 0x0b), it should forwards the message to another routers until it reached the destination, with these conditions:
- The router that receives the forward message has to be one that could form a shortest path (based on the distances) to the destination.
- Every message must follow the [Data Communication] in page 9.
- If the router that receives the a message and its IP address is the same as the destination IP address as in the packet, it should print to stdout the message it received, as same as [Data Communication] in page 10.
- If your switch doesnt know the existance of the destinations IP address, it will forward the message to the longest prefix matching of the next switch IP address^ (Kurose, p.344, 4.2.1).
- In case of 2 paths that have the (same) shortest distance to the destination, your switch must sends the message to the switch that has the longest prefix matching (Kurose, p.344, 4.2.1). This is only applicable for the case your switch knows the existance of the destinations IP address, if not, rule number 4 must be applied.
In the example below, A wants to send to B a message, and we assume that all routers in a network have their IP address and distances assigned in the figure 2 4. Then, the message will be forwarded in each switch within the green line to get to the destination.
Figure 26. End-to-end connection with the IP addresses and distances
In the case of a coming data packet with the destination IP address is 129.0.0.1 and:
- Your switch doesnt have any information about the destination IP address from the boardcast messages.
A 192.168.0.1^ 1.2.3.^
1.2.3.
2.3.4.
2.3.4.
3.4.5.
3.4.5.
5.6.7.
5.6.7.
7.8.9.1 1
7.8.9.
7.8.9.
(^) 7.8.9. 9.10.11. 9.10.11. 9.10.11. 9.10.11. 10.0.0. 10.0.0. 15 10 70 25 5 95 (^5 )
B^
A (^) B
- Your switch is connecting to a switch has an IP address of 135.0.0.1 and a switch has an IP address of 136.0.0.1. Your switch should sends the message to the switch that has an IP of 135.0.0.1 since it matches the longest prefix of the IP address (1000 0001 and 1000 0111 rather than 1000 0001 and 1000 1000).
We assume that the connection between switches is from the left-hand side to the right-hand side, in the other words, the message will always start from Adapter A to Adapter B as in figure 26. Only when B received the message from A, then B can send the message back to A using the same path used from A to B.
You are free to implement any algorithms you would like to, but your adapter and switch must not send any extra packets than the packets that have stated above, as well and making extra files for the communication between your programs. Also, all the programs must be thread-safe, if race-condition occurred in some tests, you might get 0 for them. As long as your program works as expected, you will receive full marks for that part.
Submission
Your programs must be written in Python, Java, C, or C++. Your program should be able to be invoked from a UNIX command line as follows. It is expected that any Python programs can run with version 3.6, any Java programs can run with version 8, any C programs have to be complied with the standard of C99 or GNU99. No external libraries or extensions is permitted for use in your program.
Python
python3 RUSHBAdapter.py {port}
python3 RUSHBSwitch.py {local|global} {ip} [optional_ip] {x} {y}
Java
make
java RUSHBAdapter {port}
java RUSHBSwitch {local|global} {ip} [optional_ip] {x} {y}
C or C++
make
./RUSHBAdapter {port}
./RUSHBSwitch {local|global} {ip} [optional_ip] {x} {y}
Figure 8. Filename and Command-Line syntax for the submission
No late submissions will be marked for this assignment under any circumstances. Submission must be made electronically by committing using subversion. In order to mark your assignment, the markers will check out /trunk/ass 2 / from your repository on
source.eait.uq.edu.au. Please do not create subdirectories under /trunk/ass 2 /. The marking may delete any such directories before attempting to compile. Code checked in to any other part of your repository will not be marked.
IMPORTANT NOTICE: As the assignment is auto-marked, it is very important that the filename and command-line syntax exactly matches the specification above. Specification adherence is critical for passing. If your program is failed to executed because of the wrong syntax, you will receive a 0 for the assignment without any exceptions.
Marking
Marks will be awarded for functionality only. The tests will mostly check your programs behaviour and packet structure.
Provided that your code compiles (see above), you will earn marks based on the number of features your program correctly implements. Partial marks may be awarded for partially meeting the functionality requirements. Not all features are of equal difficulty. If your program does not allow a feature to be tested, you will receive 0 marks for that feature, even if you claim to have implemented it. For example, if your program can never open a file, we cannot determine if your program would have loaded input from it. The markers will make no alterations to your code (other than to remove code without academic merit). Your program should not crash or lock up/l oop indefinitely (without any reason). Your program should not delay for unreasonably long times.
For RUSHBAdapter:
- execute and run (5 marks)
- send and receive packet (5 marks)
- packet build and protocols ( 5 marks)
- command line interface (5 marks)
For RUSHBSwitch:
- execute and run ( 10 marks)
- ip validation capacity (5 marks)
- send and receive packet (5 marks)
- packet build and protocols ( 10 marks)
- command line interface (5 marks)
For the combination of 2 or more processes:
- message transmission in a simple map ( 5 marks)
- complete transmission in a big map ( 10 marks)
Specification updates
It is possible that this specification contains errors or inconsistencies, or missing information. It is possible that clarifications will be issued via the course website. Any such clarifications posted five (5) days or more before the due date will form part of the assignment specification. If you find any inconsistencies or omissions, please notify the teaching staff.
Tips and hints
- Start your assignment early.
Updates
0.1 Initial release
0.2 Add clarification and edit part B
0.3 Edit part B
0.4 Add clarification
0.5 Add clarification
0.6 Add clarification
0.7 Add clarification for Fragmentation
0.8 Add clarification for EOF
0.9 Add clarification for Routing
1.0 Add clarification and edit part A
1.1 Fix typos
1.2 Fix typos
- 3 Fix typos 1.4 Add clarification and edit Marking