Programming Assignment #2

ELEN E6761 - Computer Communi ation Networks

Fall 2000

Due 10/3 4:10pm (CVN: 10/6 5pm)

Prof. Rubenstein

Goal

In this programming assignment, you will build a reliable transfer proto ol on top of UDP. You will design
both a sender and re eiver side parti ipant: the sender is the host that starts with a le - this le is to be
delivered to the re eiver. Note that both the sender and re eiver will be sending and re eving pa kets (the
sender sends data and re eives a knowledgments, the re eiver re eives data and sends a knowledgments).
You will design two versions: in one version, you will use Go-ba k-N style re over, and in the other, the
style of re overy will be Sele tive Repeat. In both versions, the sender and re eiver will need to perform
onne tion setup, onne tion teardown, as well as onne tion termination after a signi antly long timeout.
The onne tion establishment and teardown me hanisms an be the same for both parts of the assignment.

wrapped sendto
In both parts of the assignment, on the both the sender and re eiver side, you should repla e any all you
would normally make to sendto with a all to wrapped sendto with an identi al parameter list. wrapped sendto
is a fun tion that will be provided to you, written spe i ally for this assignment. It emulates various styles
of pa ket drops and reordering of pa kets so that you an test the thoroughness of your reliability proto ol.
This fun tion is needed be ause han es are, network loss rates on the real network are so low that not
emulating pa ket losses would make the ode of little interest, espe ially if both of your hosts reside on the
same LAN. See the ourse materials web-page for the ode pat h that ontains the wrapped sendto fun tion.
You an simply pla e #in lude "wrapped sendto. " in the body of your ode after you have in luded the
standard header les.
Requirements of your reliable transfer proto ol

status

seqno

pktsize

port

payload

IP address

winsize

Figure 1: Byte stru ture for your pa kets

The pa kets that you transmit should have the stru ture shown in Figure 1:
 byte 1: pa ket status, set to either:

0:
170:
85:
255:

onne tion setup

data (bit-sequen e 10101010)
a knowledgment (bit-sequen e 01010101)
onne tion teardown

 byte 2: size of the session transmission window

 bytes 3-4: size of pa ket (in bytes), in luding the header bytes
 bytes 5-8: sequen e number
 bytes 9-12: IP address where pa ket originated
 bytes 13-14: port of origin
 bytes 15 on: payload

Note that if the payload is n bytes long, then the size entered in bytes 3 and 4 should equal n + 14.
Your proto ol should be designed to handle / do the following:
 proto ols should handle arbitrary pa ket losses of data and/or ACKs
 proto ols should handle pa ket reordering of data and/or ACKs
 The sender should not send new pa kets faster than a rate of 10 per se ond (i.e., you must regulate

the rate at whi h it sends new pa kets - retransmissions do not need to be ontrolled. If you feel that
it is easier to ontrol the aggregate rate of new pa kets and retransmissions, you may do so instead).
Hint: use sele t() to regulate the rate of ow.

 if a knowledgments do not arrive within a spe ied period of time, t, then the sender should automat-

i ally retransmit (t should be no more than a se ond.

 if there is no ommuni ation from the other host after a period of time T where T is mu h larger than

t (e.g., 5 or 10 times as large), then the host should tear down the onne tion and report a failure to
omplete the transfer to the appli ation.

 half-duplex data transfer (full duplex would be both hosts sending data to one another).
 The re eiver should initiate the request for a onne tion.
 The sender and re eiver should both verify that the address and port ontained in the pa ket mat hes
the IP address and port that are returned by the all to re vfrom().

Note that the introdu tion of timeouts will require the use of the sele t() all. i.e., if both the sender and
re eiver blo k on their respe tive alls to re vfrom() (the re eiver waiting for data and the sender waiting for
ACKs), the proto ol will hang at both ends if all pa kets in the urrent window are lost during transmission.
Part 1: Go-Ba k-N

You an treat out-of-order pa kets as either lost pa kets, or you an buer them, as long as they t within
the urrent re eiver window.
Part 2: Sele tive Repeat

You should buer pa kets that arrive out of order, so long as they t within the re eiver window.
You an hoose the format of the a knowledgment (e.g., a bit-ve tor, a string of bytes indi ating the
pa kets re eived, ea h ACK pa ket ontains the a knowledgment for a single pa ket, et .)

Questions
 Sometimes (but almost never), pa kets are fragmented, i.e., only part of a pa ket is retrieved on a

all to re vfrom(), and additional alls must be made to retrieve the remainder of the pa ket. How
would you have to modify your proto ol design to handle fragmentation?

 Re all that the a ept() fun tion all used with TCP sessions spawns a new so ket for data transfer

after onne tion setup. How would you have to modify your sender and re eiver proto ol to allow the
sender to handle multiple re eivers at one time in a similar fashion?

What you should turn in

You should submit both a hard- opy, as well as an on-line opy. Before the due date, we will point you to a
web page that will give detailed instru tions of how / where to send your submission.
Your submission should in lude:
 your ode (4 les: Go-ba k-N sender, Go-ba k-N re eiver, Sele tive Repeat sender, Sele tive Repeat

re eiver)

 A des ription of your design de isions. Many of the details of the design of the proto ols are open.

Explain what you did and why

 A few sample runs of your ode. We will put out a list next week of mandatory s enarios that you
should in lude (i.e., various ways to ongure the wrapped sendto() fun tion, as well as the format of

the output.

 answers to the questions above.