Randpeer - Layer model

To run a p2p network is a complex task (for our module that does the work, not for you or your program). And there are many different things one may want to use a p2p network for. Thus the Randpeer library contains several layers and several internal modules, each taking care of some specific problem. And it supplies a whole set of services to the application.

Note that each node takes part in all layers at the same time. That is, a node normally takes part in the "mother net", its "application network" and some "service subnets", all at the same time. The node never leaves the mother net and the application network as long as it is online.

1.  Mother net layer

The first layer runs the mother net. All applications that use the Randpeer library take part in the same mother net. Some basic functions and services are run directly on top of the mother net. Especially such services that runs better the bigger a network is, such as network time and bootstrapping. (Bootstrapping means that when a node starts it needs to find the network.) After a node has joined the mother net it uses the subnetting service on the mother net to find and join its application network.

2.  Application network layer

The second layer runs the application network. Each application has its own application network. Some functions and services are run directly on the application network, such as application statistics, basic file transfers, and app to app connection handling. App to app connection handling means that if your application needs a connection to another node running your application our library can provide that, including our built in stealth, encryption, compression, channel separation and message separation etc. After a node has joined the application network it can use the subnetting service on the application network to find and join service subnets.

Click on the pictures to view the full size.

3.  Service subnet layer

The third layer runs several or even many separate service subnets. Service subnets can have many different purposes.

Typical service subnets are file transfer swarms, chat rooms and user identities. That is, the application creates a subnet for each chat room and names the subnet after the chat room. Nodes wanting to join the chat room simply joins that subnet and uses the broadcast service on that service subnet to broadcast messages in the chat room. A user identity works the same: The user's node creates a service subnet named after the user. Any other node that wants to chat with or phone that user simply looks up that service subnet to find and connect to the user. (But usually the other node should not join the subnet, since that subnet is for the user's node alone).

Service subnets are also used internally in the Randpeer library. Some of the algorithms such as the broadcast search system and the Distributed Hash Table (DHT) lookup system run in their own service subnets. This means that only nodes that needs to use those services need to join those service subnets and "waste" bandwidth on it. It also means that a new version of the library can plug in new kinds of services later on, such as a new better DHT, and still coexist on the same application network and use the old services, if it wants to.