SPRING '05

CMPE 476 TERM PROJECT

 

 

DUE DATE: May 27th 2005, 17:00

 

PROBLEM DESCRIPTION: Our aim in this project is to monitor various quantities belonging to industrial processes in a reliable manner. To visualize, you may think of a factory environment where there are monitoring nodes that are capable of measuring some attributes of the physical processes.

 

 

 

 

 

 

 

 

 

 

 

 

 


You are expected to write the software for the monitoring nodes. In the picture you can see a plant where separate industrial processes are going on at spots A,B,C,D,E. For each spot we assume a single monitoring node with your application running on it. An example of monitored quantities could be as follows:

 

Quantity           Measured at

TEMP, HUMIDITY       A,B,D

FLOW RATE            B,C

OPAQUENESS           E

ACIDITY              C

 

 

 

We want a node to measure, record and display the quantities for the spot it is assigned to, and also we want it to communicate with other nodes and obtain their data, too. This is how we make the application reliable – i.e. by providing & storing data on several locations.

 

TECHNICAL ASPECTS:  What you will actually do is to implement a simple application layer protocol (ALP). Your implementation will be based on Berkeley Sockets programming. Your ALP should utilize both TCP and UDP transport layers. You will decide type and format of messages in your ALP in accordance with the problem description. When implementing the project, main emphasis should be on networking side. You can make logical assumptions to simplify your design whenever you think the issue at hand is not relevant to networking.

Here are a couple of technical hints:

 

·         Monitoring Node = PC with a standard Linux distribution.

·         Assume measured quantities are available to you in a convenient manner – e.g. you obtain them through a function call.

·         Identical code on all nodes. Stick to peer to peer architecture. No servers allowed!

·         Fixed number of spots => fixed number of nodes.

·         Nodes may become unreachable for a random period of time.

·         Nodes have prior knowledge on how to address others through the network, that is, it is a closed and fixed size system.

·         A node can measure more than one quantity. Display names of the quantities are entered manually.

·         Measurement frequency = 15 sec / measurement

·         During initial startup a node is elected as a leader. Throughout operation, nodes resort to election to make sure that there is always a leader in the network, for example by using Bully Algorithm.

·         All nodes record their local measurements. Ordinary nodes display their own measurements whereas leader node displays measurement of other nodes, too.

·         Leader node can display data of others in any of the following modes (user can switch between modes)

o        Single Data Mode

o        Continuous Monitoring Mode

o        Bulk Data Transfer Mode (e.g. Temperature data from node 8 for the last half an hour)

HINT: Your choice of transport protocol is closely related to monitoring mode.

 

 

FINAL REMARKS: Be careful about the below !

 

·         Simple and neat coding is very important.

·         Put comments wherever you see it is necessary. Effective commenting will affect your grades.

·         There are many open points in the project. You must make your own assumptions and work alone to finish the project. Team work is not allowed in this project.

·         Options that will affect your grade are as follows:

 

v      Your choice and design of the underlying protocol

v      Peer-to-peer architecture, no client-server applications allowed (-50 pt.)

v      Any language other than C/C++, any library other than Berkeley sockets (-50 pt.)

v      Cheating : Straight F as a letter grade