There are three parts to this assignment. The first is a moderately difficult programming assignment. The second is a straightforward programming assignment. The third is a small set of questions drawn from the book. I recommend you start early.
A message is considered sent once it has been delivered and acknowledged. An unacknowledged message is resent after a timeout. After a finite number of resends, an error is reported.
ssize_t reliable_sendto(int s, const void *msg, size_t len, int flags, const struct sockaddr *to, socklen_t tolen); ssize_t reliable_recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen); void reliable_config(int retries, int timeoutms);These first two routines are modeled on the existing
recvfromAPIs. See the man pages for more information.
reliable_sendto should return the number of characters
sent, or -1 if an error occurred. In addition to the standard UNIX
errors that can occur on a sendto, you should set
in the event that the sender receives no acknowledgment after
attempting to send multiple times.
for more information on system call error numbers.
The third routine allows you to parameterize the number of
retransmissions that should occur when appropriate acknowledgements
are not forthcoming in a window of
timeoutms milliseconds. By
default, your protocol should retransmit 4 times with a timeout of 10
milliseconds. A timeout of
0 ms disables retransmissions and causes
reliable_send to never report an unacknowledged datagram.
retries of 0 also disables retransmissions, but delays at least
timeoutms before returning. Datagrams are never reported as lost.
You should put your protocol implementation in a file called
reliable.c and link it
in with a client and server program.
Your main client program should be called "swclient.s" and your server
program should be called "swserver.c." Each is to be executed from the
command line on different computers:
notattu2: ./swclient host portnum maxdgramsize nretries timeoutms attu2: ./swserver portnum
The server displays the data it receives on the UNIX stdout channel.
The server's portnum is an optional specifier indicating
on which port the server should receive messages. Without this
optional specifier, the server should be willing to accept any port
from the OS (bind to sin_port = 0). This simplifes the sharing of the port space.
See here for
information on using bind.
Second, measure throughput as a function of timeout for 5 different datagram sizes: 10 bytes, 512 bytes, 2k, 8k, and 64k. To measure throughput, you should copy a large file from the client to the server to ensure that your timing covers many round trips. Consider timeouts ranging from small to medium to large (10, 50, 500 ms). Show your measurements in two graphs: Include a THROUGHPUT graph with one line for each of the different datagram sizes where the x-axis is your timeout, and the y-axis is your measured throughput. Include a RETRANSMISSION graph, where the y-axis is the total number of retransmissions that the client performed.
Include a thoughtful discussion and analysis of the results of no more than one page. Don't forget to make clear the description of the experimental setup (eg, machine names, types, speeds, network speed, etc.).
fromfield indicates the source of the message.
./swserver > ./outputwhile still seeing informational messages from the server (such as which port it is listening on). Note that stdout is buffered, whereas stdout is not, so if you send both streams to the same place (such as the console or to a file with
>&), the stdout and stderr streams will appear out of sync. You can use setbuf (man setbuf) to set the buffering for stdout to 0, but only do this for debugging as it will substantially change the performance and behavior of your server program.
% ./swclient attu1 7890 1024 4 10 < someBigFile
timecommand, as in:
% time ls index.html 0.000u 0.001s 0:00.00 0.0% 0+0k 0+1io 0pf+0wSee the man page for time for more information. I recommend though that you include the timing logic in your client program itself using
gettimeofday, and print the computed throughput along with other statistics you may need when the program terminates.
selectsystem call with a timeout to determine if the acknowledgement has been received (man select).
results.pdfthat contains your evaluation, and a file called README that contains any information we might need in evaluating your solution. For example, bugs and limitations should be included in the README.
Write a program that properly computes the probability of running out of bandwidth given that there are more ways in which "at least k of n" nodes can be transmitting than there are "exactly k of n." You should use the same parameters that I used in lecture. Your program should produce a table of 2 columns. The first column is the number of nodes on the network, and the second column is the probability that the network is overcommitted.