P2P Pond is meant to be the P2P software solution to connect clients P2P Networking is meant to be the hardware mesh of ground stations

• taking an existing open source P2P
• universal for computation (BOINC) and sensor grid data gathering (data relay)
• failsafe, self healing, redundant
• no central or super node, if possible
• levels of quality (wan, lan, bybrid)
• substitute player for calculations (⇒ failsafe, less rework)

There are two main sub-projects associated with the development of a P2P network for HGG: one dealing with hardware and one dealing with software. It is also important to remember that there is a difference between a mesh network and a P2P network: http://p2pfoundation.net/Mesh_Networks . That distinction is probably important for the hardware component. I am planning to concentrate on the software component.

As developers we can either modify an existing open-source network and customize it to fit our needs or build everything from scratch. I am in favour of the latter since none of us has a deep knowledge of P2P networking and programming. Starting from fundamentals would allow us to learn about technologies gradually instead of drowning in the sea of code from a huge open-source project.

My plan would be to start with one of the simpler protocols described in the many papers on the subject, for example Chord, which was one of the first in existence. Once we have successfully created a network based on this protocol, we will be in a position to extend it and adapt it further because of the knowledge we will have gained. Even if libraries exist for these protocols, I still think it is worthwhile trying to implement a working version ourselves first.

On the other hand, if we were to modify an existing network, then I would be inclined to choose one of the file-sharing networks (as opposed to networks like Skype, streaming video). These will most likely have the models and infrastructure necessary for our needs. Since we are trying to save time with this method, I would deliberately choose one of the more advanced networks to try and get the most „bang for the buck“ regarding features. I do not think we should let the complexity of a particular system put us off – all of these networks are complex enough anyway, so a little more cannot hurt. It is also important to note that the most successful networks, such as Skype, are closed source anyway.

Anyway, this would definitely be possible and we may even see faster gains in the beginning, but it would be important to extract only the code and modules that we actually need. I feel that large chunks of code may be unnecessary for our project, but we would be forced to leave them in because we might not truly understand how they work.

I am not the project leader, but unless anyone has objections, then for the moment, my immediate short-term plan is to start implementing the Chord protocol in C. It will be necessary to write cross-platform code, but I think this can be dealt with as time goes on. Once a basic protocol is working, then I will see where I can go from there.

hadez' comments:

• tinc mesh VPN darknet for node interconnect similar to the system deployed as part of krebs

* nice course on p2p networking and how to implement it in java or python (with example app) http://cs.berry.edu/~nhamid/p2p/index.html