Im Report

An efficient implementation of client server chat application
Chapter -1
Introduction
1.1 Preamble
The enormous growth of the Internet initiated various new trends. Significant technology enhancements brought distributed systems, which allow applications to run on multiple machines at different locations. Distributed systems allow scalability, robustness, and efficient use of available resources. However, distributed system components needed more powerful communication methods than the simpler client/server architecture. Common techniques based on remote procedure calls or plain sockets could not satisfy the need. Independently from the enterprise domain, a complementary type of distributed systems, the peer-to-peer networks emerged. These huge networks follow a decentralized approach and harvest the resources of each peer. They do not depend on dedicated network servers to provide services. Each peer is considered as a servant, a server and a client simultaneously. A peer may request services from other peers while it provides services by itself to different peers. The peer-to-peer concept became popular with file-sharing applications, like Napster, Gnutella (Gnutella 2002), and the proprietary Fast track network. However, the peer-to-peer concept is not restricted to this application type. For example, Suns JXTA provides a general peer-to-peer platform independent from any application purpose. Currently, there are various efforts being made to harvest the enormous resources of peer-to-peer networks. Examples are distributed file systems (Druschel and Rowston 2001), distributed processing frameworks (Distributed Net 2002), and content delivery networks (Kontiki 2002). In short, peer-to-peer networks may lead to a paradigm shift and may replace client/server architectures for several purposes. Peer-to-peer architecture is a type of network in which each workstation has equivalent capabilities and responsibilities. This differs from client/server architectures where some computers are dedicated to serving the others. Peer-to-peer networks are generally simpler but they usually do not offer the same performance under heavy loads. The P2P network itself relies on computing power at the ends of a connection rather than from within
Dept. of CS & E, JNNCE. 1
the network itself. P2P is often mistakenly used as a term to describe one user linking with another user to transfer information and files through the use of a common P2P client to download MP3s, videos, images, games and other software. This, however, is only one type of P2P networking. Generally, P2P networks are used for sharing files, but a P2P network can also mean Grid Computing or instant messaging. One very common form of P2P networking is Instant Messaging (IM) where software applications, such as MSN Messenger or AOL Instant Messenger, for example, allow users to chat via text messages in real-time. While most vendors offer a free version of their IM software others have begun to focus on enterprise versions of IM software as business and corporations have moved towards implementing IM as a standard communications tool for business. Along with this it also includes features like file sharing, audio/video streaming and conferencing, image transfer, and sending information to mobile.
1.2 About Project Scenario

In this project we are implementing a Cost effective information distribution system to provide personalized services in heterogeneous networking environment. The proposed model can work in any kind of environment like wired or wireless. In wireless network, base stations are used for connecting to end mobile user. Gateways are used in wired network for connecting different LAN to internet. This model provides a number of services such as Instant messaging, Integrated LAN messenger, Contact list., File transfer ,Group chatting ,Image transfer, Audio/Video streaming, Simultaneous login into different accounts.
1.3 Existing System

Following are the systems that already exist.
1.3.1 Client/Server Architecture

A Client Server network is a distributed network which consists of one higher performance system, the Server, and several mostly lower performance systems, the Clients as shown in fig 1.1. The Server is the central registering unit as well as the only provider of content and service. A Client only requests content or the execution of services, without sharing any of its own resources. In a client server model, the client makes requests off the server with which it is networked [1]. This system has a as software running on it and is connected to various Client that have limited functionality. The server, typically an
unattended system, responds to the requests and acts on them. Examples of this are Windows NT and Novell NetWare.
Fig 1.1: Client/Server model Example of client/server:

MSN Messenger: MSN Messenger contains features that are similar to other instant messaging clients, including communication through text, voice, and video. These features that provide communication cannot be regulated and logged in ways that other systems, such as email, can. These unregulated communications may result in the distribution of confidential information to parties that should not be privy to such information. Social engineering may play a part in data leakage, by convincing users to part with sensitive information or files. By posing as a known contact, a malicious user may be able to obtain information easily. It is recommended that sign-in and passwords are not stored on the client, which will reduce the risk of someone using your workstation to masquerade as you to obtain information from your contacts. Another way to safeguard information would be to limit sensitive and personal information from being discussed with others online. You should never give out credit card or other personal information to anyone online. Without the network controls that are available to other systems, files and executables can be transferred with almost no safety, creating avenues of attack for malicious users. These transfers can also involve the movement of copyrighted materials, such as MP3s, movies, and licensed software. MSN, like other instant messaging clients, does not have a restriction on the size of file transfers. Malicious
code has the ability to spread quickly through instant messaging networks, circumventing protection that has been put in place to prevent worms and viruses from spreading. Instant messaging clients can bypass security devices such as firewalls, URL filtering, and gateway security devices, promoting the spread of malicious code. Many of these worms spread via URLs displayed within a message from a contact. By clicking on such a link, a user will infect his or her workstation [2]. Users should never click on a URL embedded within an instant message, especially from an unknown contact.
Fig 1.2: Architecture of MSN
1.3.2 P2P Architecture:

P2P model is a communication model in which each node may act as a client and a server. Therefore, a number of peer processing nodes exist that are communicating with one another. At times a node can request a service from another node while at other times it could be providing service. P2P architectures can be classified into pure P2P architectures where nodes Communicate directly with each other and quasi-P2P architectures where the nodes use multiple centralized servers to allow peer discovery, look up and better scalability with reduced degradation in performance [12].
Fig 1.3: Peer To Peer Network
Example of P2P:
Napster Architecture: As a P2P network, Napster did not host, post, or serve MP3 files; rather, MP3 files were hosted on the clients' PCs. Napster's central network server was used instead to maintain an index of the MP3 files available on each connected client's PC. Clients would need to download the Napster software and load it onto their machine. From there:

They would open the utility. Napster would check for an internet connection. Once connected, the user would be logged onto the central server. The main purpose of the server was to keep an index of all the MP3 files on the computers of Napster users currently online and connect them to each other. As stated above, it did not contain any of the MP3 files themselves.
The client would type in a query.
The Napster utility on the client's machine would query the index on the Napster Central Index Server for a match from any other computers online. When the central server replied, the Napster utility on the client's machine built a list of the matches in the results window. The client would choose the file from the list that they wanted to download. The Napster utility would try to establish a connection with the computer hosting the file, and if successful, the file would begin to download.
Fig 1.4: Napster Peer to Peer System
1.3.3
Problem of Existing System

There are two main reasons why current Information transfer systems are less usable
in decentralized environments. Firstly, they usually rely on dedicated data servers, which can be setup, maintained and accessed within an enterprise infrastructure relatively easy. However, such infrastructures are seldom available outside enterprises. Secondly, information transfer systems are usually designed to provide a high degree of reliability while
performance issues were regarded as less important. The performance penalty due to the overhead of current data transfer systems makes them inappropriate for applications requiring less reliability but more performance. Nevertheless, special measures are required for peer-to-peer networks. Despite their great potential, they still lack efficient group communication mechanisms. Current peer-to peer networks suffer from several problems. Firstly, the topology of the network is more or less random. Slow peers may slow down entire network branches. Secondly, the topology is static and prohibits dynamic adjusting to alternatives that would be more efficient. Lastly, group communication data has to traverse peers, which are not group members but happened to be on the group communication route. This result in consuming bandwidth of not involved peers and it may slow down the group communication as additional network nodes have to be traversed. The second goal of this project is to deal with these problems and provide a suitable solution for peer-to-peer networks with their heterogeneous and dynamic character. The fundamental idea is to make a virtual overlay network for each topic group to be independent from the existing peer-to-peer network. Thus, the topology can be setup more efficiently. In addition, the topology may also be adjusted dynamically to adjust to changes and optimize the delivery. Finally, it only consumes the bandwidth of involved peers since the virtual network includes only peers interested in a topic. In short, the contribution of this is providing high performance information transfer concepts for server-less applications and especially peer-to-peer networks.
1.4
Objectives
The following are the objectives of the project:
Study of client/server and peer to peer computing architectures.
To design and implement cost effective information distribution system over an
existing networking infrastructure that implements the following features: LAN Messenger, Instant Messenger and File Sharing.
Multimedia information sharing is also proposed such as audio/video conferencing is
also proposed. To implement the proposed system using Java platform over Linux / Windows.
An efficient implementation of client server chat application To verify and test the information distribution for various services and various
devices.
1.5 Scope & Necessity:

The use of Internet evolves exponentially day by day. It is also becoming cheaper to use, which is drawing more and more people are starting to use Internet for personal interactions. People want to have a way of keeping in touch with all there friends. Instant messengers are the best way for that. It will be better if instead of having different messengers for different category of people, we could provide a single messenger that helps them to log into all the different accounts from a single program. The scope of this project expands exponentially in the near future. As in the field of information sharing, the use of video conferencing is fast becoming the necessity of the new business trend, where the administrators want to interact and give directions to their subordinates visually in real time.
1.6 Organization:
This report is divided into 6 chapters.Chapter-2 deals with brief description about Peer to Peer Network. The requirements of the proposed system are discussed in Chapter-3. The design and implementation mechanism is explained in Chapter-4. Chapter-5 presents the results of the work for different test scenarios, the report ends with conclusion and future scope in the last Chapter.
1.7 Summary
This chapter discussed and introduced the current architectures that are in place as of now. The next chapter will discuss the concept of Peer to Peer computing in details.
Chapter 2
Peer to Peer Computing

This Chapter deals on peer-to-peer computing paradigm to Network and Internet architecture and communications. Many important industries regard this as revolution and characterize it as the instrument for the Third Generation of Internet. The different prevalent architectures of internet till date are also presented.
2.1 Different Architectures present in the Internet

The Internet is not structured in a single way, with a single structure or architecture. There are very many different types of architectures bossed out of the needs of particular times, the available computing powers and the feasibility. The most common and well-known model is the Client Server model. This is the traditional model and its structures and working is rather understood by many. The other architectures that are not so common but can be grouped separately are called as Master Slave and Consumer Supplier models [3]. The other model that is also present and picking up volume and popularity is the Peer to Peer model.
2.2
Client Server Model

A Client Server network is a distributed network which consists of one higher
performance system, the Server, and several mostly lower performance systems, the Clients. The Server is the central registering unit as well as the only provider of content and service. A Client only requests content or the execution of services, without sharing any of its own resources [2]. In a client server model, the client makes requests off the server with which it is networked. This system has a as software running on it and is connected to various Client that have limited functionality. The server, typically an unattended system, responds to the requests and acts on them. Examples of this are Windows NT and Novell NetWare. It is a noticeable fact that it is only the client that can initiate a connection between the two systems. The server can in no way search for a client or initiate a connection.
Server store databases, files, programs and more that are shared across the network with clients. This architecture allows access to data, information and resources through the server.(there is no other from of sharing).This is by far the most popular model for various business purposes. These centralized servers have two fundamental problems: scalability and resiliency.
Scalable: A system if the load on the system increases at a linear at a linear rate with an increase in users.
Resilience: A system is resilient if it is able to function correctly after one or more competent failures.
2.3 Peer To Peer Model

A distributed network architecture may be called a Peer to Peer network, if the participants share a part of their own hardware resources (processing power, storage capacity, network link capacity, printers).These shared resources are necessary to provide the service and content offered by the network (e.g.: Text message, File sharing and audio/video sharing etc) They are accessible by other peers directly without passing intermediary entities. The participants of such a network are thus resources (Service and Content) providers as well as resources (Service and Content) requestors (servant and context) [6]. P2P networks work on the concept of servant (server-client) which means a node can act both as a client and server. This is totally different from Client Server Computing model where a node can act as either as client or server but not both. While a peer is a computer that behaves as a client in the client/server model, it also contains an additional layer of software that allows it to perform server functions. This additional functionality allows the peer computer to respond to request from other peers. The idea of having computers (peers) talk to each other is not new. Even the traditional Client Server architecture had servers talking to each other. And as a parallel to Peer to Peer systems of present, we would say that those servers are peer nodes in their own sense. So the fact of peer-to-peer architecture cant be the explanation for the recent interest in Peer to Peer [9]. With the peer-to-peer concepts are:
An efficient implementation of client server chat application a) The nodes of these P2P systems are -- Internet-connected PCs which had been
formerly relegated to being nothing but clients and

b) These nodes are at the edges of the Internet, cut off from the Domain Name System
because they have no fixed IP address.
P2P computing provides an alternative to the traditional client/server architecture. While employing the existing network, server and client infrastructure, P2P offers a computing model that is orthogonal to the client/server model-the two models coexist, intersect and complement each other. As mentioned before with P2Pcomputing, each participating computer, referred to as a peer, functions as a client with a layer of server functionality. This allow s the pee to act both as a client and as a server within the context of a given application.P2P applications build on such functions as storage, computations, messaging, security and file distribution, when handled through direct exchanges between peers. A peer can initiate requests, and it can respond to requests from other peers in the network. The ability to make direct exchanges with other users liberates P2P users from the traditional dependence on central servers. User has a higher degree of autonomy and control over the services they utilize. One significant difference of Client/Server networking compared to Peer to Peer networking is that the clients do not share any of their resources (storage capacity, computing power, network connection, and bandwidth, content).In the Client/Server concept exists only one central entity, which provides all the content and services which are in a certain network. One of the greatest benefits of P2P computing is community.P2P makes it possible for users to organize themselves into ad hoc groups that can efficiently and securely fulfill request, share resources, collaborate and communicate. As P2P computing evolves, we can anticipate the emergence of a wide variety of these online communications [11].
2.3.1 Drift towards P2P architectures

Technically, P2P provides the opportunity make use of vast untapped resources that go unused without it. These resources include processing power for large-scale computations and enormous storage potential.
P2P allows the elimination of the single-source bottleneck.P2P can be used to distribute data and control and load-balance requests across the net. IN addition to helping optimize performance, the P2P mechanism also may be used to eliminate the risk of a single point of failure. When P2P is used within the enterprise, it may be able to replace some costly data center functions with distributed services between clients. Storage, for data retrieval and backup, can be placed on clients [13]. In addition, the P2P infrastructure allows direct access and shared space, and this can enable remote maintenance capability. The concept that underlies the P2P computing model, that is, direct exchange and sharing of text files and cycles between nodes, is not a new computing concept. It is hence reasonable to ask why the P2P model is on the scene at this time. Several essential developments have made P2P for the masses possible. The ubiquity of connected computers has come close to enabling anywhere, anytime access to the net and its resources. It addition, there is a critical mass of computer users. Improvements in communications bandwidth, still on a fast-track growth curve, make it possible to move large amounts of data and rich media content from one location to another. And todays PCs are sufficiently robust, in terms of processing power and storage capacity to handle the extra services required in a P2P environment.
2.3.2 Classification of P2P Architecture

When it comes to peer-to-peer computing, there are mainly two types of architectures that are most widely used [14]:
Peer to Peer Pure Hybrid
Pure peer to peer: This comes under the category of Centralized network topology. Here all peers are equal. Hybrid peer to peer: This can include any of the existing models, but typically is the decentralized model. Here special services and data (credential authentication) reside only in special peer.
2.3.3 Layered Architecture of P2P

The layered architectures of P2P is shown in Fig 2.1. It consists of following infrastructure components [16].

Communication requires application-level connectivity in spite of disruptions, intentional (PC switch off) or not (out of wireless range PDA). Group management and peer-discovery can be in a continuum between distributed (for devices relying on a limited range of communication) and centralized (for wired device)
Robustness through redundancy Security has to be outsourced because it is too complicated to ensure Resource aggregation is handled differently depending on whether Reliability is accomplished through replication (of content or of task that all nodes are secure servers.
resource is content or computing capability.
assignment). Class and application specific components such as scheduling and management.
Fig 2.1: Layered Architecture

2.3.4 Characteristics of P2P

Given the various architecture for a given peer to peer model, there are certain characteristics that have to be looked into to compare and measure their potential advantages. There can be no conclusion in saying that a particular architecture is the peer model. Depending on the application needs and requirements, the best-suited structure can be used [11]. The following properties can be used to measure the architectures.
Decentralization
Every peer is an equal participant. Every peer hosts data and computations relevant to it. Network discovery is inefficient
The peer has to join the network knowing one peer at least - and then discover the rest by copying its neighbors routing table.
Scalability
Scalability is limited by
How
much
synchronization
and
coordination
is
performed
(downloading from peers). How much state that needs to be maintained (prime numbers). How parallel the application is (SETI@home, file sharing).
Increased scalability may cause deterioration of performance Blind flooded requests to a small number of immediate neighbors Document/peer ID mappings enable smarter requests, with (recursively) cause high network traffic.
guarantees that the object will be retrieved if the owner peer is connected, with little state.
Anonymity
People can use systems without legal or other ramifications. Censorship of digital content is not possible.
15
Dept. of CS & E, JNNCE.
Basic forms of anonymity: sender, receiver and mutual. A spectrum of anonymity degrees: absolute privacy, beyond suspicion, probable innocence, provably exposed. Techniques in support of anonymity
Multicasting: (receiver is beyond suspicion). Spoofing the senders address (the senders identity is private). Identity spoofing (sender is beyond suspicion). Covert paths for sender-receiver communication anonymity. Intractable aliases through a trusted server (between absolute privacy and beyond suspicion) Non-voluntary placement (through hashing) for server anonymity.
Self-Organization
A process where the organization (constraint, redundancy) of a system
spontaneously increases, i.e., without this increase being controlled by the environment or an encompassing or otherwise external system [Heylighen1997].
P2P scale (number of systems, number of users, and the load) is unpredictable. The network faces intermittent disconnections; Self maintenance and Types of self-organization:
adaptively has to be distributed over the peers.
Routing information continually updated. Node arrival/departure protocols for effective network maintenance Spontaneous assumption of super-peer status
and routing-length guarantees
Cost-of-ownership
The group has resources that no single participant could own, which enable it Napster users share music files SETI@home members share computing cycles 802.11b users share bandwidth (parasitic grid)
to perform activities that otherwise would be very costly.
Ad-hoc connectivity
Content sharing users expect interruptions as a default. For parallelized compute-power sharing, service level agreements may For collaborative applications
necessitate computation replication.
users are increasingly expected to be connected delayed communication is enabled by proxies Ad-hoc group formation is increasingly the norm
Performance
It depends on three types of resources: processing, storage, and There are three approaches to it:
networking.
Replication of objects closer to the requesting peers Caching objects across the response path Intelligent routing through good (with common interests, or high fan-
out degree) peers Milgram 1967 - small-world phenomenon study
Security

Multi-key encryption (shared secrets among multiple entities, i.e., sender router.
receiver
Sandboxing for executing peer code, so that it does not infect the peer - data flow analysis, model checking. Watermarking/Stegnography to protect digital rights on content Reputation and accountability to enable trust among peers, exhibiting desired behavior (high quality content on offer, no freeloading) mutually
2.3.5
P2P goals
Cost sharing: Servers are more expensive than servants (Napster shares disk space and bandwidth, SETI shares unused computational cycles)
Scalability and reliability: Work on algorithms for discovery in the absence of centralized authority has nabbed optimization or (otherwise underutilized) resources utilization.
Increased autonomy: Each servant hosts data and computation pertaining to it (which would not have been hosted by any server). Anonymity and privacy: Servers know their clients; in P2P systems operations occur locally (Free net uses probabilistic routing to prevent network-traffic monitoring to enable clues as to the message origin).
Dynamism: Servants join and drop out opportunistically (buddy lists).
2.4 Summary
In this Chapter we have discussed peer-to-peer computing. Firstly it describes about the various architectures currently present in the internet. Further it deals with the classification of P2P and finally their characteristics are described. The next Chapter contains software requirements and specifications.
Chapter 3
Software Requirement Specification

Software requirement specification of the proposed system comprises of functional and non-functional requirements. The Chapter explores the SRS of the proposed system.
3.1 Functional Requirements

The functional requirement of a system gives the test of the functionalities to be achieved. The different functional requirements of the proposed system are:
a) Instant Messaging.
b) Group Messaging
a) Instant Messaging
Instant messaging (IM) is a form of online communication that allows real-time interaction through personal computers or mobile computing devices. Users can exchange messages privately, similar to e-mail (although here it is instantaneous in reply), or join group conversations. Although typed text remains the primary convention for IM, the technology has grown significantly from early versions and now allows users to send images, audio and video files, and other attachments. The interactive nature of IM is closer to spoken conversation than written correspondence, allowing users to communicate in a manner that email does not. IM users have a sense of presence of other users, as if they were in a room together. At the same time, the technology facilitates the kind of on-screen interaction, with its perceptions of distance and safety, that many find especially comfortable.
b) Group Messaging
A message is sent from a sender to one or many receivers. A sender can be seen as a publisher with multiple recipients, the subscribers. The association between the publisher(s) and its subscribers is often defined by a topic. Publishers post messages to a specific topic. All the subscribers, which expressed their interest in this topic, receive these messages. Often it is a one-to-many communication; but it can also be many-to-many communication, if
multiple publishers are involved. Peer to Peer systems usually support publisher/subscriber concepts.
3.2
Non functional Requirements

The following are the different non-functional requirements of the proposed system:
a) Manageability
In certain cases it is necessary to be able to manage the whole system. Manageability refers to the ability to control and overlook the system. In the P2P system the status of different users are managed in the distributed fashion network management issue.
b) Information coherence
Information coherence refers s to the assurances that the available data at any node is up to date with respect to content or version. It is a measure of how authoritative the information at a node is. The data that is to be distributed over to other peers are always the latest information because there is no replication of data in P2P system like in client/server systems.
c) Scalability
The system is scalable if the load on the system increases at a linear rate with an increase in user. It is a measure of how large the network can grow without hugely affecting other entities or resources. In our the P2P system any number of users can be added without having to add extra hardware or updating of any system to work under large number of users.
d) Extensibility
One of the advantages of p2p over other architectural models is its ability to scale. But another distinguishing property is the ease with we can scale. It should be easy to add user and manage them, allowing easy scaling. Any number of systems can be added to system without resulting in any degradation of the system performance.
e) Fault tolerance
Fault tolerance is the capacity of the system to continue operation even after the failure of any node(s).Pure p2p and hybrid p2p vary greatly in this aspect. One main advantage in our system is that due to failure of one of the peers the entire system will not stop functioning.
f) Security
In some cases anonymity of users is paramount. The system should be capable of resisting malicious intents. The security feature has been provided by the use of provisioning of the password to ensure that only the authorized personnel can share the information.
g) Resistance to legal or political intervention

Naspter has proven that legal or political intervention is a possibility and resistance to both can be either good or bad thing depending on your ideologies. Since the system provides for personalized services the legal issues do not arise, as the peers are sharing the personal information that has been authorized to them.
h) User Interface
The user interface is provided so as to provide an easy way for the user to interact with the system. The system provides a very user friendly way for user to use the system without any hardships or without any learning.
3.3
Tools Required
The specification of the hardware and software is given as follows:
3.3.1 Hardware and Software Specification.

a) Hardware Specification:
Pentium II or above with a speed of at least 500 MHz
64MB RAM Ethernet Card

LAN Connection b) Software Specification: Any operating system that supports the Java Runtime Environment can run it. JRE Supporting JRE TCP/IP Networking Software
3.3.2 Protocols Required

IP The Internet Protocol (IP) is a network-layer (Layer 3) protocol that contains addressing information and some control information that enables packets to be routed. IP is documented in RFC 791 and is the primary network-layer protocol in the Internet protocol suite. IP has two primary responsibilities: providing connectionless, best-effort delivery of datagram through an internetwork; and providing fragmentation and reassembly of datagram to support data links with different maximum-transmission unit (MTU) sizes. ICMP The Internet Control Message Protocol (ICMP) is a helper protocol that supports IP with facility for Error reporting Simple queries
ICMP messages are encapsulated as IP datagram as show in fig 3.1.
Fig 3.1 IP Datagram Packet
ICMP message format is as shown in fig 3.2.
Fig 3.2: ICMP Message Format UDP (User Datagram Protocol) The data that is to be sent is sent over packed into UDP packets. These packets are attached with UDP Header. Each UDP header consists of four parts, the source port, destination port, Length of the message and the checksum. SIP Like HTTP, Session Initiation Protocol (SIP) uses a request-response format. A peer makes a request and the serving peer sends a response. The serving peer can forward a request thus, will act as a client and another client can issue a response to a request, thus will act like a server. SIP protocol makes use of the following messages for the session initiation.
INVIT E
Initiates a session. This method includes information about the calling and called users and the type of media that is to be exchanged.
ACK BYE CANCEL
Sent by the client who sends the INVITE? ACK is sent to confirm that the session is established. Media can then be exchanged. Terminates a session. This method can be sent by either user. Terminates a pending request, such as an outstanding INVITE. After a session is established, a BYE method needs to be used to terminate the session. Queries the capabilities of the server or other devices. It can be used to check media capabilities before issuing an INVITE. Used by a client to login and register its address with a SIP registrar server.
OPTIONS REGISTER
RTP The Real-time Transport Protocol (RTP) provides end to end network transport
functions suitable for applications transmitting real time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality of service for real time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP level translators and mixers. Its architecture is as shown in fig 3.3.
Fig 3.3: RTP Architecture RTCP Protocol The Real Time Transport Control Protocol (RTP control protocol or RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs four functions: RTCP provides feedback on the quality of the data distribution. This is an
integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols. RTCP carries a persistent transport-level identifier for an RTP source called
the canonical name or CNAME. Since the SSRC identifier may change if a conflict is discovered or a program is restarted, receivers require the CNAME to keep track of each participant. Receivers may also require the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video. The first two functions require that all participants send RTCP packets,
therefore the rate must be controlled in order for RTP to scale up to a large number of participants. By having each participant send its control packets to all the others, each can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent. An OPTIONAL function is to convey minimal session control information, for
example participant identification to be displayed in the user interface. This is most likely to be useful in "loosely controlled" sessions where participants enter and leave without membership control or parameter negotiation.
3.3.3 JAVA Tools

The following java related tools are required for the system. JMF
JMF Package is used in order to achieve the transferring of audio and video file types. JDK 1.5 Various inbuilt packages of JDK1.5 have been used in creation of the system. Some of the important ones are:
Javax.swing & java.awt This package is used in order to create the front end along with the java AWT package.
Java.net This package provides the methods for implementing the networking.
3.4 Summary
This Chapter deals with the software requirements and specifications. It had been classified into three parts namely, functional, non-functional and tools required. The functional requirements of the system give the test of the functionalities to be achieved. The statuses of different users are described in the non-functional requirement and the tool consists of hardware and software requirements and protocols. The next chapter deals with design and implementation.
Chapter 4 Design and Implementation

This Chapter discusses the design and implementation mechanism of the proposed system. Modular approach has been used for designing to allow reusability, extensibility and manageability of the system. The system consists of three modules namely, authentication module, user interface module and communication module. in the authentication module, the authentication of the user based on password provided. In user interface module that take care of all the graphical display and the user interactions for the system, and the communication module which is the main underlying module where all the internal working of the system takes place. The implementations of the different modules are carried out using flow charts.
4.1 Design issues and challenges

The information distribution system to be designed and implemented is a system that needs to work over heterogeneous networks. By the term heterogeneous it means it will allow the users to transfer data over different kinds of networks. A few examples would be wired LAN, wireless LAN and the internet. The model proposed here will be functioning on wired as well as wireless networks, which could be further explained to work with the internet. For working with the internet we would have to connect the local network with the internet via a gateway. For wireless networks, their base stations will do the exact work as a gateway does for the wired network. The system needs to perform a cost effective distribution of data over a heterogeneous network. The number of messages exchanged for information sharing should be very less and should consume lesser memory resources. Further the immediate application of such a system is for the personalized services.
Fig 4.1: Project Scenario

The whole project scenario is depicted in the Fig 4.1. The proposed model can work in
any kind of environment like wired or wireless. In wireless network, base stations are used for connecting to end mobile user. Gateways are used in wired network for connecting different LAN to internet. This model provides a number of services such as Instant messaging, Integrated LAN messenger, Contact list., File transfer ,Group chatting ,Image transfer, Audio/Video streaming, Simultaneous login into different accounts.
4.2 System Architecture
Fig 4.2: Architecture of proposed system Authentication module is a simple module whose main purpose is getting the username and the password entered as an input and checking it with the existing password stored in the database for authentication purpose. This is done in order to prevent the unauthorized sharing of data from any of the nodes in a network. The password is used for authenticating here for each user. Authentication module does the following things in sequence in order to authenticate the user. The user interface module is responsible for all the interactions that occur between the system and the user. Selection of various services, normal messaging, specifying the actions that are to be performed are all done here in a very simple manner so that the user does not have to deal with all the difficult technical aspects that go on with in the system. This is the main module and takes care of all the background processes and the internal functionality. Its functionality is simple, it acts as the mediator between the user interfaces on different systems and also the database and the user interface. This module is the one that interacts with the external network.
4.3 Implementation
The three modules are explained below along with the flowcharts indicating the exact working of the module.
4.3.1 Implementation on the server:

public void processInput(InputStream in) { //Read inputs String datas = null; try { while(in.available() > 0) datas += new String(client.readInput()); } catch(IOException e) { return; } datas = datas.trim(); //Decode datas Vector<TagValue> queries = decodeTag(datas); //Process inputs for(TagValue tagValue : queries)
//Using Decoder class (static import)
{ if(client.isAuthentified()) { switch(tagValue.tag) { case REQUEST: if(Request.valueOf(tagValue.value) == Request.DISCONNECTION) { //Disconnection of the client ... } break; case MESSAGE: //Message to transmit to a client ... break; } } else { if(tag.tag == Tag.PSEUDO) { //The client send his pseudo ... } else { //Block it ! Client is not authentified ... } } } }
4.2.2 Implementation on client

public void processInput(InputStream in) { //Read inputs String datas = null; try { while(in.available() > 0) datas += new String(user.readInput()); } catch(IOException e) { return; } datas = datas.trim(); //Decode datas Vector<TagValue> queries = decodeTag(datas); //Using Decoder class (static import)
//Process inputs for(TagValue tagValue : queries) { switch(tagValue.tag) { case REQUEST: if(Request.valueOf(tagValue.value) == Request.PSEUDO) { //Server request authentification ... } else if(Request.valueOf(tagValue.value) == Request.DISCONNECTION) { //Server request disconnection ... } break; case MESSAGE: //A new message ... break; case PSEUDO_LIST: //List of pseudo ... break; case INFO: //Message from the server ... break;
} } }
4.2.3 Implementation on receiving thread

//Listen for datas received listener = new Thread() { public void run() { boolean end = false; while(!end) { try { //Call getProtocol.processInput(...) if some datas are received user.checkInput(); } catch(IOException e) { end = true; } try { Thread.sleep(20); } catch(InterruptedException e){} } user.disconnect(); } }; listener.start();
4.4 Summary
This Chapter describes about design and implementation. The design part covers issues and challenges, project scenario and architecture of the system. Implementation covers three modules namely, authentication, user interface and communication modules. Next Chapter deals with the results that have been obtained for the proposed system.
Chapter 5 Results
5.1 Unit testing
Unit testing focuses verification effort on the smallest unit of software design. Using unit test plan prepared in the design phase of the system development as a guide, important control paths are tested to uncover errors within the module. Testing of the module is done in an isolated environment. This testing was carried out during the coding itself. In this testing step, each Module is tested for satisfactory working and tested results are compared with the expected output. The goal of Unit Testing is to test the internal logic of the modules. The front-end design consists of server and client forms. They were tested for data acceptance. The test plans include inputs, which was tested for various types of exception. If the user keyed in wrong host-name or password, a user-friendly message would be displayed asking the user to input only correct data. All input types were tested and found satisfactory. Table 5.1 summarizes the various tests performed on the system and the outcome of the system. Sr. No. 1 Authentication Username & port no Display client interface for specific client 2 Contact List Login into the system Displays the list of all the users that are currently logged into the system. 3 Instant Messaging Username and the text The specified user receives to be sent to the user. 4 Multiple Chat Select the list of users the text. The selected users receive the text message Scenario Input Output
Table 5.1: Summary of Unit Testing
Brief description of the unit testing of each of the components that the system comprises of will be discussed here.
a)
Login interface
This is a simple one whose main purpose is to get the username and the password entered as an input and checking it with the existing password stored in the database for authentication purpose. This is done in order to prevent the unauthorized sharing of data from any of the nodes in a network. The password is used for authentication here for each user. The following Fig 5.1 shows the login interface.
Fig 5.1: Login Interface

b)
Contact list
Contact list consists of all the name of the users, who has logged on, in the list format. It is like structure. In order to communicate, the name of the user is selected from list and the user is provided with options like chat, group chat and finally to logout after the completion of communication. The following Fig 5.2 refers to contact list.
Fig 5.2: Contact List

c) Instant messaging
Instant messaging (IM) is a form of online communication that allows real-time interaction through personal computers or mobile computing devices. Here when the user clicks on the chat button for communication, a separate window is opened where he/she can exchange messages privately. The sender is represented with blue color and receiver in red. After typing the messages, click on the send button to send the message to other user and we can make use of clear button in order to clear the typed messages. The following Fig 5.3 shows the instant messaging.
Fig 5.3: Instant Messaging
d) Multiple messanging
In multiple messaging the only difference is, a single user can communicate with one or more than one user. Here a separate window is opened for each different user. And user can communicate as same as instant messaging. The following Fig 5.4 shows about multiple messanging
Fig 5.4: Multiple messaging
e)
A user can send the text messages in various formats. For this a number of formats are provided like bold, italics, underline. Various styles are also present. A user can select any particular style and format while chatting for transmission of message. The following Fig 5.5 refers to formatted text transfer.
f) Group messaging
A message is sent from a sender to one or many receivers. Often it is a one-to-many communication but it can also be many-to-many communication, if multiple senders are involved. Peer to Peer systems usually support this type of concepts. The following Fig 5.6 refers to group messaging.
Fig 5.6: Group Messaging
Fig 5.10: Integrated Testing
5.3 Summary
This chapter discussed the results achieved by the implementation of the system. The screenshots of the various scenarios have also been shown. The results has been tabulated and presented. In the next chapter the conclusion and the future scope of the project will be mentioned and various features that can be implemented in future will be mentioned.
Chapter 6
CONCLUSION
6.1 Conclusion
The development of some of the features and applications over peer-to-peer network has helped us to understand and appreciate the potential of peer-to-peer networks. The sharing of text messages, transfer of files, image and audio/video files in P2P networks allow tapping of resources at the edges of the network, besides each peer is a autonomous entity, which can share content without the help of server. Peer-to-Peer is seeing resurgence in the present market and we hope that more systems come forward to take into advantage the possibilities of using this idea and moving away from the traditional client server architecture. We believe that making changes and improvements on the system will be easy. We look forward to complete this venture of ours and give our contribution to the windows. We look forward to people using this software and giving us the feedback on improvements and advancements.
6.2 Future Scope

We have implemented the software with a lot of time constraints. All the same we had a lot of things in our mind that can be implemented over the present structure. We plan to continue to this end and try to improve this software. The login to any of the other publicly available messenger system such as MSN & Yahoo can be further implemented. Some sophisticated features like stealth settings, Saving the Message transfer history, configuring a profile could also be accomplished in future.
References
1) http://www.utd.edu/~chung/SA/2client.pdf 2) http://www.cs.ualberta.ca/~stroulia/660/Fall2006/lectures/P2P.pdf 3) http://www.oreilly.com/catalog/peertopeer/chapter/ch01.html 4) http://www.hpl.hp.com/techreports/2002/HPL-2002-57R1.pdf

5) Java Complete reference by Herbert shield
6) Farley, J. and M. Loukides, Java Distributed Computing (O'Reilly Java), January 1998. 7) Java swings by Hersman. 8) JMF tutorial by www.java2s/jmf/tutorial .html
9) Network of Peers, Peer-to-Peer Models Through the History of the Internet
http://www.oreilly.com/catalog/peertopeer/chapter/ch01.html 10) Peer-to-Peer Computing, by http://www.hpl.hp.com/techreports/2002/HPL-200257R1.pdf 11) Paper from the OReily P2P DC Conference 12) Peer to Peer Architecture :Article by Brian Morrow
13)
Peer-to-Peer Computing, by http://www.hpl.hp.com/techreports/2002/HPL-
2005 7R1.pdf 14) P2P Architecture by Rudiger Schollmeier

15)
Papers from the Proceedings of the First International Conference on Peer to A definition of Peer to Peer Networking for the classification of Peer to Peer
Peer computing.
16)
Architecture application by Rudiger Scollmerier

Im Report

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Im Report

Hochgeladen von

Copyright:

Verfügbare Formate

An efficient implementation of client server chat application

An efficient implementation of client server chat application

1.2 About Project Scenario

1.3 Existing System

1.3.1 Client/Server Architecture

An efficient implementation of client server chat application

Fig 1.1: Client/Server model Example of client/server:

An efficient implementation of client server chat application

Fig 1.2: Architecture of MSN

1.3.2 P2P Architecture:

Dept. of CS & E, JNNCE. 4

An efficient implementation of client server chat application

Fig 1.3: Peer To Peer Network

The client would type in a query.

Dept. of CS & E, JNNCE. 5

An efficient implementation of client server chat application

Fig 1.4: Napster Peer to Peer System

Problem of Existing System

An efficient implementation of client server chat application

Study of client/server and peer to peer computing architectures.

To design and implement cost effective information distribution system over an

Dept. of CS & E, JNNCE. 7

1.5 Scope & Necessity:

Dept. of CS & E, JNNCE. 8

An efficient implementation of client server chat application

Dept. of CS & E, JNNCE. 9

An efficient implementation of client server chat application

Peer to Peer Computing

2.1 Different Architectures present in the Internet

Client Server Model

An efficient implementation of client server chat application

2.3 Peer To Peer Model

formerly relegated to being nothing but clients and

because they have no fixed IP address.

2.3.1 Drift towards P2P architectures

Dept. of CS & E, JNNCE. 12

An efficient implementation of client server chat application

2.3.2 Classification of P2P Architecture

Dept. of CS & E, JNNCE. 13

An efficient implementation of client server chat application

2.3.3 Layered Architecture of P2P

resource is content or computing capability.

Fig 2.1: Layered Architecture

An efficient implementation of client server chat application

2.3.4 Characteristics of P2P

Dept. of CS & E, JNNCE.

An efficient implementation of client server chat application

adaptively has to be distributed over the peers.

and routing-length guarantees

to perform activities that otherwise would be very costly.

An efficient implementation of client server chat application

necessitate computation replication.

out degree) peers Milgram 1967 - small-world phenomenon study

Dept. of CS & E, JNNCE. 17

An efficient implementation of client server chat application

Dynamism: Servants join and drop out opportunistically (buddy lists).

Dept. of CS & E, JNNCE. 18

An efficient implementation of client server chat application

Software Requirement Specification

3.1 Functional Requirements

Dept. of CS & E, JNNCE. 19

An efficient implementation of client server chat application