Flypeer Dynamic Peer-To-Peer Infrastructure Wiki

Welcome to Flypeer

Flypeer is basically a Peer-to-Peer Infrastructure developed using SOA ( Service-oriented architecture ) concepts where you can easily create, deploy and execute services taking advantage of all P2P benefits.

Getting Started

Download the latest version.
A Hello World Flypeer example.

Features

Check the roadmap for more details.

Known Issues and Limitations

Internal Model

The core of the P2P layer is based on a modelling done by the University Of Surrey. Related papers should be available for download from this site soon.

Following is a short description of our work so far and, perhaps more importantly, description of the work that still needs to be done.

At the very core of the infrastructure there is a transaction module. This is where we are now mostly focused on. Among others, we are considering three types of transactions:

Sequential: when actions occur one after the other;
Alternative: when one action occur and, if it fails, another one takes place;
Parallel: when two actions occur at the same time.

Implementation of the sequantial transaction is almost ready. Alternative transactions will be targetted next, last followed by parallel.

With transactions working, we will define the so called Virtual Private Networks (VPTNs), based on the nodes interacting through transactions. And these VPTNs will provide the base for building Dynamic Virtual Super Peers (DVSPs), which are the final goal of the infrastructure core.

Examples

In parallel to the implementation, we are working on two small demos, to help us keep the code working while doing several big changes:

Travel agency: a simulation of a travel agency booking hotels and flights;
Chat: a small text chat client.

Besides that, we might have EvEsim working on top of our infrastructure at some point.

Other Dependencies

We are working on a few internal structures that are pretty important, yet they don't directly fit the above description. So here are some of them:

Peer state handling: defining how each peer will keep its internal state, such as current transactions, transaction's contexts, among other things;
Local and Remote Service Repositories: repository of the services provided by the local peer, as well as provided by remote peers;
Business services interfaces: we are trying to defined a nice and easy way for users to build services on top of the infrastructure. But this work is still very raw.

And more than that, there are some items we haven't started to work on yet, but will sooner or later require our attention:

Service Deployment: how are the services going to be deployed to the peers it will run on? For now, we are just embedding it in our test environment, but we certainly we need something more flexible in the future - and this might come together with modularization;
Applet / JS communication: we will need some way to easily allow javascript code to communicate with a peer run in the local browser - we currently test the infrastructure running inside browsers, but not an eventual communication of that kind yet;
Error handling: we need a more clear and user friendly way of handling errors, something more than just printing messages to the console;
Lock system: this is something important when two peers start to compete for resources. Who should get it? Until when? And so on...