在这个由多部分组成的任务中，我们最终将构建一个简单但可靠的文件传输 UDP上的应用程序。然而，为了实现这一目标，我们将首先实施在分配的A部分中，通过UDP“ping”应用程序。此UDP Ping器应用程序将帮助您熟悉UDP套接字并开发一个简单的请求超时的响应协议。在作业的B部分，我们将使用这些知识UDP。在C部分中，我们将在B部分中的客户端/服务器实现的基础上开发UDP上的单向流水线（Go-back-N）文件传输协议。我们强烈建议您尝试在给定的顺序：A部分®B部分®C部分。注意：我们强烈建议您使用Java或Python编写代码。因此，我们提供了一些基线代码（PingServer.java和PingServer.py–更多关于本文件后面的内容），取自教科书（Kurose和Ross）。在下面的描述中，假设您将使用Java进行编程。如果你是用Python编码的，所有的讨论仍然适用于你——你只需要替换使用等效Python编译和运行Java代码的命令命令。开始之前，请阅读教科书。该教材的最后几版描述了使用蟒蛇旧版本描述了使用Java的套接字编程。你应该能够在网络
ECSE 4670: Computer Communication Networks
Fall 2023
Programming Assignment
Due: Mon, Nov 20
In this multi-part assignment, we will ultimately build a simple but reliable file transfer
application over UDP. However, as a buildup towards that, we will first implement a
‘ping’ application over UDP, in Part A of the assignment. This UDP Pinger application
will help you familiarize yourself with UDP sockets and develop a simple requestresponse protocol with timeouts. In Part B of the assignment, we will use this knowledge
to develop and implement a unidirectional stop-and-wait file transfer protocol over
UDP. In Part C, we will build on the client/server implementations in Part B to develop a
unidirectional pipelined (Go-back-N) file transfer protocol over UDP.
We strongly recommend that you attempt to do this assignment in the given
sequence:
Part A ® Part B ® Part C.
NOTE: We strongly prefer that you write your code in either Java or Python.
Accordingly, we have provided some baseline code (PingServer.java and PingServer.py –
more on those later in this document), adopted from textbook (Kurose and Ross).
In the description below, it is assumed that you will be programming in Java. If you
are coding in Python, all the discussion still applies to you – you only have to replace
the commands for compiling and running Java code with the equivalent Python
commands.
Before starting, read the section on “Socket Programming with UDP” from Chapter 2 of
the textbook. The last few editions of the textbook describes socket programming using
Python; the older editions describes socket programming using Java. You should be able
to find many good resources on UDP socket programming in either of these languages on
the web.
Part A: UDP Pinger
In this part, we will do the UDP Pinger Lab assignment (altered slightly) of the textbook
(Kurose and Ross), which is one of the socket programming assignments in Chapter 2 of
the textbook. The lab is accessible on the textbook Companion Website, using the access
code that you will find in the textbook. In this assignment, you will study Java code for a
simplified Internet ping server and write the corresponding client.
The ping application:
The ping application allows a client machine to send a packet of data to a remote
machine, and have the remote machine return the data back to the client unchanged (an
action referred to as echoing). Among other uses, the ping protocol allows hosts to
determine round-trip times to other machines. We will discuss more on ping when we
study ICMP messages (ping uses ICMP ECHO request and ECHO response messages) in
Chapter 4 (network layer). You should try out
ping <server-name>
where <server-name> is the name of out favorite server, say www.google.com. Note that
some servers may not respond to ‘ping’ request. For example, try pinging www.rpi.edu
(from outside RPI) and see what happens.
The simple ping server-client that you will implement provides a functionality that is
similar to the standard ping programs available in modern operating systems, except that
you will use UDP rather than Internet Control Message Protocol (ICMP) to communicate
with each other.
Server code:
The server code is available as PingServer.java (a python version, PingServer.py, is also
provided, in case you prefer to code in python), which provides a full implementation of
the ping server. You need to compile and run this code. You should study this code
carefully, as it will help you write your ping client. As you study the server code, you will
notice that the server sits in an infinite loop listening for incoming UDP packets. When a
packet comes in, the server simply sends the encapsulated data back to the client.
Note that UDP provides applications with an unreliable transport service, because
messages may get lost in the network due to router queue overflows or other reasons.
However, since packet loss is rare or even non-existent in typical campus networks, this
server code injects artificial loss to simulate the effects of network packet loss. The server
has a parameter LOSS_RATE that determines which percentage of packets should be
lost. The server also has another parameter AVERAGE_DELAY that is used to simulate
transmission delay from sending a packet across the Internet. You should set
AVERAGE_DELAY to a positive value when testing your client and server on the same
machine, or when machines are close by on the network. You can set
AVERAGE_DELAY to 0 to find out the true round-trip times of your packets.
Compiling and Running the Server:
To compile the server, do the following:
javac PingServer.java
To run the server, do the following:
java PingServer <port-number>
where <port-number> is the port number the server listens on. Remember that you have
to pick a port number greater than 1024, because only processes running with root
(administrator) privilege can bind to ports less than 1024.
Note: if you get a “class not found” error when running the above command, then you
may need to tell Java to look in the current directory in order to resolve class references.
In this case, the command will be as follows:
java -classpath PingServer <port-number>
What to do:
In part A of the assignment, your job is to write the ping client code, PingClient.java, so
that the client sends 5 ping requests to the server, separated by approximately one second.
Each ping message should consist of 56 bytes of data. As in the actual ping application,
these 56 data bytes can be anything, and can be the same for all ping messages. After
sending each packet, the client starts a timer and waits up to one second to receive a
reply. You will notice in the server code that the ping message (the 56 bytes of data in
each UDP packet) is simply copied into the reply message. Once the reply is received, the
client stops the timer and calculates the round trip time (rtt). If one second goes by
without a reply from the server, then the client assumes that its packet or the server's
reply packet has been lost in the network. For this purpose, you will need to research the
API for DatagramSocket to find out how to set the timeout value on a datagram socket.
Your client should start with the following command:
java PingClient <host-name> <port-number>
where <host-name> is the name of the computer the server is running on, and <portnumber> is the port number it is listening to. Note that you can run the client and server
either on different machines or on the same machine.
When developing your code, you should run the ping server on your machine, and test
your client by sending packets to localhost (or, 127.0.0.1). After you have fully debugged
your code, you should see how your application communicates between two machines
across the network.
Message Formatting:
The ping messages in this part are to be formatted in a simple way. The client prints on
the screen a one-line message corresponding to each ping request. If the client receives a
response for a ping request, it prints the following line:
ping <server-ip-address> <sequence-number> <rtt-estimate>
where <server-ip-adress> is the IP address of the server in dotted decimal format,
<sequence-number> starts at 0 and progresses to 4 for each successive ping message sent
by the client, <rtt-estimate> is an estimate of the round-trip time between the client and
the server, calculated as the difference between the time a ping response is received and
the time the request was sent (the timestamp in the response packet). The <rtt-estimate>
is expressed in millisecs, showing up to 3 decimal places (microsec accuracy). Note that
this RTT estimate includes the AVERAGE_DELAY value that is introduced artificially,
and in general may not be a good estimate of the actual RTT.
If the client does not receive a response to a ping request within one second of sending it,
it prints the following line:
ping <server-ip-address> <sequence-number> LOST
Part B: Stop-and-Wait File Transfer
In this part, we will develop a simple unidirectional file transfer application over UDP.
Our goal would be to make it as simple as possible, while ensuring correctness/reliability
of the file transfer. It will be built along the lines of the Stop-and-Wait reliable transfer
protocol (Rdt 3.0) that we studied in Chapter 3. The requirements that the application
(which we will call sftp) must satisfy are described below.
The sftp application requirements:
The data transfer will be unidirectional – from the client to the server, although the
acknowledgements would need to be sent from the server to the client. To transfer a file,
the user (client) should call sftpClient <server_ipaddress> where server_ipaddress is the
IP address of the server in dotted decimal format. The stop-and-wait version of the
protocol that you will implement has some similarities with the Trivial FTP (or TFTP)
protocol, that also runs over UDP.
1 In a way, the sftp application that you will implement
can be viewed as a simpler version of TFTP.
• When called, sftp will read a file called inputfile from the local directory, and
transfer file in packets (each of which should contain 512 bytes of data, except
possibly the last packet) using UDP sockets.
• The server will reassemble the data in the packets into the file and write it as
outputfile in the current working directory (an existing file with the same name
will be rewritten).
• There is no explicit connection setup and closing (unlike TCP). The first packet
containing file data implicitly “sets up the connection”, so to speak. The end of
the file is indicated by the transfer of a packet with less than 512 bytes of data;
this also implicitly “closes the connection”, so to speak. So, no SYN or FIN flags
are needed. (What if the file size is an integral multiple of 512 bytes? Well, then
the client sends an additional packet with just 0 bytes of data to indicate the end of
file!) Note that this is similar to the way TFTP implicitly sets up/closes the
“connection”, and indicates the end of the file.
• Like Rdt3.0, you can use only one-bit (0-1) sequence and acknowledgment
numbers. You can allocate a full byte for it, for convenience, but the value of that
byte can only be 0 or 1. Thus the data part of each UDP packet sent from the
client to the server can be 513 bytes (1 byte header just indicating the 0-1
sequence number, plus the 512 bytes of file data), except possibly for the last
packet. The data part of each UDP packet sent from the server to the client can
just be the 1 byte header just indicating the 0-1 acknowledgment number. You
will assume that no bit errors happen in either forward or backward direction, so
no checksum needs to be included in any packet.
• The client can use any ephemeral port number, but the server must listen on port
number 9093. The client’s retransmission timer should be set to 1 sec. The
retransmission limit, of the maximum number of times that the client will attempt
retransmitting a packet on timeout, should be set to 5, i.e., a total of six
transmission attempts per packet.
1 RFC 1350: The TFTP Protocol, https://tools.ietf.org/html/rfc1350. TFTP is meant for
file transfer is systems which are too resource constrained to run TCP. TFTP can
however be inefficient for large file transfers, due to its stop-and-wait nature.
• Note that for sftp, you need to write both client and server (no code will be
provided), sftpClient.java and sftpServer.java. However, feel free to borrow
inspiration and code that you wrote for the ping application in Part A of this
assignment! You server should implement a LOSS_RATE and
AVERAGE_DELAY, as in the ping application in part A.
• You should test your code for different file sizes, but we ask you to report the
results (see “Deliverables” below) for a fixed file size of 50 Kbytes.
• You need to time the file transfer, and provide that in the output. For that the
client can start a timer just before it starts sending the file data, and stop it when
the entire file is transferred. If the file is transferred successfully, the client prints
the following line:
sFTP: file sent successfully to <server-ip-address> in <time in secs> secs
If the file transfer fails due to retransmission limit being reached for some packet,
the client prints the following line:
sFTP: file transfer unsuccessful: packet retransmission limit reached
• Make sure you compare inputfile and outputfile (bitwise comparison, not just the
size) to make sure the file is transferred correctly from the client to the server.
Part C: Go-back-N File Transfer
In this part, you will extend your code in part B to develop a Go-back-N (GBN) version
of your file transfer application, gftp, which will be called at the client as
gftp <server_ipaddress> <N>
where N is the sender window size, passed as a command-line-argument. gftp is similar to
sftp, but with the following additional features.
• The client (sender) sends up to N packets at any time (without receiving their
acknowledgement) and slides the window as the acknowledgments are received.
• You will use a 1-byte sequence and acknowledgment number field, which allows
a value of N up to 28
-1 = 255.
• The server (receiver) does not do any out-of-order buffering, and therefore rejects
a packet whose sequence number is not the next expected sequence number;
nevertheless, the receiver acknowledges the last packet received in order, as in
GBN.
• You will maintain only one timer at the sender at any time, that expires 1 second
from the time when the first packet in the sender’s window was sent out. As the
sender’s window slides and a new packet becomes the first packet in the sender’s
window, this timer is adjusted accordingly. To be able to do this, you may want to
maintain a record of the time when each packet is sent out.
• As in GBN, when a packet times out, all packets in the window are resent by the
sender.
Deliverables:
You are required to upload on LMS the following:
Part A:
• Client code for the ping application, pingClient.java
• A README file (Ascii), pingREADME, that discusses the tests you have
conducted, and some sample outputs to demonstrate that it is working correctly,
both under no packet losses and delays, as well as with packet losses (say 20%)
and delays (say 100 msec).
Parts B and C:
• Client and server codes for the sftp and gftp application,
sftpClient.java/sftpServer.java and gftpClient.java/gftpServer.java.
o Since sftp is a special case of gftp (N=1), you can choose to submit just
gftpClient.java/gftpServer.java, if you are certain that gftp works correctly
for all values of N.
o If sftp works correctly for you, but you are not sure about gftp, then submit
both sftpClient.java/sftpServer.java and gftpClient.java/gftpServer.java.
• A README file (Ascii), ftpREADME, that discusses the tests you have
conducted, and some sample outputs to demonstrate that sftp/gftp are working
correctly. Report any known errors.
• In a single Word or PDF document, provide figures (plots) of the following
experiments (with necessary explanation), as follows:
o For sftp (or gftp with N=1), obtain two plots as follows:
§ Fix the AVERGAGE_DELAY to 100 msec and plot the file
transfer time vs LOSS_RATE, by varying the LOSS_RATE as
0%, 5%, 10%, 15%. Compute each data point (that you will plot)
as the average of 10 runs (random seeds).
§ Fix the LOSS_RATE to 5% and plot the file transfer time vs
AVERAGE_DELAY, by varying the AVERAGE_DELAY as 50
msec, 100 msec, 200 msec, 400 msec. Compute each data point
(that you will plot) as the average of 10 runs (random seeds).
o Now for gftp with N=2, 4, 8, obtain the file transfer time for LOSS_RATE
= 5% and AVERGAGE_DELAY = 100 msec. Compute each data point
(that you will plot) as the average of 10 runs (random seeds). Plot the file
transfer time against N=1, 2, 4, 8, and comment on how the file transfer
time varies as N increases.
Grading:
The assignment will be graded out of 15; there will be 5 points for Part A, 6 points for
Part B, and 4 points for Part C.
Approximately 80% of the points will be on correctness, 10% on compactness of the
code, and 10% on proper commenting.