Peer to Peer Messaging System

(Synopsis)

1

ABSTRACT

The project titled peer-to-peer Messaging presents the development of

an instant messaging application based on the concept of peer-to-peer

networking using JXTA platform. P2P (or peer-to-peer) networking is a

network model where, depending on an operation's context, any node

can operate as either a server or a client. The P2P architecture is a

decentralized architecture, where neither client nor server status exists

in a network. Every entity in the network, referred to as a peer, has

equal status, meaning that an entity can either request a service or

provide a service. The main goal of this project is to send instant

messages to peers in the JXTA network using JXTA relay.

JXTA defines a set of protocols to enable a framework for peer-to-

peer computing. All JXTA network users are peers to each other . Peers

communicate with each other to perform different tasks (such as

searching for new peers). Peer identifiers uniquely identify the peer on

the JXTA network The JXTA relay can accept client commands and act

upon the commands on the client's behalf. The relay acts as a junction

between the JXTA networks and peers.

JXTA has defined the data communication protocols that enable

messaging between a relay and a client. The JXTA relay receives

commands from a J2ME client, performs what's necessary on the

client's behalf, and represents a JXME client on the JXTA network. The

JXME client send messages to the relay. The relay discovers the peer

and route the messages to the destination.

INTRODUCTION

2

The traditional approach to information systems,

accessed by users by means of powerful devices (such as desktops

and laptops) with known features, will not be anymore significant in

the future years. Indeed, the current trend suggests that it will be

possible to offer continuous access to all information sources, from all

locations and through various kinds of devices, mainly small and

mobile (e.g., palmtops and PDAs, cellular phones). Therefore, the need

emerges for the design of applications for smart devices, which are

highly flexible, capable of exploiting in an optimal way the resources.

This Project analyzes the opportunity to design, develop and deploy

interactive applications running on smart cellular phones (commonly

referred to as smart phones), based on a peer-to-peer communication

model and GPRS technology.

PEER-TO-PEER (P2P) TECHNOLOGY enables any

network-aware device to provide services to another network-aware

device. A device in a P2P network can provide access to any type of

resource that it has at its disposal, whether documents, storage

capacity, computing power, or even its own human operator.

In the client/server architecture, clients request services and

servers provide those services. A variety of servers exist in today's

Internet -- Web servers, mail servers, FTP servers, and so on. The

client/server architecture is an example of a centralized architecture,

where the whole network depends on central points, namely servers,

to provide services. Regardless of the number of browsers or clients,

the network can exist only if a server exists.

3

CLIENT-SERVER MODEL

Like the client/server architecture, P2P is also a

distributed computing model, but there is an important difference. The

P2P architecture is a decentralized architecture where neither client

nor server status exists in a network. Every entity in the network,

referred to as a peer, has equal status, meaning that an entity can

either request a service (a client trait) or provide a service (a server

trait). Figure 2 illustrates a P2P network.

4

PEER-TO-PEER MODEL

Though peers all have equal status in the network, they don't all

necessarily have equal physical capabilities. A P2P network might

consist of peers with varying capabilities, from mobile devices to

mainframes. A mobile peer might not be able to act as a server due to

its intrinsic limitations, even though the network does not restrict it in

any way.

Although P2P might sound like a dot-com fad, the

technology is a natural extension of the Internet’s philosophy of

robustness through decentralization. In the same manner that the

Internet provides domain name lookup (DNS), World Wide Web, email,

and other services by spreading responsibility among millions of

servers, P2P has the capacity to power a whole new set of robust

5

applications by leveraging resources spread across all corners of the

Internet.

P2P networks shun the centralized organization of

the client/server architecture and instead employ a flat, highly

interconnected architecture. By allowing intermittently connected

computers to find each other, P2P enables these machines to act as

both clients and servers that can determine the services available on

the P2P network and engage those services in some application

specific manner. The main advantage of P2P networks is that they

distribute the responsibility of providing services among all peers on

the network; this eliminates service outage due to a single point of

failure and provides a more scalable solution for offering services. In

addition, P2P networks exploit

available bandwidth across the entire network by using a variety of

communication channels and by filling bandwidth to the “edge” of the

Internet. Unlike traditional client/server communications, P2P enables

communication via a variety of network routes, thereby reducing

network congestion.

P2P is the key to realizing this potential, giving

individual machines a mechanism for providing services to each other.

Unlike the client/server architecture, P2P networks don’t rely on a

centralized server to provide access to services, and they usually

operate outside the domain name system.

P2P has the capability of serving resources with high

availability at a much lower cost while maximizing the use of resources

from every peer connected to the P2P network. Whereas client/server

solutions rely on the addition of costly bandwidth, equipment, and co-

location facilities to maintain a robust solution, P2P can offer a similar

6

level of robustness by spreading network and resource demands

across the P2P network.

Unfortunately, P2P suffers from some disadvantages due

to the redundant nature of a P2P network’s structure. The distributed

form of communications channels in P2P networks results in service

requests that are nondeterministic in nature. For example, clients

requesting the exact same resource from the P2P network might

connect to entirely different machines via different communication

routes, with different results. Requests sent via a P2P network might

not result in an immediate response and, in some cases, might not

result in any response. Resources on a P2P network can disappear at

times as the clients that host those resources disconnect from the

network; this is different from the services provided by the traditional

Internet, which have most resources continuously available. P2P

overcomes this disadvantage by providing redundant access to a

resource.

7

Existing System

In the client/server architecture, clients request services and

servers provide those services. Clients connect to a server using a

specific communications protocol, such as the File Transfer Protocol

(FTP), to obtain access to a specific resource. Most of the processing

involved in delivering a service usually occurs on the server, leaving

the client relatively unburdened. The client in the client/server

architecture acts in a passive role, capable of demanding services from

servers but incapable of providing services to other clients. This model

of service delivery was developed at a time when most machines on

the Internet had a resolvable static IP address, meaning that all

machines on the Internet could find each other easily using a simple

name.

Limitations of the current system

The disadvantage of using client-server architecture is that as

the number of clients increases, the load and bandwidth demands on

the server also increase, eventually preventing the server from

handling additional clients.

Objective

The main objective of this project is to send instant messages

within a peer group in a decentralized network using JXTA technology.

Proposed System

8

The existing system operated on a client/server

mechanism in which a centralized server is required. While

communicating between the peer members in the JXTA network i.e.,

the proposed system, a peer name has to be given by the user in the

configurator window. The user is identified in the network using the

peer id. The peer member can secure his identification using the

password. The user should have an idea regarding the identification of

another person. Thorough knowledge of identifying the members,

adding the peers in the network, deleting the members from the

network are required.

9

Hardware & Software Requirements

Pentium IV Processor – 2 GHZ

NIC – 32 Bit Ethernet Card

40 GB HDD

256 MB DDR RAM

Mobile Phone

JXTA Proxy Server

J2SDK 1.4.2_06

J2ME WTK 2.0

Windows 2000 Server

10

The project Peer-to-Peer Messaging is divided into three major

modules:

Element

Message

Peer Network

ELEMENT MODULE

The Element represents a single element of the JXME

message. The JXME implementation uses the Element to author JXME

messages. A pure P2P system does not require the existence of any

centralized servers or resources to operate. Therefore, a P2P system

must not rely on any centrally administered naming or addressing

system.

The first module of the project deals with entering the

member into the JXTA network and to enable them to chat with other

members of the group. Batch file called myjxta will be run first. In the

advanced settings tab, TCP option has to be enabled. Incoming and

outgoing connections has to be enabled. Port number of the system

has to be provided in the http settings. The peer who wants to become

the member of the JXTA group will enter with the peer name. Only

authenticated users can enter the network as password is required. In

the relay host, proxy id should be given for communicating with the

other peer. When all the settings are completed, the peer member has

entered the network and is ready to communicate with all members in

the NetPeerGroup.

MESSAGE MODULE

The message module is designed for the peer members to

communicate with each other in the network. JXME does not define any

special request message that explicitly asks the relay to send one or

more response messages it has for the JXME client. The JXME client

11

continues to send requests (for example, a peer group join request, a

pipe creation request, or a search query) or other outbound messages

to the relay. The relay avails these requests as opportunities to send

any incoming message to the JXME client in response to a request. The

JXME client uses the request Id element in the response message to

find out which request this response corresponds to.

JXTA peers use pipes to send messages to one another. Pipes

are an asynchronous and unidirectional message transfer mechanism

used for service communication. Pipes are indiscriminate; they support

the transfer of any object, including binary code, data strings, and Java

technology-based objects. The pipe endpoints are referred to as the

input pipe (the receiving end) and the output pipe (the sending end).

Pipe endpoints are dynamically bound to peer endpoints at runtime.

Peer endpoints correspond to available peer network interfaces (e.g., a

TCP port and associated IP address) that can be used to send and

receive message. JXTA pipes can

have endpoints that are connected to different peers at different times,

or may not be connected at all.

PEER NETWORK MODULE

The Peer Network contains the methods to allow the JXME

communication with the relay. The Peer Network is like a

communication module that internally uses different Message and

Element objects and handles all communication with the relay. Peer

Network has methods to perform the various tasks between the relay

and the mobile client. The Peer Network manages all the messages

and maintains the support tasks, maintaining the identity of various

messages exchanged between the relay and the client.

12

The third module deals with the implementation of communication

between JXTA peers in the midlet. Proxy id should be given and the

peer enters the group with a peer name. There are various options like

sending the message, reply, connect to the relay, Buddy list,

configuration and default settings. Using the various options,

messages can be sent, reply can be sent to the received message and

connection can be established with the relay. Using the buddy list

menu, members can chat, new members can be added to the group

and the members can also leave the group.

13