Submitted in partial fulfillment of the requirements for the award of the degree of Bachelor of Technology By
Arpit Mittal (03711) Niraj Deosthali (03721) Shivkumar Pundir (03754) Under the guidance of
Prof. R Chandrasekharam Mrs. G Geethakumari Mr. K Ramesh
Department of Computer Science and Engineering National Institute of Technology (Deemed University) Warangal (A.P.) – 506004
April 2007
Department of Computer Science and Engineering National Institute of Technology (Deemed University) Warangal (A.P.) – 506004
Certificate This is to certify that, this is a bonafide record of the project work “Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord protocol)” carried out by Arpit Mittal (Roll no: 03711), Niraj Deosthali (Roll no: 03721) and Shivkumar Pundir (Roll no: 03754), of Final Year B.Tech (Computer Science & Engineering), during the academic year 2006 – 07 in partial fulfillment of the requirements for the award of the degree of Bachelor of Technology.
Dr. T. Ramesh Head, Department of CSE National Institute of Technology Warangal (A.P.)
-2-
Acknowledgements First, we would like to express our gratitude to Mrs. G. Geethakumari Madam (Faculty, Dept. of CSE), for her persistent suggestions and encouragements throughout the project work. We would like to thank Prof R. Chandrasekharam (Former Faculty, Dept of CSE) and Mr. K. Ramesh (Asst. Professor, Dept. of CSE), for their consistent guidance which helped to complete our project work effectively. We owe the credit for this work to Mr. S. Ravichandra (Faculty In-charge, B.Tech Project Work, Dept of CSE) as well. Finally, we thank Prof. T. Ramesh, our Head of the department for providing us the opportunity to do this project work with complete support.
Arpit Mittal Niraj Deosthali Shivkumar Pundir (Final Yr B.Tech CSE) NIT Warangal
-3-
Abstract The client-server communication typically involves dedicated centralized system which routes the client request to the designated one. Several problems arise due to this scenario such as lack of scalability and high failures rates of the nodes or systems. Also a problem of communication overhead occurs. Chord protocol attempts to solve these issues that ultimately use a Distributed Hash Table concept. Distributed Hash Tables are a class of decentralized distributed systems that partition ownership of a set of keys among participating nodes, and can efficiently route messages to the unique owner of any given key. They are typically designed to scale up to large numbers of nodes and to handle continual node arrivals and failures. Also, Chord Protocol is a ring based distributed hash table for structured P2P systems. Each node stores at most log (N) entries (or states) in its finger table to point to other peer. Chord maintains its routing information as nodes join and leave the system. Now, in order to implement the same for any application we have developed design patterns. Design pattern is a general repeatable solution to a commonly occurring problem in software design. Object-oriented design patterns typically show relationships and interactions between classes or objects. Precisely, we have taken over a study of Distributed Hash Table and application of relevant protocols (Chord) in which we have designed a system for successful implementation of IP Telephony (A peer-to-peer application) using Chord Protocol and incorporated our own developed patterns within the same.
-4-
Table of Contents 1. Introduction.................................................................................................................- 6 1.1 Problem Specification...........................................................................................- 7 2. Related Work / Background........................................................................................- 7 3. Analysis.....................................................................................................................- 10 3.1 Evaluation and Synthesis ....................................................................................- 10 3.2 Modeling .............................................................................................................- 10 3.2.1 Functional Modeling....................................................................................- 10 3.2.2. Object Modeling .........................................................................................- 12 3.2.3 Dynamic Modeling ......................................................................................- 13 3.3 Specification .......................................................................................................- 19 3.3.1 Title ..............................................................................................................- 19 3.3.2 Introduction..................................................................................................- 19 3.3.3 Overall Description......................................................................................- 20 3.3.4 External Interface Requirements..................................................................- 21 3.3.5 System Features ...........................................................................................- 21 3.3.6 Other Non-functional Requirements............................................................- 21 4. Design .......................................................................................................................- 22 4.1 Data Design.........................................................................................................- 22 4.2 Architecture Design ............................................................................................- 22 4.3 Interface Design ..................................................................................................- 24 4.4 Component Level Design ...................................................................................- 25 4.5 Design Patterns ...................................................................................................- 26 5. Implementation .........................................................................................................- 28 Class node .................................................................................................................- 31 6. Experimental Results ................................................................................................- 33 6.1 Experimental Set-up............................................................................................- 33 6.2 Test Cases ...........................................................................................................- 34 6.3 Test Results & Verification ................................................................................- 34 6.4 Empirical or Formal Validation ..........................................................................- 40 7. Conclusions and Future Work ..................................................................................- 51 8. References.................................................................................................................- 52 9. Appendix...................................................................................................................- 54 9.1 List of diagrams ..................................................................................................- 54 9.2 Definitions / Key words ......................................................................................- 55 -
-5-
1. Introduction In 21st century, communication rules the world around us, may it be anything between living or non-living things. The efficiency is the keyword. The arena of communications has been widely occupied by different type of networks all over. There are mainly two types: Client-Server and Peer-to-Peer. A peer-to-peer system is a distributed system whose component nodes participate in similar roles, and are therefore peers to each other. Peer-to-peer can be viewed as decentralized network architecture. In contrast, the clientserver architecture implies a sharp distinction between the clients which request and consume services, and servers which provide services. Even though the nodes have similar roles with each other, there may still be some structure to the peer-to-peer system, and it usually possesses some degree of selforganization where each node finds its peers and helps maintain the system structure. The main benefits of peer-to-peer system are scalability, fault-tolerance and the lack of resource bottlenecks in servers. Thus the edges that a peer-to-peer system has over the client-server networks can be realized through a different concept used in storing and distribution of keys with the participating nodes in a network. This concept is nothing but DHT (Distributed Hash Table) It avoids the greater memory usage and saves bandwidth. Distributed Hash tables (DHTs) are a class of decentralized distributed systems that provide a lookup service similar to a hash table: (name, value) pairs are stored in the DHT, and any participating node can efficiently retrieve the value associated with a given name. Responsibility for maintaining the mapping from names to values is distributed among the nodes, in such a way that a change in the set of participants causes a minimal amount of disruption. This allows DHTs to scale to extremely large numbers of nodes and to handle continual node arrivals, departures, and failures giving scope to perform with optimal results. There are many protocols associated with DHT. But Chord is the unique one which implements it better because of its numerous features like co-operative mirroring, time shared storage, distributed indices and large scale combinatorial searches all within complexity of order of O (log(N)), where N is the number of nodes in the system. It’s basically a ring based protocol which is completely decentralized and can find the data in logarithmic complexity. Its lookup mechanism is provably robust in the face of frequent node failures and re-joins. Now, before deciding upon the implementation, the way of achieving the same and the details of programming style and approach becomes another important point. Here, the concept of Design patterns was taken over. The role of Design patterns is to describe the design at higher level of abstraction than code i.e. to design a structure and behavior of collaborating objects. For chord protocol, three functionalities are important, i.e., Join, Lookup and Leave which were converted into Patterns developed. Coming to the choice of application, we had a task of building the library using the said patterns and a wrapper for a peer-to-peer network using this library. The existing Internet -6-
telephony client-server architecture based on IETF’s Session Initiation Protocol (SIP) employs a registration server for every domain, which has many problems because of centralized server network mentioned before. So the simulation of IP Telephony using Chord was chosen to be the application of peer-to-peer network implementation.
1.1 Problem Specification To Implement Internet Telephony using Chord Protocol as a Peer-to-peer application that follows Distributed Hash Table concept and uses Design patterns & Library proposed by us. Following are the main aims of the application: 1. Simulate IP Telephony with all basic functionalities such as calling a node, sending a voice across the network between any peer, both ways, disconnecting the call etc. 2. Provide the user with options to create a ring or join the current ring being a node or a system in network, illustrating use of chord protocol. 3. Facilitating controls to make it a robust, efficient and generous application implementing the IP Telephony.
2. Related Work / Background Peer-to-peer systems play a vital role in communication arena [1]. An important goal in peer-to-peer networks is that all clients provide resources, including bandwidth, storage space, and computing power. Thus, as nodes arrive and demand on the system increases, the total capacity of the system also increases. This is not true of client-server architecture with a fixed set of servers, in which adding more clients could mean slower data transfer for all users. The distributed nature of peer-to-peer networks also increases robustness in case of failures by replicating data over multiple peers, by enabling them to find the data without relying on a centralized index server. Peer-to-peer systems and applications have attracted a great deal of attention from computer science research; some prominent research projects include the Chord project, the PAST storage utility, the P-Grid, a self-organized and emerging overlay network and the CoopNet content distribution system We can classify the P2P networks as unstructured or structured. An unstructured P2P network is formed when the overlay links are established arbitrarily. In such an unstructured P2P network, if a peer wants to find a desired piece of data in the network; the query has to be flooded through the network in order to find as many peers as possible that share the data. The main disadvantage with such networks is that the queries may not always be resolved. Flooding also causes a high amount of signaling traffic in the network and hence such networks typically have very poor search efficiency. Most of the popular P2P networks such as Gnutella and FastTrack are unstructured. -7-
On the other hand, Structured P2P networks employ a globally consistent protocol to ensure that any node can efficiently route a search to some peer that has the desired file, even if the file is extremely rare. Such a guarantee necessitates a more structured pattern of overlay links. By far the most common type of structured P2P network is the distributed hash table (DHT), in which a variant of consistent hashing is used to assign ownership of each file to a particular peer, in a way analogous to a traditional hash table's assignment of each key to a particular array slot. The first four DHTs: CAN, Chord [3], Pastry, and Tapestry were introduced about the same time in 2001. Since then this area of research has been quite active. Outside academia, DHT technology has been adopted as a component of BitTorrent and in the Coral Content Distribution Network. A key technique used is that any one node needs to coordinate with only a few other nodes in the system -- most commonly, (log n) of the n participants -- so that only a limited amount of work needs to be done for each change in membership. A fundamental problem that confronts peer-to-peer applications with frequent node arrivals and departures is to locate the node that stores a particular data item efficiently [10]. Chord, a distributed lookup protocol addresses this problem. Chord provides support for just one operation: given a key, it maps the key onto a node. Depending on the application, data location can be easily implemented on top of Chord by associating a key with each data item, and storing the key/data item pair at the node to which the key maps. Chord uses a variant of consistent hashing [4] to assign keys to Chord nodes. Consistent hashing tends to balance load, since each node receives roughly the same number of keys, and involves relatively little movement of keys when nodes join and leave the system. Chord adapts efficiently as nodes do so, and can answer queries even if the system is continuously changing. Results from theoretical analysis, simulations, and experiments show that Chord is scalable, with communication cost and the state maintained by each node scaling logarithmically with the number of Chord nodes. In the steady state, in an N-node system, each node maintains information only about (log n) other nodes, and resolves all lookups via (log n) messages to other nodes. Chord maintains its routing information as nodes come and go; with high probability each such event results in no more than ((log n)^2) messages. Only one piece information per node need be correct in order for Chord to guarantee correct (though slow) routing of queries; Chord has a simple algorithm for maintaining this information in a dynamic environment. Thus, the three features that distinguish Chord from many other peer-to-peer lookup protocols are its simplicity, provable correctness, and provable performance. Chord simplifies the design of peer-to-peer systems and applications based on it by addressing the difficult problems such as Load balance, Decentralization, Scalability, Availability and Flexible Naming. The major applications of chord include, Cooperative Mirroring, Time-shared Storage, Distributed Indexes and Large-Scale Combinatorial Search.
-8-
Another important feature of the project work is the attention to design patterns. Owing to recent emerging trends of the convergence of communications and computing, architectures and infrastructures in the communication domain have become significantly dependent on advances in areas of distributed computing, mobile agents, object-oriented languages and reusable design techniques such as design patterns for improving quality and scalability. The designs of these frameworks has been heavily influenced by existing object paradigms and design patterns, which enables them to successfully handle occurrences of discrete events asynchronously with great ease. Design patterns describe the structure and behavior of a set of collaborating objects. Nowadays, they have become a popular format for describing design at a higher level of abstraction than code. Broadly there are three layers of interaction: functionality, logical and physical. The design patterns allow an incremental development process. A functionality version of the application can be built first and logical and distribution introduced afterwards. The functionality version allows the test and debug of application functionalities ignoring distribution issues. The logical layer introduces distributed communication ignoring the mechanisms and preserving the object-oriented communication paradigm. At the logical layer, testing and debugging is done in a nondistributed environment. Finally, at the physical layer the application is enriched with distributed communication mechanisms. Here, data gathered from simulations at the logical layer may help to decide on the final implementation. As specified before, the choice of implementation was IP Telephony which is nothing but a routing of voice conversations over the internet or any IP based network. Internet telephony, also known as voice-over-IP or IP telephony (IPtel) is the real-time delivery of voice (and possibly other multimedia data types) between two or more parties, across networks using the Internet protocols, and the exchange of information required to control this delivery. Internet telephony offers the opportunity to design a global multimedia communications system that may eventually replace the existing telephony infrastructure, without being encumbered by the legacy of a century-old technology. [9] [14] Currently, the majority of IP Telephony system cost is in maintenance and configuration, typically by a dedicated system administrator of the domain. It also means that quickly setting up the system in a small network (e.g., for emergency communications or at a conference) is not easy. On the other hand, peer-to-peer (P2P) systems are inherently scalable and reliable because of the lack of a single point of failure. P2P systems are robust against global, catastrophic failure, although single nodes may fail. The solution to the same has been proposed up by SIP [6] (Session initiation protocol). The SIP is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. Thus, finally we have proposed a P2P Internet telephony architecture using Chord aiming to achieve a fully distributed model to increase robustness, and the ability to deploy it without modifying controlled infrastructure.
-9-
3. Analysis 3.1 Evaluation and Synthesis The analysis of the project work considering the entire criterion shows that the work involves both research and implementation. The study of DHT and Chord protocol in detail along with their relevant concepts forms the basis of the research required. The application implemented has got the merits of both theoretical study of Design patterns followed by their development and the proposal & built up of library and wrapper for the application. Indeed the merits of use of Peer-to-peer networks, Distributed Hash Table, Chord protocol, its specific use in implementing IP Telephony and design patterns and use of Java are depicted by the application to the best possible extent. The original work in the same i.e. synthesis is nothing but design patterns developed, library and wrapper proposal and built up work and idea of IP Telephony using Chord that handles the related modifications in order to implement the same.
3.2 Modeling 3.2.1 Functional Modeling Use Case Diagrams 1. Use Case Diagram for Connecting to / Creating the ring
Fig 1
- 10 -
2. Use Case Diagram for making a call
Fig 2
3. Use Case Diagram for Disconnecting from the ring
Fig 3
- 11 -
3.2.2. Object Modeling Class Diagram
Fig 4: Class Diagram for VOIX
- 12 -
3.2.3 Dynamic Modeling 3.2.3.1 Sequence Diagrams 1. Sequence Diagram for joining the network
Fig 5
- 13 -
2. Sequence Diagram for leaving the network
Fig 6
- 14 -
3. Sequence Diagram for making the call
Fig 7 3.2.3.2 Flow Diagrams 1. Flow Diagram for joining the ring Steps: x Call the join method. x If ring doesn’t exists, initialize the finger table and the current node will become the reference node, then end. x Otherwise, contact the reference node. x Then, initialize the finger table. x Update the finger tables of the other nodes in the ring. x Join method returns.
- 15 -
Fig 8 2. Flow Diagram for leaving the ring Steps: x Call the leave method. x Update the finger table entries of the other nodes in the network. x Move the key values. x Leave the network.
Fig 9
- 16 -
3. Flow Diagram for Lookup Service: Steps: x x x x
The lookup method is called (in our case, find_successor method) The key value is passed The node will find the k nodes that are closest to key Returns the k nodes
Fig 10 4. Flow Diagram for making the call Steps: x x x x x x
Join the ring Make a request for call Check if the remote user has accepted it. If yes, then talk Then terminate the call Otherwise, Exit
- 17 -
Fig 11 3.2.3.3 State Diagram
Fig 12: State Diagram for VOIX
- 18 -
3.3 Specification 3.3.1 Title Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord Protocol)
3.3.2 Introduction 3.3.2.1 Purpose This Project has been developed for the purpose of implementing the Internet Telephony using the Chord Protocol which ultimately uses a Distributed Hash Table Concept, which is the main focus of the project work. The Design patterns are also developed for the same. The project aims at demonstrating the use of peer-to-peer network for the communication in an efficient and robust way through the application constructed in. It facilitates the user to successfully experience an Internet Telephony system. 3.3.2.2 Document Conventions None. 3.3.2.3 Intended Audience and Reading Suggestions This document is intended for the developers of the software to guide the software design. It gives an overview of the related concepts, their need and sequence of their entry into the project work, the design, implementation issues and software requirements and specifications along with constraints and guidelines for demonstration. 3.3.2.4 Project Scope The scope of this project work lies in that it deals with an idea of DHT, and its detailed study and a practical realization of the same using mentioned paradigms. The application given as a demonstration, deals with an IP Telephony system that covers all basic features of a typical software of that kind following assumed constraints (Use of Chord Protocol Design patterns, Proposal of Library and building a wrapper etc.) Benefits 1. Peer-to-Peer network: It avoids scalability, communication overhead and high failure rate problems 2. Distributed Hash Table: It distributes the ownership of keys within participating nodes, reducing burden and improving performance 3. Chord Protocol: It carries out the lookup in O(log(N)) complexity and maintains the information of join and leave of nodes within the system dynamically.
- 19 -
4. Design Patterns: They describe a design in such a way that provides higher level of abstraction than code. 5. IP Telephony using Chord: Avoids greater memory and bandwidth usage and is the choice of application is illustrative enough to demonstrate it.
3.3.3 Overall Description 3.3.3.1 Product / Project Perspective The project implements the study of DHT with a suitable choice of application and related requirements. 3.3.3.2 Product / Project Function The project aims at showing up the successful run of Internet telephony with all features working optimally. (Say creating a ring of N nodes, establishing calls between any of them, dynamic leave and join of nodes properly updated etc.) 3.3.3.3 User Classes and Characteristics Any user can become a node of the ring / peer of the network (all same privileges) 3.3.3.4 Operating Environment Windows 3.3.3.5 Design and Implementation Constraints 1. The Circle or Ring of nodes that will be formed, should not have more than 2m nodes, where ‘m’ is the length of identifier so that a ring can have IDs from 0 to 2m 1. 2. A ring has to be created before any new node joins / tries to connect 3. System currently working over a LAN (Local Area Network) with subnet 255.255.255.0 3.3.3.6 Assumptions and Dependencies 1. The application is assumed to be installed and instantiated on all the aspiring nodes / peers to the ring or network. 2. Both the versions of Java should be same to be a technical requirement. 3. The complete IP address should be specified while connecting to the reference node in an already created ring.
- 20 -
3.3.4 External Interface Requirements 3.3.4.1 User Interfaces The software application has windowed user interface that follows the given criterions: 1. The user is able to create a ring, connect to an already created ring through a reference node, call a particular node, disconnect the conversation and re-call, and or leave (exit) the application and re-join the same performing any of the said tasks again. 2. The interface is presentable, easy to comprehend and looks elegant. 3. The user comes to know about the time for which the call is established 4. The ring tone while calling / dialing the same is heard by the user giving a reciprocation of its action performed. 3.3.4.2 Hardware Interfaces Not applicable 3.3.4.3 Software Interfaces Java Runtime Environment 1.6.0 and above Java Media Framework 2.1.1e and above
3.3.5 System Features 3.3.5.1 Front End Front end interacts well with the user providing Menu bar with all the necessary actions enlisted within. The user can provide with IP address of the reference node, click the buttons provided wherever for activating the event of call, connect, disconnect, exit etc. And observe the timer that gives the status of call during the same, whereas all the error actions are properly handled with pop-ups directing user about necessary further course of action. No Definite Stimulus / Response Sequence provided the assumptions and constraints are not violated. 3.3.5.2 Back End Not applicable
3.3.6 Other Non-functional Requirements Performance Requirements If the limits of constraints and assumptions are followed, and system requirement matches the software performs optimally within its scope and limitations. - 21 -
4. Design 4.1 Data Design In this section we describe how the data is maintained in the system. Chord Node: Various attributes are described below: i. Id : The id of the node ii. Port_recv: The port where reception is made iii. Port_trans: The port through which the transmission is made iv. IP: The IP Address of the local node v. PrececessorIP: The IP Address of the predecessor node vi. Fingertable[] ft: The finger table of the local node Finger Table: Finger table entry includes both the Chord identifier and the IP Address of the relevant node. It will maintain the information about the successor node ids and their IP Addresses. It contains attributes start, interval, successor node IP who is responsible for the interval, successor node ID who is responsible for the interval and successor node IP. Various attributes are listed below: i. Start : The starting node for the given index ii. Interval_start: The starting node of the interval iii. Interval_end: The ending node of the interval iv. Successor_ip: The IP Address of the successor node
4.2 Architecture Design The system is designed based on the overlay routing, using the Chord Protocol. An overlay network is a network at the application layer where each node corresponds to an application program running on any computer connected to the Internet, and each overlay link (a virtual link) is itself an end-to-end path in the underlying IP network. In order to scale and be robust, we build what is called a structured overlay network. It is called a structured overlay since instead of flooding we would route the messages intelligently such that both publish and search messages would precisely end up at a node which is responsible for that piece of information within a bounded number of hops. Each participating node runs the same application. The Chord Protocol will form layered kind of structure over the underlying socket layer in such a way that the whole system will get distributed. The user application will interact directly to the DHT Chord layer which further passes on the message to the socket layer for various networking communications. Thus, the physical address of the remote machine is resolved dynamically. The user thus will use the application constructed by us to resolve the IP Address of the remote systems and will make a call to it, which will ultimately lead to the voice communication.
- 22 -
Fig 13 Generic Architecture using Chord Protocol
Fig 14 Existing Architecture of IP Telephony Application
- 23 -
Fig 15 Architecture of our system (Modified Architecture of IP Telephony after incorporating Chord Protocol)
4.3 Interface Design The interface for VOIX has been developed using Java Swing components. It consists of functionalities for the user to connect or create a chord ring. It also makes the use capable of making the call to any remote system existing in the chord network. It includes the functionality to disconnect from the ring as well. The functional interface visible to the user is as follows: Node Interface: (The interface for the library) File: node.java public interface node{ public node(); public node getn (String ip); public void updaten (String ip, node n); public node find_successor (int id); public node find_predecessor (int id); public void join (node n); public void init_finger_table (node n1); public void update_others (); public void leave (node n); public void update_others_del(); }
- 24 -
The detail about the methods is given in the implementation section. Reference node Interface: ( The main interface of the application) File: refnodeIntf.java public interface refnodeIntf extends Remote { void updatenode(node n) throws RemoteException; void invoke_computer(String IPAddrStr) throws RemoteException; node getnode() throws RemoteException; } Here, updatenode method updates the local node with the attribute values of node ‘n’. invoke_computer method invokes the computer at the specified IP Address ( provided by IPAddrStr). Getnode method will return the node for the local system.
4.4 Component Level Design
Fig 16 Component Level Diagram
Connector: This module will establish connection with the ring. User can directly interact with this module and can get the required operation done. This module updates the finger tables of the system. Creator: This module will create a new ring. This is also exposed directly to the user. This will update the finger table entries of the local node and will make the node capable to receive any remote requests. Finger Table: It contains the distributed hash table. It gets regularly updated to maintain stability of the system. It enables the system to resolve the physical address once provided with the id.
- 25 -
Voice Communication Module: This module is responsible for all the voice communication done. It will take care of all the transmission and reception of data and also controls the various events occurring. When a transmission has to be performed it will create a ‘data source’ which will take input directly from the voice ‘capture device’ (microphone). Then it will create the ‘data sink’ using this data source. This data sink will in turn render the media to the destination specified. At the destination, the data will be received, will be buffered locally and then it will be given to a ‘processor’ which will process the data and will send it to the appropriate output device. Whole process is managed by a ‘manager’. Same process is performed when the remote computer sends the data to the local system. When user wishes to end the call, the module will terminate the transmission of data which will exhaust the buffer at the remote end and will stop the communication. Disconnector: This module takes care of successful departure of a node from the network. It also stabilizes the network by updating the finger table entries of all the nodes in the system.
4.5 Design Patterns This application is build using the design patterns developed by us. They are as follows: Connector pattern: (Facilitates to make connections) connect(id) //takes the id of the node that has to be searched node n'=n.search(id); n.connectto(n',connectionstring); // in this function we will use the port no and ip to // connect search(id) for i = m downto 1 if(id in finger[i].interval) return finger[i].successor.search(id); return n; Join pattern: This framework facilitates when a new node joins in the network: #define successor finger[1].node // node n joins the network; // n' is an arbitrary node in the network n.join(n') if (n') init_finger_table(n' ); update_others(); // move keys in (predecessor, n] from successor else // n is the only node in the network
- 26 -
for i = 1 to m finger[i].node = n; predecessor = n; // initialize finger table of local node; // n' is an arbitrary node already in the network n.init _finger table(n') finger[1].node = n'.find_successor(finger[1].start); predecessor = successor.predecessor; successor.predecessor = n; for i = 1 to m - 1 if (finger[i+ 1].start in [n, finger[i].node)) finger[i+ 1].node = finger[i].node; else finger[i+ 1].node =n'.find_successor(finger[i+ 1].start); // update all nodes whose finger // tables should refer to n n.update_others() for i = 1 to m // find last node p whose ith finger might be n p = find_predecessor(n- 2^i-1); p.update_finger_table(n, i); // if s is ith finger of n, update n’s finger table with s n.update_finger table(s, i) if (s in [n, finger[i].node)) finger[i].node = s; p = predecessor; // get first node preceding n p.update_finger_table(s, i); // ask node n to find id’s successor n.find successor(id) n' = find_predecessor(id); return n'.successor; // ask node n to find id’s predecessor n.find predecessor(id) n' = n; while (id = in (n', n'.successor]) n' = n'.closest_preceding finger(id); return n';
// return closest finger preceding id n.closest_preceding finger(id)
- 27 -
for i = m downto 1 if (finger[i].node in (n, id)) return finger[i].node; return n; Departure pattern: // n is the node which is leaving // n' is any arbitrary node n.leave(n') if(n') successor.predecessor = predecessor; predecessor.successor = sucessor; update_others(); else //n was the last node in the network n.deletering(); // whole ring will be deleted // update all nodes whose finger // tables should refer to n n.update_others() for i = 1 to m // find last node p whose ith finger might be n p = find_predecessor(n- 2^i-1); p.update_finger_table(n.successor, i); // if s is ith finger of n, update n’s finger table with s n.update_finger table(s, i) if (s in (n, finger[i].node]) finger[i].node = s; p = predecessor; // get first node preceding n p.update_finger_table(s, i);
5. Implementation The design of this project has been implemented using java as the primary programming language. The application is designed making use of java swing and Abstract Window Toolkit (AWT). The default run target is the refnodeImpl.java which includes the main function within it. Moreover, it also extends the UnicastRemoteObject, in order to enable remote method invocations, and hence implements 'refnodeIntf' Interface. It generates an instance of refnodeImpl class, which in turn creates an object of FrontEnd class which ultimately creates the frame for the windowed application. This nested frame generation is done to fascillitate the methods of the refnodeImpl class to be invoked remotely. Java Remote Method Invocation (Java RMI) enables the programmer to create distributed Java technology-based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. RMI uses object
- 28 -
serialization to marshal and unmarshal parameters and does not truncate types, supporting true object-oriented polymorphism. The User Interface (UI) manager available in java is used to set the look and feel of the application similar to system applications. The frame is created by extending the class JFrame in swing. We have made use of border layout and flow layout to create the window of out application. We have also incorporated JMenuBar in the application which provides the menu bar. Also, the nested tabbed panes also appear in the main frame according to the various conditions. We have also added the System Tray feature to our application by using java.awt.SystemTray functionalities. The values are entered in JTextArea and JButtons are used to invoke various methods. The chord library is implemented in the file node.java and fingertable.java. Thus, whenever it is needed to join the ring / create the ring an instance of node class is created to do the job. Also, fingertable class provides the basic data structure to the fingertable. The various functions of node class are listed later. Node class is implemented as serializable. This is done to enable node can be passed as a parameter to a remote method. This is done by implementing serializable interface. Java provides automatic serialization which requires only that the object be marked by implementing the java.io.Serializable interface. Implementing the interface marks the class as "okay to serialize," and Java then handles serialization internally. There are no serialization methods defined on the Serializable interface, but a serializable class can optionally define methods with certain special names and signatures that if defined, will be called as part of the serialization/deserialization process. Also, voice communication is done by streaming using objects of AVTransmit2 and AVReceive2 classes implemented using the java media framework (JMF). The Java Media Framework API (JMF) enables audio, video and other time-based media to be added to applications and applets built on Java technology. This optional package, which can capture, playback, stream, and transcode multiple media formats, extends the Java 2 Platform, Standard Edition (J2SE) for multimedia developers by providing a powerful toolkit to develop scalable, cross-platform technology. The AVTransmit2 class attempts to transmit each of the tracks within the given input media. To do that, an RTP session is created for each media track. For that purpose, the RTP Session API instead of the DataSink API is used for flexibility. The default (first available) RTP format is set for each track. Real-time scaling is applied when necessary. The AVTransmit2 class takes three parameters in the constructor - the source locator, the destination IP address and a base destination port number for all the media tracks. AVReceive2 uses the RTPManager API, introduced in JMF 2.1.1, to receive RTP transmissions. AVReceive2 performs the following tasks: * Open one RTP session per session address given. * Listen for the NewReceiveStreamEvent from the ReceiveStreamListener. * Create a JMF Player for each stream received for playback.
- 29 -
The project is brodely divided into four modules: 1. Creator Module 2. Connector Module 3. Voice Communication Module (VCM) 4. Disconnector Module These modules are coupled together closely to form the entire VOIX system. 1. Creator Module: This module facilitates us to create a new ring with the system as the reference node. This is done by calling the join method which will initialize the finger table entries and make the node ready to receive remote connection requests. 2. Connector Module: This module enables a node to get connected to an existing chord ring. To do so the IP address of the reference node has to be specified. Using it the reference node is retrieved and "join" function (implemented in node.java) is called. This function performs the necessary operations to establish the connection such as first of all it will initialize the finger table of the caller node then successively update the finger tables of all the nodes in the ring. This is done by invoking the methods remotely on each node. 3. Voice Communication Module (VCM): To start any voice communication the destination node's id has to be specified. Using it, the physical address of the node in the ring is resolved. Then a duplex connection is established between both the systems. In order to transmit the data an object of AVTransmit2 class is created. The AVTransmit2 class takes three parameters in the constructor - the source locator, the destination IP address and a base destination port number for all the media tracks.
The source locator can be * A file name such as "file:/C:/media/speech.mov", * An http locator such as "http://mediacentral.com/speech.avi", * Or a capture data source such as "javasound://8000" The IP address should be the IP address of the computer that should receive your transmission. If you want all the computers on your subnet to receive the transmission, then use 255 as the last number in your IP address. The base Port number can be any port number that is not in use by any other service on your computer. For example, we are using "2222". This number has to be an even number. The first media track will be transmitted from the base port number. The next track will go to base port number plus 2 and so on.
- 30 -
Related Classes * javax.media.Manager * javax.media.Processor * javax.media.protocol.DataSource * javax.media.rtp.SessionManager Similarly, in order to receive the data, AVReceive2 is instantiated. Using it we will be able to receive the stream from the destination node. For this we have to specify the address of remote node along with the port where reception is done. Here we are using port as “4444”. The port should be the same as what's being used by the transmitter. Related Classes * javax.media.Manager * javax.media.Processor * javax.media.protocol.DataSource * javax.media.rtp.SessionManager 4. Disconnector Module: This module performs the job of disconnecting a node from the given chord network. In order to do so it calls the “leave” method (implemented in node.java). This function will in turn call update_others_del function to update the finger tables of other nodes in the ring and subsequently delete the existing node from the chord network. Thus, the whole ring will be stabilized after this operation is performed. Further, in order to facilitate the chord protocol operations we have developed a node.class file which provides the various methods required for the implementation of chord protocol.
Class node
Field Summary Static int Id
The id of the node static int port_recv
The port where reception is done. Static int port_trans
The port where transmission is done. Static string ip
The ip address of the local node. Static string Predecessor_ip
- 31 -
The ip address of the predecessor Fingertable[] ft
The finger table entries
Constructor Summary node()
A no-argument constructor so that this class can be instantiated by calling Class.newInstance.
Method Summary void Getn(String ip)
This method is used to retrieve the node at the given ip address. void Updaten(String ip_add, node n)
Updates the node at the ip address == ip_add with the fields of node n String Find_successor(int i)
Returns the ip address of the node with id == i void Join(node n)
Facilitates a node to join in the ring. If ring already exists then n will be the reference node, otherwise pass null. void Init_finger_table(node n)
It will initialize the finger table for any node. ‘n’ is the reference node. void Update_others()
This will update the finger table of the nodes in the ring after a join has been made. void Update_finger_table(node n, int i)
Update the finger table of the node n at the index i void Leave(node n)
Enables a node to leave the ring. ‘n’ is the reference node. void
Update_others_del()
Updates the finger table of the nodes in the ring after a leave operation has been performed void Update_finger_table_del(node n, int i)
Update the finger table of node n at the index i
- 32 -
This class makes use of the data structures provided by fingertable.class which are as follows:
Field Summary int start
starting node for the given index int interval_start
the starting node of the interval int
interval_end
the ending node of the interval String successor_ip
the IP address of the successor node
Constructor Summary Fingertable()
A no-argument constructor so that this class can be instantiated by calling Class.newInstance.
6. Experimental Results 6.1 Experimental Set-up Configuration The system is configured using the following steps in order to start using the application for the same. 1. Install the Java Development Kit (JDK 1.6.0 or above) 2. Install the Java Runtime Environment (JRE 1.6.0 or above) (usually comes with each other) 3. Install the Java Media Framework 2.1.1e 4. Check for working of RMI registry through command prompt. 5. Set the path of environment variables to the bin folder of JDK, as a convenient practice. 6. Repeat the steps 1 to 5 on all the systems to be configured for the application. Compilation Sequence of Source Code Compile AVTransmit.java , AVReceive.java, MsgBox.java, Fingertable.java, Node.java. Then Compile FrontEnd.java, refnodeImpl.java and refnodeIntf.java simultaneously. Then create client and server stubs by using command “rmic” with refnodeImpl.
- 33 -
Start the RMI registry with command “start rmiregistry” which is required for RMI operations. Subsequently invoke the program with command “java refndeImpl”
6.2 Test Cases 1. To check whether a new node can create a ring (when the application is not yet started) 2. To check whether a node can connect to an already created ring 3. To check whether a call between two nodes already connected is established 4. To check whether a call already established can be ended. 5. To check whether an already connected node can disconnect from a ring 6. To Exit the application 7. To check the working of Help file
6.3 Test Results & Verification 1. To check whether a new node can create a ring (when the application is not yet started)
PROJECT : MODULE :
Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord Protocol) Creator
FUNCTIONAL SPECIFICATION:
Create the ring
TEST DATE
TEST OBJECTIVE:PREPAIRED BY TEST CASE NO:Test Data Step No
Apr 8th, 2007 To check whether a new node can create a ring (when the application is not yet started) Arpit / Niraj / Shivkumar 1 Nil Steps
1
2
Start command prompt in Windows
Reach the folder containing application
Time Taken
Data May start using Run console or a short cut provided Change the directory to the one containing the application
- 34 -
15 min.
Expected Results Should start with a command prompt for windows.
Should switch over to the folder containing the application
Actual Results Command Prompt appears on the screen The current directory is set to the folder containing application
Remarks
Successful
Successful
3
4
Type "start rmiregistry" and press ENTER Start RMI registry
Execute the Interface file of the application
Type "java RefNodeImpl" and press ENTER Go to File menu, click or mouse over on 'Join' and then choose 'Create Ring'
5
Create a New Ring Press OK
6
Finish
Should display another command prompt window invoked by the registry Should start the application with VOIX 1.0 user interface visible on the screen
Another window of command prompt opens up
Should display all the menu bar controls respectively and ask for a Ref ID Should display a message that a ring with the current Ref ID of the node is created
VOIX 1.0 application starts up The user interface asks for a Ref ID with two buttons OK and Cancel to press for A pop-up saying Operation is accomplished comes out
Final Remark
Successful
Successful
Successful
Successful
Successful
2. To check whether a node can connect to an already created ring
PROJECT : MODULE :
Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord Protocol) Connector
FUNCTIONAL SPECIFICATION:
Connect to a ring
TEST DATE
TEST OBJECTIVE:PREPAIRED BY TEST CASE NO:Test Data Step No
Apr 8th, 2007 To check whether a node can connect to an already created ring (when the application is not yet started) Arpit / Niraj / Shivkumar 2 Connect to 192.168.10.1 Steps
1
Connect to a ring
Time Taken
15 min.
Data
Expected Results
Actual Results
Remarks
Go to File menu, click or mouse over on 'Join' and then
Should display all the menu bar controls and respectively and ask for IP of Reference node
The interface asks for an IP of Ref node of the ring created
Successful
- 35 -
choose 'Connect'
2
Returns to the main screen
The IP address given is 192.168.10.1
Should display a message that the node has been connected
A pop-up saying Operation accomplished comes out
Final Remark
Successful
Successful
3. To check whether a call between two nodes already connected is established
MODULE :
Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord Protocol) Voice Communication Module
FUNCTIONAL SPECIFICATION:
Call the node
PROJECT :
TEST DATE
TEST OBJECTIVE:PREPAIRED BY TEST CASE NO:-
Test Data Step No
Apr 8th, 2007 To check whether a call between two nodes already connected is established Arpit / Niraj / Shivkumar 3 ID of the recepient node (58) Steps
1
2
Call another node
Dialling the recepient node
Time Taken
Data Go to File menu, click or mouse over on 'Call' / Right click on the system tray icon and click on Call Type the ID of the recepient node (already known, or pre-decided for the sake of
- 36 -
15 min.
Expected Results
Actual Results
Remarks
Should display all the menu bar controls respectively and ask for an ID of recepient code to be dialled
The interface asks for an ID of recepient node
Successful
Should display that a call is being attempted with a tone of dialling sound coming from the system
A call is dialed to node with ID 58
Successful
convinience) - 58 I this case and press OK
3
4 5
Receiving a call (on the receiving node)
Accept the call from Caller node with ID 86 (The called node ID) Press the Accept button
Accepting the call START CONVERSATION…
Should display that a call is coming from Caller with IP 192.168.10.86 with two options of Accept or Cancel it A ringing tone will sound showing that an incoming call is waiting. The call should be accepted and a timer showing the duration of the call should be visible
A call coming from the node 192.168.10.86 is showed up on the interface A ringing tone sound came from the system and a timer showing the duration of call appears the on the screen
Final Remark
Successful
Successful
Successful
4. To check whether a call already established can be ended.
MODULE :
Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord Protocol) Voice Communication Module
FUNCTIONAL SPECIFICATION:
End the call
PROJECT :
TEST DATE
TEST OBJECTIVE:PREPAIRED BY TEST CASE NO:Test Data Step No
Apr 8th, 2007 To check whether a call already established can be ended Arpit / Niraj / Shivkumar 4 Nil Steps
Time Taken
Data Press End Call
1
Ending the call (From the Caller node) - 86
- 37 -
15 min.
Expected Results
Actual Results
Remarks
Should end the call and should display the normal screen of the application.
The call is ended and the communications stops
Successful
Nil
2
(On the recepient node) - 58
Should stop the call timer and show that the call is ended (A message pops up)
The call gets ended and a message saying that the call has been ended by the source pops out
Final Remark
Successful
Successful
5. To check whether an already connected node can disconnect from a ring
PROJECT : MODULE :
Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord Protocol) Disconnector
FUNCTIONAL SPECIFICATION:
Disconnect from the ring
TEST DATE
Apr 8th, 2007 To check whether an already connected node can disconnect from ring Arpit / Niraj / Shivkumar 5 Nil
TEST OBJECTIVE:PREPAIRED BY TEST CASE NO:Test Data Step No
Steps
1
Disconnect from the ring
Time Taken
Data Go to File menu, click or mouse over on 'Disconnect'
15 min.
Expected Results
Should complete the disconnection and return to the main screen
Actual Results Asks user whether he is sure to leave the ring Disconnects the node and returns to the main screen
Final Remark
Successful
Should disconnect the already connected node from the ring with a message asking approval from user
Press OK
2
User approves disconnection
- 38 -
Remarks
Successful
Successful
6. To Exit the application
PROJECT : MODULE :
Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord Protocol) Not applicable
FUNCTIONAL SPECIFICATION:
Exit the application
TEST DATE
Apr 8th, 2007 To Exit the application when the node is not active Arpit / Niraj / Shivkumar 6 Nil
TEST OBJECTIVE:PREPAIRED BY TEST CASE NO:Test Data Step No
Steps
1
2
Exit the application
User approves Exit
Time Taken
Data Go to File menu, click or mouse over on 'Exit' / Right click on the system tray icon and click on Exit Press OK on the warning message
15 min.
Expected Results
Actual Results
Remarks
Should exit the application with a warning message whether the user really wants to quit
Asks user whether the user wants to quit the application
Successful
Should close the application
The application closes
Successful
Final Remark
Successful
7. To check the working of Help file
PROJECT : MODULE :
Study and Implementation of Distributed Hash Table (VOIX: An IP Telephony using Chord Protocol) Not applicable
FUNCTIONAL SPECIFICATION: TEST DATE
Use help Apr 8th, 2007
Time
- 39 -
15 min.
Taken
TEST OBJECTIVE:PREPAIRED BY TEST CASE NO:Test Data Step No
To check the working of Help Arpit / Niraj / Shivkumar 7 Nil Steps
1
Starting the Help
Data
Expected Results
Actual Results
Go to Help menu / Right click on the system tray icon and click on Help
Should pop-up the help file
The help file pops up
Final Remark
Successful
Remarks
Successful
6.4 Empirical or Formal Validation The following screenshots pertain to a testing experiment within a network of 3 nodes. Here a call has been attempted successfully from node 86 to 58. While the Ref. node IP is 192.168.10.1 Test Case 1 The screenshot 1 shows the main screen of application. After following the steps of configuration and start up of VOIX 1.0, this window appears on the screen. Screenshot 2 shows the menu bar controls to connect a ring or form a network. Screenshot 3 shows the next step in creating a ring i.e. it asks for Ref IP which is not required since it’s the first node of the ring – Ref node. Screenshot 4 shows that the operation of creating a ring has been accomplished i.e. a ring can now be formed using this node as a reference.
- 40 -
Screenshot 1: Starting the application (Main Screen)
Screenshot 2: Creating the ring (Step 1)
- 41 -
Screenshot 3: Creating the ring (Step 2)
Screenshot 4: Creating the ring (Step 4)
- 42 -
Test Case 2 While connecting to a ring through a ref. node, screenshot 5 shows the menu bar controls for the same. Screenshot 6 shows that the application asks for Reference node IP, in order to connect to the ring. Here as specified before, its 192.168.0.1 Screenshot 7 shows that the current node has been connected to the ring. i.e. operation has been accomplished.
Screenshot 5: Connecting to a ring (Step 1)
- 43 -
Screenshot 6: Connecting to a ring (Step 2)
Screenshot 7: Connecting to a ring (Step 3)
- 44 -
Test Case 3 There are several steps involved in a call from one node to the other. Before the call is attempted, both the systems other than Ref. node need to be connected to it, by the procedure mentioned in test case 2. Screenshot 8 shows the menu bar controls for calling a node. Here, the ID of receiver node, say 58 in this case, is entered. (Screenshot 9) After call is being attempted the following screen of application appears. (Screenshot 10) On the receiver side, the appearance of an incoming call looks like this. (Screenshot 11) Screenshot 12 shows the details while a conversation is going on between the two nodes after the call has been accepted by the receiver. A small window showing the timer for conversation appears along with.
Screenshot 8: Calling a node (Step 1)
- 45 -
Screenshot 9: Calling a node (Step 2)
Screenshot 10: Calling a node (Step 3)
- 46 -
Screenshot 11: Calling a node (Receiver side) (Step 1)
Screenshot 12: Calling a node (Receiver side) (Step 2)
- 47 -
Test Case 4
Screenshot 13: Ending a call (Caller side)
Screenshot 14: Ending a call (Receiver side)
- 48 -
This case deals with ending a call. Screenshot 13 shows that an end call request is given by the caller node. The call ends after a small interval of time. Coming to the receiver node, the pop-up as shown in Screenshot 14 appears saying that the call has been ended by the source. Test Case 5 This case deals with disconnection of a node from the ring. Screenshot 15 shows the menu bar controls for the same. A warning or alert message pops up to verify whether the user really wants to disconnect from the ring as it will have to re-connect before trying to call any other node. (Screenshot 16) On user’s approval that he is sure to disconnect, the operation accomplished window pops up from the application. (Screenshot 17)
Screenshot 15: Disconnecting from a ring (Step 1)
- 49 -
Screenshot 16: Disconnecting from a ring (Step 2)
Screenshot 16: Disconnecting from a ring (Step 3)
- 50 -
Test Case 6 This case deals with quitting the application. Screenshot 17 shows the menu bar controls regarding the same. The application closes down after the same.
Screenshot 17: Exiting the application
7. Conclusions and Future Work We have presented a study and implementation of DHT (Distributed Hash Table) concept with the previously mentioned constraints, with an illustration of an IP Telephony application that includes original efforts on library and design patterns. The study of DHT had been the main research work taken up in the initial stage of the project work, and the details of working of Chord protocol being another point of concentration. After enough exposure, the need of Peer-to-peer networks in communication was converted into an application demonstration of Internet Telephony. The proof of improvement in features both theoretically and practically can be cited by use of Chord for IP telephony with modules proposed using Design patterns. The library and wrapper proposed upon which the application is built is another crucial part of project work. The practical realization of Internet Telephony with all the basic features for its optimal working has been presented. All the concepts of distribution of keys, reducing the overload of communication and memory usage, higher abstraction of code, facilitating
- 51 -
frequent join and leave system for nodes are some of the prime merits of the project work. The user interface is equally generous in order to meet the needs of typical software that implements IP Telephony. All the relevant documentation and error handling is also taken care of. Future Work Security of the current application from P2P point of view is not a big concern at this level being very less data saved comparatively but the concern of Byzantine problem of arbitrary behavior of a node can be dealt with better fault tolerance and defense. Also anonymous P2P or Friend-to-Friend networks offer hiding of IP addresses effectively leading to secure sharing of resources if introduced any. The research has been going on over chord protocol and use of modified techniques and some kind of hybrid system may be implemented that takes the advantages of many different structured P2P algorithms to further reduce the latency and maintenance cost [7] As far as the application is concerned, the Library developed is good enough to run the demonstrated application, and a few of our fellow project mates that deal with the same arena, but it can definitely be extended in order to suit for varied applications. The concept of Buddy List as such in any talk or messenger software can be implemented with nodes / systems and incorporated with the current application.
8. References [1] http://www.p2pfoundation.net The Foundation for P2P Alternatives. [2] http://www.etse.urv.es/~cpairot/dhts.html Distributed Hash Table links. [3] Hari Balakrishnan, M.Frans Kaashoek, David Karger, Robert Morris, and Ion Stoica. Looking up data in P2P systems. In Communications of the ACM, February 2003. [4] Karger, D., Lehman, E., Leighton, F., Levine, M., Lewin, D., And Panigrahy, R. Consistent hashing and random trees: Distributed caching protocols for relieving hot spots on the World Wide Web. In Proceedings of the 29th Annual ACM Symposium on Theory of Computing (El Paso, TX, May 1997), pp. 654–663.
- 52 -
[5] Dabek, F., Brunskill, E., Kaashoek, M. F., Karger, D., Morris, R., Stoica, I., And Balakrishnan, H. Building peer-to-peer systems with Chord, a distributed location service. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems (HotOS-VIII) (Elmau/Oberbayern, Germany, May 2001), pp. 71–76. [6] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: session initiation protocol. RFC 3261, Internet Engineering Task Force, June 2002. [7] A. Gupta, B. Liskov, and R. Rodrigues. One hop lookups for peer-topeer overlays. In HotOS IX: The 9th workshop on hot topics in operating systems, Lihue, Hawaii, USA, May 2003. USENIX. [8] Chunqiang Tang, Zhichen Xu and Sandhya Dwarkadas. Peer-to-peer Information Retrieval using Self-organising Semantic Overlay Networks. [9] Kundan Singh and Henning Schulzrinne. Peer-to-Peer Internet Telephony using SIP. [10] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan. Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications. [11] Bilhanan Silverajan, Ilkka Karvinen, Janne Mäkihonka, Jarmo Harju. The Design of a flexibly interworking distributed message based framework. [12] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Design Patterns: Elements of Reusable Object – Oriented Software. [13] Ant´onio Rito Silva1, Francisco Assis Rosa2, Teresa Gonc¸alves2 and Miguel Antunes. Distributed Proxy: A Design Pattern for the Incremental Development of Distributed Applications. [14] Henning Schulzrinne and Jonathan Rosenberg, Internet Telephony: Architecture and Protocols an IETF Perspective.
- 53 -
9. Appendix 9.1 List of diagrams 1. Use Case Diagram for Connecting to / Creating the ring
(10)
2. Use Case Diagram for making a call
(11)
3. Use Case Diagram for Disconnecting from the ring
(11)
4. Class Diagram for VOIX
(12)
5. Sequence Diagram for joining the network
(13)
6. Sequence Diagram for leaving the network
(14)
7. Sequence Diagram for making the call
(15)
8. Flow Diagram for joining the ring
(16)
9. Flow Diagram for leaving the ring
(16)
10. Flow Diagram for Lookup Service
(17)
11. Flow Diagram for making the call
(18)
12. State Diagram for VOIX
(18)
13. Generic Architecture using Chord Protocol
(23)
14. Existing Architecture of IP Telephony Application
(23)
15. Modified Architecture of IP Telephony after incorporating Chord Protocol (Architecture of our system) (24) 16. Component Level Diagram
(25)
9.2 Definitions / Key words Peer-to-Peer network (P2P) A peer-to-peer network or P2P network is a distributed system or a computer network which has all the component nodes having similar roles, also termed as peers and privileges offering both services of client and server to the other such nodes of the network. Client-Server network A client-server network is a type of computer network that involves many nodes (clients) connected to a specific node or nodes (server/s) where the client nodes or systems are mainly seeking the requests and services from the server nodes with remarkably distinct privileges. Distributed Hash Table (DHT) Distributed Hash Table is a class of decentralized distributed systems that provide a lookup service similar to a hash table and a participating node can efficiently retrieve the value associated with a given name. The mapping of names of values is distributed among nodes such that the continuous arrival, departure of nodes through the system leads to minimal disruption. Chord Protocol Chord Protocol is a ring based distributed hash table for structured P2P systems. Each node stores at most log (N) entries (or states) in its finger table to point to other peer. Lookup is done in O (log (N)) time. Design Patterns Design pattern is a general repeatable solution to a commonly occurring problem in software design. Object-oriented design patterns typically show relationships and interactions between classes or objects. IP Telephony IP Telephony is a routing of voice conversations over the internet or any IP based network. Internet telephony is also known as voice-over-IP or IP telephony (IPtel), and is the real-time delivery of voice (and possibly other multimedia data types) between two or more parties, across networks using the Internet protocols, and the exchange of information required to control this delivery.
- 55 -
Session Initiation Protocol (SIP) The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. VOIX It’s a French word for “Voice” – the name of our software implementing IP Telephony using Chord Protocol.
- 56 -
