Contents

The Plan

This week, we need to solidify a first-approach to our network and get some functional tests complete during class so we can move forward.  These tests are critical so we will focus entirely on that for the class period.  If we get these tests completed, we can move forward in other areas of discussion. 

Discussion

Last week, we got some really good discussion going with regard to the bit-for-bit strategies and needs of the network.  This week we focus on the two test we determined were important to help shape our network.  Namely, we want to determine how/when collisions occur as well as what the actual transmission time is between nodes.  Our algorithms will rely on these bits of information. 

Last week, we also tried to develop a shorthand for describing network flow that allows us to describe the information moving around the network (independent of the underlying algorithm).  Our host sniffer should be able to generate something like this notation so we can start to diagnose and learn more about our approaches to the algorithms. 

Below are the two tests (collision, latency) described in terms of network flow using this notation.  We may change this notation but this helps get things rolling. 

Our basic network topology for critical tests.

Test 1 - Collisions

We need to come up with a better notion of what happens when there is a collision.  Does that packet get dropped? garbled? If we know this, we can make some critical assumptions in our algorithm. 

Using the above network, we will try to write simple, task-based code to accomplish the following task.  Node 1 sends a message to Node 4.  Intermediate Nodes 2 and 3 see the message and forward it to 4 which should result in a collision, assuming predictable timing.  Since this test is for the collision issue, we can hard-code nodes 2 and 3 with no real algorithm, they only need to re-transmit what they see.  Here is a node-by-node plan for this test:

• Node 1 - Just use the remote or GP application to send a packet. 
• Node 2 - Simple program that just re-broadcasts any packet it sees and then times out for a second or two to avoid ripples. 
• Node 3 - Same exact code as node 2
• Node 4 - Can be either another GP application just receiving the traffic or, ideally, the sniffer can be used here. 

Using our network flow notation we devised last week, this might look like:

Describing these line by line, we see at 001o (step 1, output) that node 1 sends a packet from 1 to 4 starting with a TTL of 3.  This assumes our 3-3-2 bit packet structure as a starting point.  In the next step (001i) nodes 2 and 3 both see the same packet.  at 002o, our "dumb" algorithm for nodes 2 and 3 just resends the same packet with the TTL reduced by one.  Since all 4 nodes can see these pseudo-simultaneous re-transmits, we can ignore the reflection to node 1 (to be handled later), the echos at nodes 2 and 3 (they time out for a short bit to avoid any ripple for this test), and we can observe and try to characterize what happens at node 4. 

Do we get a packet at all, is it correct? Do we always see the same result? This is the crux of this first test. 

Test 2 - Latency

This test is straightforward and yields the time required to a packet through a couple of nodes.  This is critical as we need to determine our transfer rate to allow things to pace out, ignore input for reflections, etc.  In this test, we just send a packet from 1 to 2 to 4 to 3 to 1.  This cycle involves 4 "hops" so we should be able to sniff the loop and get a basic hop time average. 

Implementing this can be a simple algorithm on each node as follows:

• Node 1 - likely a C++ host driven GP 2.0 module.  This allows better timing measurement.  This code can be the sniffer with the single addition of a periodic output packet addressed to 2. 
• Node 2 - This can be a simple TEA program on a stem that awaits a packet and if it is addressed to 2, it just sends a hard-coded packet to 4. 
• Node 3 - This is just like node 2 but it awaits a packet addressed to it and sends it back to node 1
• Node 4 - Again, the same algorithm but it sends upon receipt of an addressed packet to node 3. 

Again, in our network flow notation, this would be something like:

Since the sniffer is modified to generate the original packet, we can the check the time-stamp from this output as well as that of the intermediate hops and better characterize the network timing. 

Assignment

Last week was a bit scattered and we ended up with a few networking approaches, some nearly ready code, and a notation description.  For this week, we will assign sub-projects to happen in parallel based on what we have learned.  These assignments include:

• Library Improvement
• Packet Documentation
• Sniffer Changes, Docs
• Algorithm Pseudo-Code
• Test Results Write-up

Each of these assignments will be due as CVS check-ins before the start of class next week. 

Revision History:

• 2009-02-11: Added Link to Resources for description of Packet Structure
• 2009-02-10: Initial Post

Related Links:

Main page for the University of Oregon Winter 2009 407/507 course

Resource Collection for the 407/507 Winter 2009 course