Peer-to-Peer Data Sharing Among LabVIEW Nodes
CS 395T- Grid Computing
The goal of this project is to impose a peer-to-peer (P2P) data grid on a set of LabVIEW (LV) nodes. LV nodes, in this
context, are data acquisition sensors that access live data. This data is published over the network via a publish-
subscribe protocol used by these sensors, and any client who knows the physical address of these sensors can directly get
the sensor data from the node that owns the sensor. These nodes are also capable of running embedded LabVIEW Real-
Time (LVRT) applications, which allows us to create a P2P network with these nodes by creating a global namespace for
these sensors  such that a client can use a logical name of the sensor and query the P2P grid to locate the sensor.
This report is organized as follows: First, I give a brief background of P2P computing model, sensor networks, and
relevant applications . Second, I describe the experimental setup and hardware I used to create the P2P netwok. The
third section gives a detailed description of the P2P network design and the LV based implementation. The final section
gives expected results and conclusion.
This project is based on two broad research areas in grid computing: P2P networks and sensor networks . Both of
these technologies have been around for some time , but the broad use of Internet technology has created several new
opportunities for these technologies. Because these technologies are still being defined, I give a brief overview of each
as it applies to this project.
P2P Computing Model
The P2P computing model allows different nodes on the network to communicate directly with each other to share data
and/or resources. For this project, P2P is defined as follows :
Nodes have awareness of other nodes
Peers create virtual network that abstracts the complexity of interconnecting peers
Each node can act as both a client and a server
Peers form working communities of data and application
Overall performance of the system increases as more nodes are added
Sensor network covers the distribution of small and relatively cheap sensors that are capable of wireless communication
and significant computation . Sensor network technology allows us to place sensors closer to the phenomena being
monitored so that the data can be processed and filtered closer to the data source. It also allows multiple sensors to
collect the same information and then collaborate with neighboring nodes to resolve ambiguities. Typical sensors in this
network have embedded processor, wireless communication circuitry, data storage capacity, etc.
The sensor network technology is revolutionary for many situations where information gathering and processing is
needed for inhospitable physical environments and/or less accessible environments, such as remote geographic regions
or large industrial plants .
This project will be a prototype of a real life application that can benefit from a P2P system which allows sharing of data
in a standard data grid format. The real life application can be a subset of emergency control response system to a
natural disaster, for example, earthquake or a tornado. In a situation like that, data needs to be acquired from different,
spatially distributed sensors, and analyzed for different behaviors; for example, to predict the next course for the disaster
and damage caused by it. Currently most of these systems use central data storage and supercomputers to store and
process this data .
As distributed and networking technology becomes faster and more reliable, more and more applications are moving
away from central repository for live sensor data. In this project, Ill present a solution that stores the data locally, in a
distributed data grid, by combining the storage devices on all sensors and sharing that storage so that different sensors
can put their data in a virtual global data space. This not only allows sensors to share unused storage space, but by
abstracting the physical to logical memory mapping in the data grid, it also allows clients to access that data as if is
located in a central global memory1.
The goal of this project is to create a P2P data sharing network using LV nodes that are capable of acquiring sensor data
and publishing it on the network . Currently these nodes work in a client server mode. However, because these nodes
can run LVRT applications , we can create a P2P system where each node in the grid is aware of every other node in
the P2P system, and can query the node to access the sensor data. By adding a P2P data grid, we get the following
The major benefit of having a P2P data grid is that is allows internal and external nodes to access data without having
any knowledge of where that data is physically located. This is done by providing a physical to logical mapping of data
to a global namespace that all peers in the grid can have equal access to. External nodes can then query any peer node in
the grid to locate the actual data point in the grid.
Sharing of Sensor Data Among Peers
Since all peers in the grid are aware of the data and resources available in the grid, they can use this information to
minimize network traffic and share resources on need basis. For example, if one node needs more disk space it can
request other nodes to share any free disk space that they are not using.
1 There are many open issues with P2P and sensor networks, like network security, wireless communication, power consumption, etc. These issues are not addressed in this report.
Dynamic Network Topology and Fault Tolerance
A P2P data grid allows dynamic insertion and removal of sensors in the data grid. This way even if one sensor or node
goes offline, the overall data grid can continue to function. By adding some redundancy in the system, we can also make
the grid fault tolerant, such that if one sensor dies another sensor can take over its responsibilities.
For this project, I used National Instruments FieldPoint RT controllers ([c]FP-20xx serial product line) and LabVIEW
Real-Time 7.0 software. A FieldPoint system is a modular I/O system that consists of a controller and one or more of
I/O modules. The I/O modules are designed to acquire a variety of physical data, like temperature, pressure, etc.
Numbers of physical channels in a FieldPoint system depend on the number and type of I/O modules used. The [c]FP-
20xx controllers are also capable of running LVRT applications for embedded control and data-logging. These
controllers also support a publish-subscribe protocol to publish the I/O data over the network, which allows clients to
directly talk to the controller and read or write any of the I/O channels.
Although the resources and number of channels available on a FieldPoint system are slightly higher than what a typical
sensor network is likely to have , they are ideal to simulate a P2P data grid as they have the following capabilities:
Each node can be placed in geographically different, potentially hazardous, location
Each node is capable of running a LabVIEW Real-Time application
Each node has one or more sensors connected to it
Each sensor can acquire live physical data
Each node can share its sensor data over the network using a publish/subscribe protocol 
Figure 1 shows the basic design for the P2P data grid. A peer in this grid is a FieldPoint controller with some I/O
channels connected to it . The nodes are capable of communicating among each other as peers and can share
information among each other, such that no one node has all the information available in the grid, but when all these
nodes come together as peers in the grid, they can present the I/O data as if it is coming from a central repository.
Figure 1 P2P data grid with FieldPoint LVRT nodes
The nodes share their data with each other by creating a mapping from physical address to a logical name. This logical
name is unique for each channel and serves as the global name for that I/O channel in the data grid. The logical
namespace is created using a default naming convention, which each node conforms to. By allowing a default naming
convention, we can minimize the initialization needed by the user to setup the system. However, the system can allow
the user to change the logical name to a user-defined name, once the grid is initialized. Table 1 shows an example
mapping where each controller has a temperature channel connected to it. In this example, each node has specific region
assigned to it (e.g. Zone1) and uniquely names all its channels based on this region and channel offset.
Physical Address Logical Name
Table 1 Mapping from sensors physical address to default logical name2
2 The physical address in my setup was ac