Peer-to-Peer

Peer-to-Peer

In the October 2010 Communications of the ACM is an article “Peer-to-Peer Systems” by Rodrigo Rodrigues and Peter Druschel small parts thereof I have quoted below.

“The term P2P has been defined in different ways, so we should clarify what exactly we mean by a P2P system.  For the purposes of this article, a P2P system is a distributed system with the following properties:

     High degree of decentralization.  The peers implement both client and server functionality and most of the system’s state and tasks are dynamically allocated among the peers.  There are few if any dedicated nodes with centralized state.  As a result, the bulk of the computation, bandwidth, and storage needed to operate the system are contributed by participating nodes.

     Self-organization.  Once a node is introduced into the system (typically by providing it with the IP address of a participating node and any necessary key material), little or no manual configuration is needed to maintain the system.

     Multiple administrative domains.  The participating nodes are not owned and controlled by a single organization.  In general, each node is owned and operated by an independent individual who voluntarily joins the system.

…

In some decentralized P2P systems, nodes with plenty of resources, high availability and a publicly routable IP address act as supernodes.  These supernodes have additional responsibilities, such as acting as a rendezvous point for nodes behind firewalls, storing state or keeping an index of available content.  Supernodes can increase the efficiency of a P2P system, but may also increase its vulnerability to node failure.

…

     Overlay maintenance.  P2P systems maintain an overlay network, which can be thought of as a directed graph G = (N,E), where N is the set of participating computers and E is a set of overlay links.  A pair of nodes connected by a link in E is aware of each other’s IP address and communicates directly via the Internet.”

The Exploratory Project to a large degree seems to fit the definition of the Peer-to-Peer Systems article.  That is, each distributed application (except for the display application) is both a server and a client in that particular components of the application can provide a service while others can be a client of a service or be both a provider / producer of a topic(s) and a client / consumer of other topics.  There is a configuration file that specifies the communication protocol supported by each application of the distributed system and, in the case of sockets, the IP address.  The various applications automatically connect with each other as they come online and determine which applications can provide their unmet services (that is, topics) and make known what services that they can provide to other applications of the system. 

At the time I read the article, only one node of the distributed system communicated with the display application while other nodes were all clients that received particular display events from the display server node and published display commands to the server node to be forwarded to the display application rather than the display application being a peer in the network.  Hence, in that version of the Exploratory Project, the node that interacts with the display application represents a supernode.

However, the ARINC-661 protocol for communications between user applications and a display application specifies that multiple user applications can communicate with the display application with any particular user application associated with its own display “layer”. 

Therefore, I extended the Exploratory Project such that multiple P2P applications can interface directly to the display application with each such application having its own display layer.  Since any particular component of an application can register to treat a particular display event, multiple components can be responsible for what is displayed on a display layer just as currently implemented for a single display layer.  And, since the component that registers to treat the display event can be allocated to any peer-to-peer application, such an application can communicate with the display in two different ways; one, via the application that has been allocated to treat the display layer and, two by being the application that has been allocated to treat the events of a different display layer.

For instance, the new version of the Exploratory Project is such that two layers can be described in the Definition File (DF) file and treated by the C# Display Application.  This, of course, can be extended by increasing the array sizes that retain data for the various layers. 

As in the previous version, the App1 P2P node connects to the Display Application for the forms and controls specified in the DF for layer 1.  Three forms are specified for the layer with three components of the P2P system each registering to treat the widget events of one of the forms with two of these components allocated to App2.

For the new version, App2 was extended to also interface to the Display Application via a separate communication channel by cloning the code of App1 and the Display Application was modified to select the communication channel to be used based on the layer of the form containing the widget / Windows control.

Due to the capabilities of the Exploratory Project, events of one display layer can modify another display layer controlled by another application.  That is, a layer 1 event transmitted to App1 can cause a change in layer 2 controlled by App2.  To illustrate this I changed the component that treats the text box of the third form of layer 1 to examine the text to check for “SHOW” or “HIDE” without regard to upper or lower case.  This control was already treated by a component of App2 to which the event had been forwarded by the project framework and then the response returned to App1 to forward to the Display App. 

If either Show or Hide were entered the normal response was changed to only clear the text box (rather than also adding the text to a list box of the first form of the layer) and to create a second response to display (show) the layer 2 form or hide it with the second response using the cloned version of the topic that is delivered to the layer 2 interface component of App2.  Therefore, the first response to clear the text box is sent to App1 for it to forward to the Display App using the layer 1 connection and the second is sent to the Display App via the layer 2 connection of App2.

Problems encountered in extending the Display Application

One modification to the C# Display Application necessary to add multiple layers was to add the use of worker threads to the application so that waits to receive commands from the P2P applications could occur on the connection for each layer at the same time.  This was something that was desirable prior to treating multiple layers, but not yet implemented, so that commands could be received asynchronously to events being transmitted to the responding application.  That is, to remove the need for command-response operation.

It was also necessary to have a pair of MS Pipes for each layer so that a wait for receive could occur on one pipe of the pair while an event could be transmitted using the other pipe of the pair.  Therefore, the MS Pipes between the Display Application server and each P2P application client node became similar to the pair of pipes between P2P nodes (except in the later case one pipe of the pair for any node was for the node acting as the server and the other for the node acting as a client of the other node).

The use of worker threads for the receives caused another problem.  That is, the interface to Windows requires that the access to the form controls always be from the same thread.  At first I thought that I could send an event to the main thread that was used to display the default form of the layer and have it then update the form responding to the received command.  However, the event handler ran in the same thread as had sent the event so that didn’t help.

Therefore, I also created a display thread for each layer that was created when the pipe pair for the layer connected with its P2P application.  The open of the display thread opens and displays the default form of the layer.  But it also starts a Windows timer prior to opening the default form so that the timer runs in the same thread.  (The other types of C# timers run in the main thread rather than the thread in which they are created.)  Then, each time the timer event handler runs, it checks if there is a received command for the layer and, if so, uses it to update the form associated with the layer.  In this way the use of the Windows controls for a layer is always from the same worker thread.

To determine the layer of a thread, the worker threads are named when they are created and the name of the executing thread is compared with these possible names to determine which thread is running.

Churn due to applications connecting, disconnecting, reconnecting, etc has yet to be addressed.