data留学生程序讲解、C/C++编程调试、辅导c++程序 讲解Database|辅导Python程序

日期：2021-03-24 08:17

The University Of Queensland
School of Information Technology and Electrical Engineering
Semester One, 2021
COMS3200 - Assignment 1
Due: 3:00pm 24th March, 2021
Marks: 100
Weighting: 20% of your final grade
Revision: 1.1
Introduction
This assignment introduces the Network Edge & Core, the top three Networking layers (from
OSI models) such as Application Layer, Transport Layer, and a small part of Network Layer.
After finishing the assignment, you should be able to distinguish between Packet and Circuit
Switching, understand End-to-End Delay, be able to interpret and analyse network packets
and do network programing.
This assignment contains three (3) parts. For Part A and B, you will need to submit you
answers through Blackboard Quiz. for Part C, you will submit your code via COMS3200
subversion (SVN). All submitted works are marked automatically. And it’s strongly
recommended that you have read this spec carefully before start working, as 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 (30 marks)
Answer each of the following questions in the associated quiz on Blackboard, following the
specified instructions. All answers will be automatically marked.
The figure below illustrates a simple network map that included two (2) edges: Local Network
(grey area) and Global Network (white area).
In Local Network, the three (3) circuit switches: SC1, SC2 and SC3 are interconnected by
two (2) links: LC1 and LC2. Each of these circuit links has three (3) slots. The hosts are each
directly connected to one of the switches. In this part, we only need to know the
communication scenario between Host A and Host B. The network has reserved one slot on
each of the two links. In the figure below, the dedicated end-to-end connection uses the second
slot in both links LC1 and LC2 (see the red coloured line).
We assume that device C is the combination of modem and router in the Local Network, are
connected together and connect to SC3 through LC3. The data transmission from device C
in Local Network through L1 is considered the data from client C in the Global Network
view.
2
In Global Network, packet-switches are used in the entirety of the network. We have a
scenario where a client requests a web page from a remote server on a remote island via a
slow satellite link above the earth in a geostationary orbit. There is one (1) client C, one (1)
server S, and three (3) DNS servers: D1 is a Local DNS Server, D2 is a Root DNS Server, D3
is a Top-level Domain (TLD) DNS Server, and D4 is Authoritative DNS Server. We don’t
need to know where the Link L7 connect to in this assignment.
Figure 1. A simple Network Map
Local Network
Scenario 1 – Local Network (8 marks)
Host A sends a file of 2,880,000 bits to Host B at the time t0 = 0 mili-second (msec). Link
LC1 and link LC2 uses time-division multiplexing (TDM) with three (3) slots and have a bit
rate of 9 Mbps. It needs 500 msecs to establish an end-to-end circuit before Host A can begin
to transmit the file and the second (2nd) slot of the circuits in LC1 and LC2 is allocated for
the transmission between Host A and Host B. At the time t0 + 500 msecs, the first (1st) slot
of the circuits in LC1 and LC2 start to transmit. At the time t1, Host B has received all bits
of the file from Host A. After 200 msecs from t1, Host B sends a file of 960,000 bits to Host
A. Host A has received all bits of the file from Host B at time t2.
There are some assumptions for the Local Network:
1. There is no propagation delays in this networking.
2. There is no transmission delays between A and SC1, as well as B and SC3.
3. The network starts with no data are transmissing at the time t0 = 0.
4. The slot of the circuits is allocated for the transmission can be used in both direction.
5. All switches have no processing delays (this is unrealistic, just to simplify calculations).
Task: Answer the questions below in mili-seconds (msecs) rounded to three decimal places.
Question 1: What is the value of t1? (4 marks)
Question 2: What is the value of t2? (4 marks)
Scenario 2 – Global Network (17 marks)
A program on one of the hosts in the Local Network starts the process of retrieving a webpage
from the Server S. The following events happen sequentially:
1. At the time t0 = 0 mili-second (msec), Client C sends a DNS request to D1. D1 receives
the DNS request from Client C successfully at the time t1.
2. Right after t1 without any processing delays, D1 sends a response with Server S’s IP
address to Client C. Client C receives the DNS response from D1 successfully at the
time t2.
3. Right after t2 without any processing delays, C sends a TCP request (SYN) to open a
connection to Server S. Server S receives the TCP SYN request from Client C
successfully at the time t3.
4. Right after t3 without any processing delays, Server S acknowledges (SYN/ACK) the
TCP request and opens the connections with Client C. Client C receives the TCP
(SYN/ACK) acknowledgement from Server S successfully at the time t4.
5. Right after t4 without any processing delays, Client C sends a HTTP GET request to
Server S (which includes the ACK back to S for its SYN). Server S receives the HTTP
GET packet from Client C successfully at the time t5.
6. Right after t5 without any processing delays, Server S sends the web page to Client C,
which requires 7 packets, which includes the HTTP response plus the HTML file.
Client C receive the first (1st) packet of the HTTP response from Server S successfully
at the time t6 and the seventh (or last) packet of the HTTP response at the time t7.
7. After receiving each data packet without any processing delays, Client C sends an
ACK message back to Server S. Note that S does not need to wait for an ACK before
sending the next data packet. After receiving the last data packet acknowledgement
without any processing delays, S sends a TCP FIN packet to close the connection.
After receiving FIN from Server S without any processing delays, Client C sends one
4
FIN/ACK packet back to S. After receiving FIN/ACK without any processing delays,
S sends a final ACK packet back to C. When this final ACK packet is received at C
without any processing delays, the connection is finally closed at the time t8.
There are some assumptions for the Global Network:
1. The network is packet-switched.
2. The network starts with no other packets in queues - only packets that are a part of
this question.
3. Each link is bidirectional and can concurrently handle bits travelling in opposite
directions.
4. All required records are stored in the DNS servers.
6. C, D1 and S have no processing delays (this is unrealistic, just to simplify calculations).
5. DNS packets and TCP SYN, ACK, FIN, SYN/ACK, and FIN/ACK packets are 100
bytes long, including all headers, preamble, etc.
6. HTTP GET and HTTP response packets are 1000 bytes long, including all headers,
preamble, etc.
7. 1 Mbps = 10?6 Bps; 1 Kbps = 10?3 Bps (Bps is bits per second).
8. 1 GB = 1024 KBs; 1 KB = 1024 Bs; 1 B = 8 bs (b is bit).
Task: Answer the questions below in mili-seconds (msecs) rounded to three decimal places.
Question 1: What is the value of t1? (1 mark)
Question 2: What is the value of t2? (1 mark)
Question 3: What is the value of t3? (2 marks)
Question 4: What is the value of t4? (2 marks)
Question 5: What is the value of t5? (2 marks)
Question 6: What is the value of t6? (2 marks)
Question 7: What is the value of t7? (3 marks)
Question 8: What is the value of t8? (4 marks)
There are some information about Tranmission Links and Switches that will assist you on
finishing the task:
Tranmission Links
Link Connect Between Transmission Rate Length Propagation Speed
L1 C S1 100 Mbps 240 m 2 x 10?8 m/s
L2 S1 S2 7 Kbps 36,000 km 3 x 10?8 m/s
L3 S2 S4 100 Mbps 40 m 2 x 10?8 m/s
L4 S2 S3 100 Mbps 3,200 km 2 x 10?8 m/s
L5 S3 D1 100 Mbps 500 m 2 x 10?8 m/s
L6 S4 S 80 Mbps 60 m 2 x 10?8 m/s
Switches
Switch Link Associated Processing Delay
S1 L1, L2 1 msec
S2 L2, L3, L4 1 msec
S3 L4, L5 0.25 msec
S4 L3, L6, L7 0.25 msec
5
Scenario 3 – The Internet’s Directory Service (5 marks)
In this scenario, we now consider on the Global Network only. The following events happen
sequentially:
1. Client C sends a DNS query message of a host name to D1.
2. D1 receives the DNS message, then forward the query message to D2.
3. D2 receives the DNS message, then sends a DNS message containing the IP address of
D3 to D1.
4. D1 receives the DNS message, then sends the DNS message to D3.
5. D3 receives the DNS message, then sends a DNS message containing the IP address of
D4 to D1.
6. D1 receives the DNS message, then sends the DNS message to D4.
7. D4 receives the DNS message, then sends a DNS message containing the IP address of
the required host name to D1.
8. D1 receives the DNS message, then forwards the message to Client C.
Task: Answer the questions below.
Question 1: Which on these events above that can combined together to form an recursive
DNS query? (1 mark)
Question 2: Which on these events above can combined together to form an iterative DNS
query? (1 mark)
Question 3: In the event 3, what is the DNS record type in the message (or packet) that D2
sends to D1? (1 mark)
Question 4: In the event 5, what is the DNS record type in the message (or packet) that D3
sends to D1? (1 mark)
Question 5: In the event 8, what is the DNS record type in the message (or packet) that D1
sends to C? (1 mark)
Part B (20 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 need to know how to use Wireshark in analysing a packet capture file, names
a1.pcap. This packet capture shows a client downloading a javascript resource file from a
server. Some of the relevant IETF RFCs may help you understand more of the following
questions. In particular:
1. RFC 793 for Transmission Control Protocol
2. RFC 791 for Internet Protocol
3. RFC 2018 for TCP Selective Acknowledgment Options
4. RFC 7323 for TCP Extensions for High Performance
Wireshark displays TCP sequence numbers as a value relative to the first sequence number.
You will need to disable this to answer any questions that ask for a raw sequence number. It
is highly recommended that you turn off TCP Reassembly to understand the order of packet
transmission.
6
Task: Answer the questions below.
Question 1: What is the web browser being used by the sender? (1 mark)
Question 2: What is the web server software being used in the remote server? (1 mark)
Question 3: Is protocol offloading being used at the client? (1 mark)
Question 4: How many routers are there between the client and server? (2 marks)
Question 5: What is the raw TCP sequence number of...
a. the packet initiating the TCP connection? (1 mark)
b. the acknowledgement from the server for the above packet? (1 mark)
Question 6: In frame 4, what are the values of the 8 TCP flags (CWR to FIN) as a single 8-
digit binary number? (1 mark)
Question 7: In frame 4, the GET request is for a javascript file resource. What is the address
of the web page that requested this javascript file resource? (1 mark)
Question 8: How long should the received javascript file be considered fresh? (1 mark)
Question 9: What is the initial value of the window scale shift count indicated by...
a. the client? (1 mark)
b. The server? (1 mark)
Question 10: The GET packet from the client to the server has an advertised window size of
46. What is the true value window size in bytes? (2 marks)
Question 11: How many bytes are lost totally while tranmissing is indicated in the pcap file?
(2 marks)
Question 12: How many duplicate acknowledgments are sent by the client regarding the
missing bytes? (1 mark)
Question 13: In which frame is the lost frame retransmitted? (1 mark)
Question 14: In which frame does the receiver indicate that all missing frames have been
received? (1 mark)
Question 15: From frame 1 to 3 (inclusive), how many frames have incorrect checksum value?
(1 mark)
Hint:
1. Frame 4 shows a HTTP GET request from the client to the server, that could help
you on answering question 6,7 and 8.
2. In frame 30, some data is lost, question 11, 12, 13 and 14 are focused in the lost frames.
Part C (50 marks)
You have recently been hired by the multinational tech giant COMS3200 Inc, who have
identified your in-depth knowledge in the field of secure transport-layer protocols. You have
been tasked to develop a network server capable of sending messages to a client that comply
with the desired protocol. This part will implement a network simulation in the application
layer, called RUSHBServer.
Again, this is an individual assignment. You can feel free to discuss aspects of socket
programming and the specification with fellow students. Directly help (or seek help from)
other students with the actual coding of your solution is considered cheating, as well as looking
at another student’s code (even if it’s in printed or 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 you’re having trouble,
please seek help from a member of the teaching staff. Don’t be tempted to copy another
student’s code, and don’t commit any code to your repository unless it’s your work.
7
Simulation
Each process (a running instance) of RUSHBServer will simulate file storage server. When
your server receives a client’s file request, it should locate the requested file in its local working
directory and return the file contents over one or more packets. When complete, the server
should close the connection with the guest that have sent the file. Your server also needs to
be capable of simultaneously dealing with multiple clients. The server should try its best on
improving the flow-control and guaranteeing the clients to get all the content reliably and
uncorrupted by using the company’s selected protocol, RUSHB (Reliable UDP Substitute for
HTTP Beta).
RUSHB Structure
The RUSHB protocol is a HTTP-like stop-and-wait protocol that uses UDP in conjunction
with the RDT (Reliable Data Transfer) protocol. It is expected that the RUSHB protocol is
able to handle packet corruption, loss and encryption.
A RUSHB packet can be expressed as the following structure (úú is concatenation):
IP HEADERúú UDP HEADERúú RUSHB HEADERúú ASCII PAYLOAD
The data segment of the packet is a string of ASCII plaintext. Single RUSHB packet must
be no longer than 1500 bytes, including the IP and UDP headers (i.e. the maximum length
of the data section, or the concatenation of RUSHB HEADER and ASCII PAYLOAD, is
1472 bytes). Packets smaller than 1500 bytes need to be padded with 0 bits up to that size.
In detail, the following figure describes the header structure of a RUSHB packet.
Figure 2. Structure of a RUSHB Packet
The client and server independently maintain sequence numbers. The first packet sent by
either endpoint should have a sequence number of 1, and subsequent packets should have a
sequence number of 1 higher than the previous packet (note that unlike TCP, RUSHB
sequence numbers are based on the number of packets as opposed to the number of bytes).
Flags (7 bits total) Reserved (all 0s, 6 bits)
RUSHB Version Code (constant)
8
When the ACK flag (see Flags section in the next page) is set, the acknowledgement number
should contain the sequence number of the packet that is being acknowledged. When a packet
is retransmitted, it should use the original sequence number of the packet being retransmitted.
Packet that is not retransmission (including NAKs) should increment the sequence number.
The Flags Header is broken down to the figure 3 below.
BIT 0 1 2 3 4 5 6
FLAG ACK NAK GET DAT FIN CHK ENC
Figure 3. The Flags Header structure
The following scenario describes a simple RUSHB communication session. Square brackets
denote the flags set in each step (for example, [FIN/ACK] denotes the FIN and ACK flags
having the value 1 and the rest having the value 0). Note that RUSHB, unlike TCP, is not
connection-oriented. There is no handshake to initialise the connection, but there is one to
close the connection.
Scenario A (simple communication):
1. The client sends a request [GET] packet to the server.
§ The sequence number of this packet will always be 1.
§ The data section (ASCII payload) of this packet will contain the name of a resource
(e.g. file.txt).
2. The server receives the [GET] message, then transmits the requested resource to the
client over (possibly) multiple [DAT] packets.
§ The first packet from the server has a sequence number of 1.
3. The client acknowledges having received each data packet, by sending an [DAT/ACK]
packet to each received one.
§ The acknowledgement number of this packet should be the sequence number of the
packet being acknowledged.
4. After receiving the last acknowledgement [DAT/ACK] from the client, the server send
[FIN] message to end the connection.
5. The client receives the [FIN] message from the server, then sends back [FIN/ACK] to
the server.
6. After receiving the last acknowledgement [FIN/ACK] from the client, the server send
[FIN/ACK] again to the client and close the connection.
For all the packets with [DAT] flag is set to 0, the payload must be filled with all 0s bit only.
Please note that it is just a simple example of RUSHB protocol; the server also needs to deal
with optimised data flow control and multiple clients (that will be described later).
All RUSHB servers are capable of checksum and encryption. During the initial [GET], clients
can negotiate requests for checksum, encryption or both. This is done using [CHK] for
checksum and [ENC] for encryption in the very first [GET] packet. The first [DAT] from the
server will indicate if negotiation was successful by setting the corresponding [CHK], [ENC]
flags. Once negotiated, these options are valid for all packets until close the connection with
that client.
9
RUSHB checksum uses the standard Internet checksum on the payload only. As per the RFC,
the checksum field is the 16-bit one’s complement of the one’s complement addition of all 16-
bit words of the payload (see example below). Once [CHK] is negotiated, all packets that
have invalid checksums are considered corrupt.
For example, this is how we calculate checksum (note that network packets use big-endian
as the byte order for its protocol):
ASCII Payload abcde
Calculation
0x6261 is ab
0x6463 is cd
0x0065 is e
------------
0xc729
Result ~(0xc729) = 0x38d6
Figure 4. Example checksum calculation
RUSHB protocol used a simple asymmetric encryption algorithm called RSA to (perhaps)
secure the data transferred between host and clients. To simplify the use of this algorithm,
the server and the client will both (share the same key) use [n; e] = [249; 11] as its public key
and [n; d] = [249; 15] as its private key. We assume that the client always knows the server
public key, and the server always knows the client public key (to reduce the difficulty of the
assignment).
When the server receives the message with [ENC] from the client, the server will perform
decryption using the algorithm below (in Pseudocode):
message = ‘’
for each letter i in payload:
if i == 0 then break
convert_to_dec(i)
value = (i^d) % n
message += convert_to_ascii(value)
Also, the server will perform encryption and send the message with encrypted payload (in
Pseudocode):
encrypted = ‘’
for each letter i in payload:
if i == 0 then break
convert_to_dec(i)
value = (i^e) % n
encrypted += convert_to_ascii(value)
payload = encrypted
You do not need to know how RSA works; you just need to know how to use them as the
following example:
1. The client sends a request [GET/ENC] packet to the server, assume that the packet
is valid an uncorrupted. The packet payload is: ?ü?ü
10
2. The server receives the packet, then analyses the received payload as the figure below.
ASCII Payload ?ü?ü
Calculation
? -> 247 -> (247^15)%249=100 -> d
ü -> 220 -> (220^15)%249=97 -> a
? -> 134 -> (134^15)%249=116 -> t
ü -> 220 -> (220^15)%249=97 -> a
Result data
Figure 5. Decryption process at server
3. The server understands that the file it needs to send is called data, so it retrieves the
content of the file data and send the encrypted messages to the client with [ENC] flag
using the encryption algorithm above.
The following rules takes place when [ENC] is negotiated for all packets:
1. Encryption and decryption processes is only for ASCII Payload.
2. If [CHK] is negotiated, then the checksum computation takes precedence after the
encryption/decryption has finished.
3. [ENC] request is only available on the client side, and server only follows the client
requests.
Submission
Your server program 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 RUSHBSvr.py
Java
make
java RUSHBSvr
C or C++ make
./RUSHBSvr
Figure 6. 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/ass1/ from your repository on
source.eait.uq.edu.au. Please do not create subdirectories under /trunk/ass1/. 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.
11
Tasks
1 Basic Server (10 marks)
To receive marks in this section you need to write a program that is able to:
§ Listen on an unused port for a client’s message
§ Successfully close the connection
When invoked, your program should let the OS choose an unused localhost (127.0.0.1) port
and your program should listen on that port. It should output that port as a raw base-10
integer to stdout. For example, if you use C with GNU99 for your program and port 26041
was selected, your program invocation would look like this:
./3200Svr
26041
Any lines in stdout after the port number can be used for debugging. For this section, your
program does not need to respond to the [GET] request from the client. Upon hearing from
a client, your program can immediately signal the end of the connection (as described in the
example above). Once the [FIN] handshake has been completed, your server should close the
connection with the client. Note that in this case, unlike TCP, closing the connection clears
the state (or cache) associated client with the client. The current client could send [GET]
request and get accepted by the server again, but any other packets that associated with the
previous session (such as [ACK] of the previous file) should be ignored. You do not need to
implement [CHK] or [ENC] for this part.
2 File Tranmission (5 marks)
To receive marks in this section you need to write a program that is able to:
§ Perform all features outlined in the above section
§ Successfully transmit a requested file over one or more packets
§ Receive ACKs from the client during transmission
When your server receives a GET packet, it should locate the file being requested and return
the file contents over one or more DAT packets. When complete, the server should close the
connection (as in the above section). If the file being requested does not exist, closes the
connection. It is expected that this file is stored in your program working directory. You do
not need to implement [CHK] or [ENC] for this part.
3 Retransmission (10 marks)
To receive marks in this section you need to have a program that is able to:
§ Perform all features outlined in the above sections
§ Retransmit any packet on receiving a NAK for that packet
§ Retransmit any packet that has not been acknowledged within 4 seconds of being
sent
A client will send a DAT/NAK packet should it receive a corrupted packet or a packet with
a sequence number it wasn’t expecting (the NAK packet’s acknowledgement number will
contain the sequence number it was expecting). In this case your program should retransmit
the packet with that sequence number.
If a [DAT], [FIN], or [ACK] packet gets lost during transmission your program should
retransmit it after 4 seconds without acknowledgement (an packet should has its own timer,
saparately). If a [NAK] is received, the timer should reset (for the packet related to that
12
[NAK] only). How you choose to handle timeouts is up to you, however it must work on moss.
Please note there could be some unexpected behaviours when dealing with concurrency
(clocking and frequency), please research carefully before doing this task. You can only use
standard libraries, please make a thread on Ed if you are not sure if a library is permitted for
use or not. You need not implement [CHK] or [ENC] for this part.
4 Packet Integrity [CHK] (5 marks)
To receive marks in this section you need to have a program that is able to:
§ Perform all features outlined in the above sections
§ Implement the [CHK] mode negotiation and ignore packets with corrupt checksums
if checksum mode is in use
When a packet with incorrect checksum arrives, your program should ignore it and continue
to run without error. Any retransmission timer should also not stop or reset. You must also
ensure that if checksum was negotiated at the start, all packets must have a valid checksum.
You need not implement [ENC] for this part.
5 Secure Communication [ENC] (5 marks)
To receive marks in this section you need to have a program that is able to:
§ Perform all features outlined in the above sections
§ Implement the [ENC] mode negotiation and encode outgoing and decode incoming
packets when ENC mode is in use
You must also ensure that if ENC was negotiated at the start, all packets are to be encoded
before sending and decoded before reading.
6 Multiple-clients Handling (10 marks)
To receive marks in this section you need to have a program that is able to:
§ Perform all features outlined in the above sections
§ Handle multiple connection with clients
Your server should handle multiple connections with the clients. It should not mismatch the
packets of one client with another. When closing the connection with a client, your server
should do the action with that client only, and the transmission with others should continue
as usual.
7 Internet Attack Prevention (5 marks)
To receive marks in this section you need to have a program that is able to:
§ Perform all features outlined in the above sections
§ Prevent Denial-of-Service attack from one client
§ Prevent Denial-of-Service attack from multiple clients (distributed)
You should only do this part when finished all the parts above. Your server should detect
and block the client if it receives equal or more than ten (10) [GET] or invalid packets from
a client within 2 seconds from that client. Also, it should temporarily stop receiving and
sending packets for 10 seconds if it gets more than thirty (30) [GET] or invalid packets from
any client within 5 seconds. After 10 seconds of freezing, your program should refresh and
start accepting new coming connections, and those clients that perform the attacks will be
blocked from your server. Blocking a client means ignoring all incoming packet from that
client. Please note there could be some unexpected behaviours when dealing with concurrency
13
(clocking and frequency), please research carefully before doing this task. Your program needs
to distinguish between an authentic client and an attacker. A packet is called invalid when
the server ignores them, such as a packet that is not in RUSHB protocol, or [ACK] and [NAK]
with the wrong acknowledge number, or [GET] packet with a nonexistent file, etc. For
example, client A sends a valid [GET/CHK] to the server, while server is transmissting the
data to client A, client A send 9 packets with invalid checksum numbers, total of 10 packets
happened in 2 seconds, and thus, the server blocks client A.
Marking
Marks will be awarded for functionality only. The tests will mostly check your program’s
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 can not
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/loop indefinitely (without any reason). Your program should not
delay for unreasonably long times.
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
1. Start your assignment early.
2. Finite state machine is a good way to design a program’s work flow.
3. Check if the process send packets successfully by using Wireshark (listen on loopback).
4. Use RUSHBSimpleClient to debug your program, and test them on moss frequently
using RUSHBSimpleTest.
5. Ask a teaching staff if you need any assistances.
Updates
0.1: initial release
0.2: fix checksum errors, add clarifications about RUSHB packet
0.3: edit and add clarification in part A, part C submission changed to RUSHBSvr
0.4: add clarification in part A
0.5: fix RSA errors
1.0: official release
1.1: fix typos