From: Janet Davis (jlnd_at_cs.washington.edu)
Date: Thu Feb 26 2004 - 21:53:55 PST
You all had an opportunity to discuss interoperability for the Fishnet
protocol in quiz section this morning. Here are the issues that Evan and
Harsha summarized for me, and my suggestions for interoperable
implementations.
If you think of any more we missed, or if you strenously object to any of
my suggestions, please email the list.
Is an initial sequence number (ISN) of 0 OK?
* It looks like nothing forbids a sequence number of 0. However, you
should consider using a random ISN.
What is the maximum sequence number? Do I need to worry about wraparound?
* The sequence number is transmitted as a signed 32-bit integer, so the
maximum sequence number is 2^16-1. Rather than handling wraparound, you
might pick a relatively small ISN so that wraparound is unlikely. (It's
not the most robust solution, but it's simple.)
Should the ACK be the last byte received or the last byte + 1?
* The choice is entirely arbitrary, but everyone must agree. The
assignment says to use the next byte expected (i.e., last byte received
+ 1) for the acknowledgment number. Let's stick with that.
If seq != expected when receiving, what do you do?
* The protocol requires you to send an acknowlegment on every packet you
receive. Send an ACK even if the packet that was received does not
advance the acknowledgment number.
If I'm not expecting the packet I receive in the state the connection is
in (e.g., I get a data packet without receiving SYN, or I receive a
duplicate SYN), what should I do?
* If you are confused, you can always send FIN to close the connection.
Should we retry SYNs?
* This affects interoperability depending on what the receiver does if it
gets a duplicate SYN. Let's say the receiver may respond with FIN if it
gets a duplicate SYN; this allows a simpler receiver implementation.
How should connection teardown work?
* The assignment was very vague on this, but we do need to agree. Let's
put the burden on the sender: The sender must wait until all data has been
acknowledged before sending FIN. We will not require FIN to be
acknowledged. (In what regard would requiring an acknowledgment of the
FIN packet be a better solution?)
What does it mean when the receiver sends FIN?
* The receiver sends FIN only when it doesn't want to receive any more
data. The sender should stop sending data immediately upon receiving a
FIN, regardless of unacknowledged data.
Do send and receive buffer sizes need to be the same?
* Not necessarily. The advertised window helps us here.
How long do we wait before inferring that the node on the other side is
not going to send FIN and hence, close the connection?
* This timeout should be much larger than the retransmission timeout. I
have heard several people using 1 minute, which seems reasonable to me.
(Incidentally, this is the maximum segment lifetime used on the Internet.)
-- Janet Davis jlnd_at_cs.washington.edu http://www.cs.washington.edu/homes/jlnd/ _______________________________________________ Cse461 mailing list Cse461_at_cs.washington.edu http://mailman.cs.washington.edu/mailman/listinfo/cse461
This archive was generated by hypermail 2.1.6 : Thu Feb 26 2004 - 21:53:58 PST