May 2, 2003

Why we chose to develop our own p2p framework rather than use JXTA:

We spent a couple days getting comfortable with JXTA—getting familiar with its source code and interface—and we decided to develop our own P2P framework. We did this because we wanted to have a very good understanding of how a P2P network works and we felt the best way to do this was to develop a P2P framework from the ground up. Furthermore, developing a P2P framework from scratch seemed more appealing and more beneficial to ourselves rather than extending off of JXTA.

Initial Network Design:

In order to get comfortable with networking, we decided to build a main server-client network similar to the design of Napster. All clients in the network will connect to this main server and the server will process all the commands from the clients. Each client will also have their own server so that other clients can directly connect to him.

Initial-P2P Chat:

Our first P2P application was a single client-single client chat program where the clients are directly connected to each other (ie, none of the chat messages get routed through the server). This Chat worked in the following way:

1. The client initiating the chat will first ask the main server for a listing of all the clients on the network.

2. The client initiating the chat will then ask the main server for the IP address of the client he wishes to chat with.

3. The client initiating the chat will then make a direct connection to the second client’s server.

4. Console windows will appear on both clients

5. Chatting between the two clients commences.

File Sharing:

Our second P2P accomplishment was a file-sharing application. We chose to develop this application to show the extendibility of our framework to handle multiple types of applications. The file-sharing worked in the following way:

1-3 Same as Initial-P2P Chat

4. The client requests a listing of the shared files from the second client

5. The client the requests a single file and the second client sends the file.

Design of Current Code:

After developing these Initial-Chat and the File Sharing applications we saw the need to refactor the code to make it more extendible and flexible. The current design is as follows:

There is no distinction between a main server and a client. Every peer on the network is both a client and a server and is capable of performing all the functions of our initial main server. In a sense, the peer acts a “main server” for all the peers that are connected to it—ie, there is no forwarding on of queries or commands sent from a peer to the peer it is connected to. For instance, if peers A, B, and C are all connected to peer D, and peers D and F are connected to peer G, then A, B, and C have knowledge only of A, B, C and D, and F has knowledge only of D and G.

Peers communicate with each other by sending Nettable objects. A Nettable object is essentially an “information packet” asking the receiver to perform a certain task. The receiver creates a corresponding InfoReceived object based on the certain type of Nettable. (ie, a ChatInitInfoReceived object is created when a ChatInfoNettable is received). The InfoReceived object is required because each peer has an instantiation of its utilities that are independent of all other peers. These utilities include the peer’s sockets, input/output streams, Adminstrators for applications, and so on which are necessary to handle a task such as initializing a chat conversation. The InfoReceived object is then executed.

A system of factories is used to create the appropriate InfoReceived object for a given Nettable. This improves the extensibility of the framework, for new applications simply need to write the necessary Nettables and InfoReceived objects to implement their application.

Design of Multi-Chat

The ease of the addition of the Multi-Chat application proved that the refactored design of our framework was greatly improved. It uses the same P2P-aspects of the initial Chat (asks the server for the peers he wants to chat with and a direct connection is made amongst chatting peers), but can now handle any number of peers involved with a chat session.

Future Work:

After An Administrator for each application that contains all the logic for a specific application. For example, the ChatAdministrator will house the ChatNettables, ChatInfoReceiveds, ChatFactory, ChatMessageRouter and anything else associated with the chat application. Under this design, the framework of the P2P network will receive a Nettable, determine which Administrator it belongs to and then send that Nettable to the appropriate Administrator. Additionally, the Utilities map can now hold strictly the tools necessary for all applications—particularly the socket and input/output streams. This will further decrease any unnecessary shared data between applications.

An improved login system to facilitate better connecting to the network (will the user have to specify the IP address of the peer to connect to?) and passwords if need be.

Ability to send queries throughout the entire network (ie, not having have queries end at the server a peer is connected to).

A more user friendly GUI.