STRUCTURED AND UNSTRUCTURED P2P NETWORKS – Project topics materials

Get Complete Project Material File(s) Now! »

The HyperCircle Class Diagram

The class diagram (Figure 17) shows our implementation of the HyperCircle protocol. The HyperCircleNodeHandle class, specialized from the basic OverSim NodeHandle class, stores all properties of the nodes, while the HyperCircleBucket class stores the properties of the first-level hypercircles. The HyperCircleBaseDimension class stores the second-level circles, and the HyperCircleDimension (superclass of HyperCircleBaseDimension) stores circles of every greater levels. The most important properties of all these classes are the neighbors, which are illustrated here as recursive relationships. All three neighbor relationships will almost always all exist, the exception being when there are less than three nodes (or circles) in the encompassing circle.
The HyperCircleNodeBucket class is implemented as a vector storing up to 8 nodes, and also having its own neighbor relationships. The buckets are always contained within a dimension; in the case of a topology of no more than 64 nodes this would be the universe dimension that is always at the top level. A further vector class called circleVector is used to store the addresses of the buckets that are not full (instantiated with the name nonFullCircle). In this way, if a joining peer contacts a peer in a full circle, he can be forwarded to a non-full circle. The same is also true for the class dimensionVector and its instance nonFullDimension, albeit dealing with dimension. The HyperCircleDimension class, along with its specialized class HyperCircleBaseDimension, represent circles of level two and upwards (i.e. circles containing circles, as opposed to circles containing nodes).
HyperCircleBaseDimension is a vector containing HyperCircleNodeBuckets, while HyperCircleDimension is a vector containing HyperCircleBaseDimensions or HyperCircleDimensions. As with the HyperCircleNodeBucket class, these classes also have three neighbor relationships, and its own class for containing non-full dimensions (dimensionVector).
This brings us to the subject of vacantPoint, vacantCircle and vacantDimension, three vector instances which hold the addresses of virtual nodes, buckets and dimensions. (There can be at most one virtual node in every bucket, one virtual bucket in every BaseDimension and one virtual dimension (base or otherwise) in every dimension in the network at any time). The virtual objects take priority over the non-full objects and get filled when a new proper object appears (for example, a new peer, or a new circle as a consequence of a new peer joining).
The HyperCircleRouteMessage, specialized from OverSim’s basic RouteMessage class, holds the messages sent to and from the nodes. Depending on the circumstances, a message can have a relationship with 2, 3 or 4 nodes. Every message has a source and destination nodes. If it is on its way to its destination via other nodes network, it also has a relationship to the last node it passed on its way, and if it passes a node that is forwarding messages on behalf of a virtual node, it also has a relationship to the virtual node. In the same way, it also has relationships with the last bucket and the last dimension it passed, as well as virtual buckets and dimensions. In order to terminate the message’s further travel when it has passed the appropriate number of nodes it has a counter for nodes traversed, and a separate counter for dimensions traversed.

READ Propagation of Elastic waves in elastic isotropic media

Extensions to the HyperCircle Algorithm

To make the topological HyperCircle structure work in a satisfactory way, a few extensions had to be made to the algorithm described in [1]. Most of them have to do with conserving the balance of the network when nodes join and leave. For this purpose, there can only ever be one virtual node in a circle at any time (that goes for both buckets and dimensions). Therefore, all nodes need to be informed of the vacant point. In real life, this would be implemented with broadcast messages to all nodes, but in our simulation the vacant nodes, buckets and dimensions are stored in their own global vectors (a map in the case of dimensions, to be able to map the vacant point to a specific level). The same is true for our nonFullCircles and nonFullDimensions vectors, which store all non-full circles and dimensions so that new nodes can be directed to them instead of opening new circles and/or dimensions of their own, which would seriously derail the balance of network.

1 Introduction
1.1 BACKGROUND
1.2 PURPOSE/OBJECTIVES
1.3 LIMITATIONS
1.4 THESIS OUTLINE
2 Theoretical Background
2.1 PEER-TO-PEER NETWORKS
2.2 STRUCTURED AND UNSTRUCTURED P2P NETWORKS
2.2.1 Unstructured P2P Networks
2.2.2 Centralized Server Networks .
2.2.3 Super-Peer Networks .
2.3 STRUCTURED P2P NETWORKS (DETERMINISTIC TOPOLOGIES)
3 The HyperCircle P2P Topology
3.1 NETWORK MODEL, AIMS AND REQUIREMENTS
3.2 ORGANIZING PEERS INTO A HYPERCIRCLE GRAPH
3.3 SEARCH AND BROADCAST ALGORITHM
3.4 CONSTRUCTING THE HYPERCIRCLE TOPOLOGY
3.5 TOPOLOGY MAINTENANCE ALGORITHM
3.5.1 Integration Dimension Selection
3.5.2 Integration Champion Node Appointment
3.5.3 Node Integration .
3.5.4 Node Departure .
3.5.5 Broadcast and Search in an Incomplete Hypercircle
4 Implementation
4.1 SELECTION OF SIMULATION SOFTWARE
4.2 THE OVERSIM SIMULATOR
4.3 LAYER STRUCTURE OF THE HYPERCIRCLE IMPLEMENTATION
4.4 THE HYPERCIRCLE CLASS DIAGRAM
5 Results
5.1 LIMITATIONS OF THE PROTOCOL IMPLEMENTATION
5.2 SIMULATION RUN SETUP
6 Conclusion and Future Work
7 References