Peer peer messaging system (synopsis)
Upcoming SlideShare
Loading in...5
×
 

Peer peer messaging system (synopsis)

on

  • 384 views

 

Statistics

Views

Total Views
384
Views on SlideShare
384
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Peer peer messaging system (synopsis) Peer peer messaging system (synopsis) Document Transcript

  • 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-topeer 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 peerto-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. 2
  • INTRODUCTION 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 View slide
  • 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 View slide
  • 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 5
  • 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 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. 6
  • 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 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. 8
  • Proposed System 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 11
  • 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 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 12
  • and maintains the support tasks, maintaining the identity of various messages exchanged between the relay and the client. 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