A Pull-based Sensor Network

 

1 The problem

In the second part of the programming project, you are asked to implement a pull-based sensor network. The network configuration is to be as follows:

Larry and David Jones have decided to open a Jones family account with Ameritrade to keep track of the net worth of the family stocks. Larry and David each have their own personal portfolios. The value of the Ameritrade account is the sum total of each of the individual portfolios.

 

The Directory server contains subscription information (IP address etc) for each sink, i.e. information about which sources a sink should contact. All sinks contact the Directory server when they start up to learn which sources provide the data that they need.

 

Ameritrade first contacts the Directory server for information about the personal portfolios of Larry and David Jones. Ameritrade then directly contacts the servers that handle the individual portfolios and gets the current value of each. In this case, the portfolio servers act as sources. Therefore, the servers at level 2 act as both sources and sinks.

 

The personal portfolio servers contact the Directory server to know which sources to poll for the corresponding stocks. David Jones owns stocks in IBM and AT&T; Larry has invested in Microsoft and Intel. The portfolio servers poll the corresponding sources for updates and calculate the current portfolio value. Here, the portfolio servers act as sinks.

 

As this is a pull-based network, sinks stay current by polling the corresponding sources for updates.

 

This project has three parts.

 

1.      The update interval at the Level 1 stock price sources is fixed. The personal portfolio servers stay up-to-date by polling the Level 1 sources at some conservative interval that ensures that the Level 2 sinks are stale for as little time as possible.

 

Ameritrade polls the portfolio servers at an appropriate interval that allows the updates at the Level 2 servers to propagate to Level 3 as fast as possible.

 

Sequence numbers may be used to keep track of the most recent poll result from a source and order of updates. If you'd like, you may use logical clocks instead of sequence numbers.

 

You are provided a trace for each of the four sources that will help you test your system.

 

2.      The Level 2 sinks vary their polling frequency and adapt to the update frequency at the Level 1 sources. You can implement this in any way that you like.

 

You may use the approach covered in class where the sink starts polling the source at a conservative frequency. If many poll message are wasted (data was not updated), the sink polls at lower frequency. If all poll messages indicate that the data has been updated since the last poll, the sink polls the source more frequently, or increases the poll frequency. This process is repeated until the polling interval converges to the update interval.

 

The Level 3 sink also should use a similar approach to detect the update frequency at the portfolio servers.

 

For this part, the update frequency at the stock quotes sources remains fixed. You may use the same traces as in the previous part to test your system.

 

3.      Now you must test the system that you built in the previous part on Level 1 sources that have changing update intervals. The update intervals at the stock quotes sources change over the sequence of updates. The personal portfolio servers and, in turn, the Ameritrade server should be able to adapt their polling frequency to the changing update intervals.

 

You are provided four example traces for the level 1 sources to help you test your system.

 

Some things to keep in mind:

• The example network shown above has sinks subscribing to 2 sources. Your code should be written in a way that the number of sources can be varied easily, for example by changing the directory entry for a sink.
• Be aware of the thread synchronizing issues to avoid inconsistency or deadlock in your system.
• No GUIs are required. Simple command line interfaces are fine.
• You can work in groups of two for this assignment.

2 Evaluation and Measurement

 

Set up the network described in the diagram.

 

Study how the value of the Jones account calculated by your system differs from the actual value of the account at that instant. The actual value is deterministic given the traces. For each of the three parts of the project, include a graph of the calculated value of the Jones account versus time. On the same graph, include the plot for the actual value versus time. Calculate the percentage of instances where the calculated value differs from the actual value. This gives the fidelity or consistency of the system. Do this for all three parts. Compare these numbers and discuss your results. For the first part this value should be zero.

 

For the first part of the project, count the number of wasted poll messages – polls which did not result in updates as the data at the source had not changed. Compare this number with the number of wasted messages in the second and third parts.

 

For the second and third parts, plot the polling frequency versus time. For the second part show that the polling frequency converges to the actual update frequency. For the third part, indicate in the graph the actual frequency at each instant.

 

For now, the traces provided are example traces to help you test your program. Actual traces will be put up shortly.

3 What you will submit

When you have finished implementing the complete assignment as described above, put all the code in a separate directory in your edlab account (/677/project2).

You are required to submit your solution in the form of printouts.

Each program must work correctly and be documented. You should hand in:

1.      A copy of the output generated by running your program. When the directory server sends data, have your program print the information to the screen. When a sink is polling a source, have your program print messages for whether an update is required, and if so, for the data being sent by the source and for the data being received by the sink.

2.      A separate (typed) document of approximately two pages describing the overall program design, a description of "how it works", and design tradeoffs considered and made. Explain how you implemented the adaptive polling frequency. Describe clearly how synchronization is handled. Also describe possible improvements and extensions to your program (and sketch how they might be made).

3.      A program listing containing in-line documentation.

4.      Instructions to compile and run the code from 677/project2.

5.      A separate description of the tests you ran on your program to convince yourself that it is indeed correct. Also describe any cases for which your program is known not to work correctly.

6.      Performance results and discussion.

Let us not waste a lot of trees. So, if any of the above turn out to be large, just save the relevant information in a file, leave it on your EDLAB account and submit the name of the file.

4 Grading policy for all programming assignments

Grading:

·         Program Listing

o        works correctly ------------- 50%

o        in-line documentation -------- 15%

·         Design Document

o        quality of design ------------ 15%

o        understandability of doc ------- 10%

·         Thoroughness of test cases ---------- 10%

Grades for late programs will be lowered 12 points per day late.