Overview

Introduction to Fishnet
Fishnet Java Docs: (.html) (.tar.gz) (.zip)
Fishnet 1.64: (.tar.gz) (.zip)
Fishnet 1.8: (.tar.gz) (.zip)
Fishnet 1.8 (generics for java 1.5/1.6): (.tar.gz) (.zip)
Wireless Fishnet 1.8: (.tar.gz) (.zip)

Assignment 1

Description
Submission: by e-mail to Colin
Due: Oct. 13, 2008
Sample Solution: (zip)

Assignment 2

Description
Submission: https://catalysttools.washington.edu/collectit/dropbox/dixonc/3961
Due: Oct. 27, 2008

Notes

On Interoperability

First, we're going to ask (at least try) for interoperability on this project which means that we need to standardize packet formats and how they are processed.

For PING_PKT, you already have a template for what to do. The only issue is whether you choose to drop pings with an "old" sequence number. My personal take is that now that we won't be flooding ping packets (except with TTL 1), you can just reply to all ping packets. This might be useful, for instance if a routing change causes a new packet to get there substantially faster than an old one but you still want to reply and give (possibly) useful information back to the user.

For LINK_INFO_PKT, the payload should be the result of a call to the pack() function of a LinkState object, so that other implementations can call LinkState.unpack() on the payload. The source filed in the packet should obviously, be the the node who's neighbors are listed in the payload. Sequence numbers from a node should uniformly increase (with possible wraparound). Note that when a node is "failed" it doesn't actually lose any state, so this should prevent you from having to get true recovery right.

For NAME_PKT, the payload should be the string the source wants to be known by processed by the Utility.stringToByteArray() function so that other people can call Utility.byteArrayToString() on the payload to extract the name. This establishes the obvious binding between the payload and the source in the packet. One person asked if a it should be possible for two nodes to have the same name, or for one node to have multiple names. These options won't be required, but can be useful in some real-world circumstances.

Lastly, as long as you implement a correct version of Dijkstra's shortest path algorithm, the nitty gritty details about tie-breaking and the like don't matter. It's a decent exercise to figure out why this doesn't matter.

On Names

Forwarded to the class because it's of general interest:

Yes, that would be ideal. No, it isn't required to be able to change your name, though in the implementation I am writing it doesn't require any changes.

For the sake of standardization, the command should be:

name <name>

Also, since a given flooded NAME_PKT might not make it to everyone because of loss, it should presumably be periodically refreshed by resending.

XXX YYY wrote:
For CSEP 561 project 2, where does a node obtain the name it’s supposed to announce? Do we need to add a “name” command or something (and would that imply the need to support name changes?)

Assignment 3

Description
Due: Nov. 17, 2008
Submission: https://catalysttools.washington.edu/collectit/dropbox/dixonc/3961 Please read the submission instructions on the CollectIt Dropbox or the relevant e-mail.

Notes

On FINs

In project 3, it's unclear whether FINs should be acknowledged or not.

I'm going to step in and be the standards body. FINs flowing against the flow of data should not be ACKed. FINs flowing with the flow of data should be (but only after ACKing all other data, as is dictated by using cumulative ACKs).

A few clarifications:
  1. Rather than sending 512 bytes/packet, send Transport.MAX_PAYLOAD_SIZE bytes/packet.
  2. The payload should be bytes which have the value all 1's followed by all 2's, etc. rather than a string of all '1' characters which has been encoded to bytes.
  3. The sequence number of DATA packets should be the number of the first byte in the packet, the sequence number in ACKs should be the first byte of the first packet you are missing. Both as in TCP. The starting sequence number for a connection should be taken from the SYN. This starting number need not be 0. In fact, TCP randomly assigns it.

    So, if a SYN is sent with sequence number 5, the receiver should ACK with the ACK sequence number being 6. Then the first data pack should have sequence number 6. If the packet contained 107 bytes (ending with byte) 112, the ACK would come back with ACK sequence number 113 (the next expected byte).

    Note that the SYN "took up" one byte of sequence space. This same thing is done in real TCP. FINs should also take up one byte of sequence space. This means that on receipt of a SYN or a FIN, a receiver should simply send a normal ACK back, not a SYN+ACK or a FIN+ACK.

    The SYN+ACK and FIN+ACK are actually overloaded packets designed to both acknowledge the creation (or destruction) of the connection in one direction while creating (or destroying) the connection in the other direction. Since this is a unidirectional connection, FINs and SYNs should not flow from the receive to the sender.
  4. A connection is uniquely specified by the 5-tuple of: source port, source address, destination port, destination address and protocol. Since all transport connections will have the same protocol, this means that Transport connections are really defined by the 4-tuple of addresses and ports.

    You should be able to support simultaneous connections as long as they differ in this 4-tuple. So, multiple transfer connections must be allowed even though the will all share the same destination port and destination address.

    Also, a connection which is listening on a port should spawn a new connection whenever it receives a SYN so that it can also continue listening for more new connections.
  5. As far as creating classes goes, you will probably want to create at least one Connection class and then keep a list of them inside Node. If you want you can create a separate file for your Connection class, though it's not necessary. It also may be helpful to differentiate between outgoing, incoming, and listening Connections either inside the Connection class or as 3 separate classes.

Assigning ports

A bunch of people seem to have been confused by this, so here goes:

When a node boots, it should start listening for transfer connections on port 1. Let's call this node 0, and use standard TCP/IP notation of address:port, so we are listening on 0:1.

Now, if node 1 sends a SYN from it's port 35 to Node 0's port 1 we, Node 0 will send an ACK in response. This ACK *must* be sent from the same port as the SYN was sent to.

SYN: from 1:35 to 0:1
ACK: from 0:1 to 1:35

The connection will continue with those ports. It *must not* choose a new port for the receiver to handle this connection. If another transfer connection comes along from Node 12 port 57 to Node 0 port 1, this will mean that you have two connections at Node 0.

Connection 1: 1:35 => 0:1
Connection 2: 12:57 => 0:1

Node 0 should be able to simultaneously handle both by demultiplexing based on all four values source address, source port, destination address, destination port.

Assignment 4

Description
Due: Dec. 1, 2008