Tag Archives: jxta

Quick Jxta Introduction

According to the classical definition of a peer-to-peer network, peers that are part of this network should be able to run both as a client and as a server. This is what Jxta allows you to do.

Jxta is a platform for developing peer-to-peer applications. It supports the definition stated above, plus a lot of infrastructure features that most peer-to-peer applications might need. One example of such a feature is firewall traversal, which is done transparently for us. Also, it has some other very important qualities:

  • It is open source and thus publicly available;
  • It is programming language agnostic – there is at least a Java, a C++, a Ruby and a mobile implementation;
  • It is communication protocol agnostic: it can run on top of TCP, HTTP, Bluetooth etc.

It is important to note that Jxta is not an API – that’s why it can be independent of the programming language. Jxta defines a set of protocols, that can be implemented in a variety of different platforms. Currently, these are the protocols specified by Jxta:

  • Peer Resolver Protocol (PRP): provides the foundation for sending and responding generic queries between peers
  • Rendezvous Protocol (RVP): used to help propagating queries between peers
  • Peer Discovery Protocol (PDP): used to allow peers to publish and find resources (like other peers, services etc)
  • Endpoint Routing Protocol (ERP): provides the mechanism that a peer can use to find routes to other peers, hiding low level details
  • Pipe Binding Protocol (PBP): provides the means to make a connection between two peers
  • Peer Information Protocol (PIP): used to get information from a peer, like its status or provided services for example

Those are of course very basic definitions of the protocols, but should be enough for now.

Jxta is not difficult to learn but it is extensive. If you are to fully use it, you have a lot to learn. You can find a lot of resources on the internet. There is the official site, which is the best starting point. And the community is active in the mailing lists. Also, I’m currently reading this book, which you can download for free.


A peer-to-peer project

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:

peers communications across a network

peers communicating across a network

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.


Follow

Get every new post delivered to your Inbox.