Since a few weeks ago, we’ve been involved in a peer-to-peer project, somewhat deeply – and a little less than this before. Then, in the last two weeks, we started to implement something. Just a small demonstration code (for now), to be sure the work is feasible.
So, first question: What?
After some discussions, we decided to use guigoh‘s conference as a first scenario to test the ideas. But before that, we should be able to have some independent peers communicating. This would be the very foundation for any work that comes later. Something like this:
This means that Peer1 must be able to reach Peer2, and any other Peer, across a network. It shouldn’t have to worry about the details on how to find and send a message to them. Also, the peers cannot depend on any central server or any kind of node that could represent a single point of failure. And the same must be true for all peers.
Based on some ideas from guigoh‘s conference application, and from the Dynamic Virtual Super Peer (DVSP) model (more on this one in a future post, if Amir and Sotiris don’t mind ;)), plus the small concept explained above, we planned what should be done in terms of functionality. So this is it, in two simple steps:
The conference initialization: One peer creates a new conference, store its information in what we are calling ConferenceContext, and send invitations to the other peers it wants to have part in the conference. The ConferenceContext is also sent with the invitation. Each of these peers can accept or decline the invitation, which will then define who the conference participants are.
An ongoing conference: When the time for the conference arrives, a conference window is displayed at the peer’s screen. In this window, the user can type messages that the peers will exchange between themselves. In the end, it is a simple chat, but in a pure peer-to-peer architecture.
Now for the difficult question: How?
The next decision was technological: how is this going to be implemented? Doing everything from scratch is probably not a very good idea. Just Imagine having to write firewall traversal code by yourself, for a simple example of the trouble. There is just too much basic infrastructure work that would be necessary. And thus a lot of resources, which we don’t have.
There are a few options around the web, but not that much actually. I won’t list them here because I don’t tend to remember things I put aside (sorry :-p). The important thing to mention is the chosen technology: Jxta.
I won’t dive into Jxta right now. Instead, the next post will probably be about it. So if you have any questions feel free to send it to me, and I’ll try to address them.