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
sendto
and recvfrom
APIs. 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 errno
to
ETIMEDOUT
in the event that the sender receives no acknowledgment after
attempting to send multiple times.
See intro(2)
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.
A retries
of 0 also disables retransmissions, but delays at least
timeoutms
before returning. Datagrams are never reported as lost.
k
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.).
from
field 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
time
command, 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.
select
system call
with a timeout to determine if the acknowledgement has been received (man select).
results.pdf
that 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.