Final report cp2pc

common programming interface for peer-to-peer systems

By Maarten van Steen, Ihor Kuz

Background

The cp2pc project was initiated in 2002 aiming to construct a client-side "gateway" that would allow different file-sharing peer-to-peer networks to interoperate. Such a client-side gateway is often also referred to as an ÜberClient. The project was funded by the NLnet Foundation. The technical results of the project are summarized in an accompanying paper that will be submitted for publication in the Linux Journal. In this note, we make a brief assessment of the project. This assessment is motivated by the series of SIRS projects that have also been funded by NLnet. However, unlike SIRS, we made a serious attempt to improve the dissemination of the results of cp2pc.

The cp2pc Approach

The cp2pc project was split into two separate phases. During the first phase, we primarily concentrated on the feasibility of developing an integrating client, and spent time on studying existing P2P networks. The goal of this phase was to develop an initial architecture/design of an integrating client that was based on a commonly acceptable API. Designing the API was done after studying five different systems: Gnutella, JXTA, Mnet, CFS (a file system based on the Chord peer-to-peer system), and GDN (which has been developed as part of the SIRS projects).

The outcome of this work was an API that turned out to be very stable. Also, we achieved a good impression concerning the necessary components for the integrating client. Furthermore, not only did we have a founded choice for the P2P networks that were to be supported (namely Gnutella and GDN), but we also were able to write a reasonably detailed, yet flexible plan of work that gave confidence that actual results could be accomplished in a the following phase. The choice for Gnutella and GDN was partly based on the observation that these are internally two very different systems. Furthermore, Gnutella was chosen for its popularity. Our intimate knowledge of GDN was a main reason for choosing that system. Furthermore, it turned out that Chord had a number of serious portability problems.

The second phase, which started roughly four months after the start of the first phase, concentrated on actual development work. We used Java as our implementation language. As usual in most software projects, there were delays and set backs, but by-and-large, we eventually managed to deliver the promised results. The duration of the project was longer than expected, but the delay can be attributed almost fully to the fact that we simply put less effort per time unit into actual cp2pc efforts than originally planned. However, the quality of the actual client (i.e., its user interface) is not as nice as we initially aimed for. Also, much more time was spent on other parts of cp2pc than client development so that the client became available only late in the project.

Dissemination

Besides these two phases, we immediately set up a mailing list and actively participated in discussions with groups working on similar problems, notably Tristero. In the end, we managed to divide some of the work between Tristero and cp2pc by which results from either project were exchanged and incorporated.

Earlier in 2002, we had a poster session at the SANE conference in Maastricht. One of the important issues here was that we were forced to present ourselves in an early phase of the project, an activity which helped to keep us focussed on one of the goals of cp2pc, namely that eventually others would take over development.

Furthermore, to better disseminate results, Ihor Kuz attended the CodeCon conference to have face-to-face discussions with a number of Tristero members (a trip report is added to this note).

Conclusions

One of the most important results from this approach has been the wider and immediate dissemination of the outcomes of cp2pc. We have been approached by several groups claiming they did something similar, and have exchanged code with a number of them. However, it is only with the Tristero members that more continuous and active discussions and collaboration have taken place.

Despite the significant improvements in comparison to the SIRS projects concerning the way we handled the project, the effects of this approach is still difficult to measure. It is somewhat "encouraging" to have noticed that Tristero is having similar problems in disseminating results, but the fact remains that without actively seeking contact with other groups, the cp2pc results would have been known only locally.

However, we do feel that the attitude of having to develop code that should really be open in the sense that others can continue development, has resulted in code that is easier to understand and adapt. Along with the earlier and continuous feedback by external people, we feel that our code is much more open than, for example, the code developed in SIRS, which we consider an important achievement.

Availability

Documentation and code related to cp2pc is available through the project's Web site and through SourceForge.