Beruflich Dokumente
Kultur Dokumente
Dissertation submitted in partial fulfilment for the degree of Master of Science in Advanced Computing
Abstract
Peer To Peer architectures, abbreviated (P2P), are very successful networking architectures, and they are continuously developed and increasingly used, for the fact that they support efficient distribution of resources and are stable against disturbances such as bottlenecks, local network failures or denial of service attacks. Network Address Translator, abbreviated (NAT), introduced to overcome the lack of IPv4 addresses; it acts like an interface between the Internet and the LAN. The advantages for using NATs are private IP addresses reusability, and additional security because of the NATs firewall like behaviour. The disadvantage for using NATs is the NAT Traversal problem in P2P applications. Running a service behind a NAT arise the NAT traversal problem, because NAT boxes don't have an automatic mechanism to direct the incoming packets to the right internal host. Port forwarding, relays and Hole Punching are popular methods to solve the NAT traversal problem. The goal of this project is to design and implement a NAT traversal solution which will decrease the load on the server by decreasing the number of relayed connections, but has a reasonable scalability, a Java based solution because OneDrum uses JXTA framework to develop P2P applications, and also java uses a safe environment and allows a lot of powerful libraries like Netty which was used in the implemented solution, a solution that uses a reliable transport layer protocol TCP in all communications; the data transfer, information message exchange and the Hole Punching algorithm, a solution that is simple to understand by other developers, simple to be integrated into other applications, also a tested solution and proved to be working. However, using TCP in performing Hole Punching mechanism, adds extra complexity to the Hole Punching mechanism, but on the other hand, reliable sessions will be formed and that is easy to manage and eliminate the complexity that has to be added to the unreliable UDP connections in order to transfer reliable data over UDP. Researches on different Hole Punching approaches were undergone; these approaches have some points of strength as well as weaknesses, these points of strength and weaknesses were described in this dissertation. According to OneDrum company requirements, the NAT traversal solution proposed by this dissertation for Cone based NATs was successfully implemented using java, with the aid of Netty library and the TCP Hole Punching was performed, tested and proved to be working. -i-
Attestation
I understand the nature of plagiarism, and I am aware of the University's policy on this I certify that this dissertation reports original work by me during my University project.
Signature
Date
- ii -
Acknowledgements
First of all, I would like to acknowledge my supervisor Dr. Mario Kolberg for his unlimited support, guidance and valuable suggestions during the period of accomplishing this dissertation. Also, I would like to thank my family for their endless support and love during all the years of carrying out my studies, especially during the last three months while I was writing this dissertation, and for the encouragement they give me whenever I face an obstacle. Also, I would like to thank my teachers, friends, classmates and all who supported me during the past academic year.
- iii -
Table of Contents
Abstract ............................................................................................................... i Attestation .......................................................................................................... ii Acknowledgements ...........................................................................................iii Table of Contents .............................................................................................. iv List of Figures .................................................................................................. vii 1 Introduction ................................................................................................. 1 1.1 1.2 1.3 1.4 2 Dissertation Background ...................................................................... 1 Dissertation Objectives......................................................................... 1 Achievements ....................................................................................... 2 Dissertation Overview .......................................................................... 2
2.1.1 Advantages and Disadvantages of Client Server Architecture ....... 3 2.2 Peer To Peer Architecture .................................................................... 4
2.2.1 Structured Peer To Peer networks .................................................. 5 2.2.2 Distributed Hash Tables.................................................................. 5 2.2.2.1 Chord ........................................................................................ 6 2.2.2.2 CAN ......................................................................................... 6 2.2.3 P2P Topologies ............................................................................... 7 2.2.3.1 Ring Topology ......................................................................... 7 2.2.3.2 Hierarchical Topology ............................................................. 7 2.2.4 Unstructured Peer To Peer networks .............................................. 8 2.2.4.1 Query Flooding ........................................................................ 9 2.2.4.2 Random walk ........................................................................... 9
- iv -
2.2.4.3 Pure Peer To Peer Networks .................................................. 10 2.2.5 Hybrid Peer To Peer Networks ..................................................... 10 2.3 2.4 Advantages and Disadvantages of P2P Networks .............................. 12 Network Address Translation............................................................. 13
2.4.1 Full Cone NAT ............................................................................. 13 2.4.2 Address Restricted Cone NAT ..................................................... 14 2.4.3 Port Restricted Cone NAT ............................................................ 14 2.4.4 Symmetric NAT ............................................................................ 15 2.4.5 NAT Summary .............................................................................. 15 2.5 NAT Traversal Techniques ................................................................ 16
2.5.1 Port Forwarding ............................................................................ 16 2.5.2 Upnp.............................................................................................. 16 2.5.3 Application Layer Gateways ........................................................ 17 2.5.4 STUN ............................................................................................ 17 2.5.5 TURN............................................................................................ 18 2.5.6 Hole Punching............................................................................... 18 2.6 2.7 Peer To Peer in NAT Environment .................................................... 19 NAT Traversal Related Work ............................................................ 19
2.7.1 NatTrav ......................................................................................... 20 2.7.2 Concurrent / Parallel Hole Punching ............................................ 21 2.7.3 STUNT.......................................................................................... 22 2.7.4 JXTA ............................................................................................. 22 2.7.5 Skype ............................................................................................ 23 2.8 3 Summary ............................................................................................ 23
Design ........................................................................................................ 29 4.1 4.2 The Requirements .............................................................................. 29 The NAT Traversal Approach............................................................. 30
4.2.1 The NAT Traversal Approach Messages....................................... 32 4.3 5 The Software Design .......................................................................... 33
5.1.1 Netty Library................................................................................. 36 5.1.2 The Codec ..................................................................................... 38 5.1.3 The Library Structure .................................................................... 39 5.2 6 The Sample Application ..................................................................... 44
Testing ....................................................................................................... 46 6.1 6.2 Practical Experiment .......................................................................... 46 Software Testing ................................................................................. 47
6.2.1 Unit testing .................................................................................... 47 6.2.2 Integration Testing ........................................................................ 50 7 Conclusion ................................................................................................. 52 7.1 7.2 7.3 Summary ............................................................................................ 52 Evaluation........................................................................................... 52 Future Work ........................................................................................ 54
References ........................................................................................................ 55
- vi -
List of Figures
Figure 1. Client Server Architecture ................................................................................... 3 Figure 2. Ring Topology. .................................................................................................... 7 Figure 3. Hierarchical Topology ......................................................................................... 8 Figure 4. Pure P2P Topology............................................................................................. 10 Figure 5. Super Node Hybrid P2P Topology..................................................................... 11 Figure 6. Full Cone NAT .................................................................................................. 13 Figure 7. Address Restricted Cone NAT........................................................................... 14 Figure 8. Port Restricted Cone NAT ................................................................................. 15 Figure 9. Symmetric NAT ................................................................................................. 15 Figure 10. Figure 11. Figure 12. Figure 13. Figure 14. Figure 15. Figure 16. Figure 17. Figure 18. Figure 19. Figure 20. Figure 21. Figure 22. Figure 23. Figure 24. NatTrav Sequential Hole Punching protocol ................................................. 20 NatTrav Test Scenario 1 ................................................................................. 25 NatTrav Test Scenario 2 ................................................................................. 26 NatTrav Test Scenario 3 ................................................................................. 27 NatTrav Test Scenario 4 ................................................................................. 28 NAT traversal approach design and messages flow ....................................... 30 nettynattrav Package ...................................................................................... 34 The commandline Package ............................................................................ 34 The test Package ............................................................................................ 35 Netty Framework ........................................................................................... 37 Encoded ConnectMessage Frame .................................................................. 38 Encoded RemoteEdgePeerInfoMessage Frame ............................................. 38 Encoded ConnectionCompletedMessage Frame ........................................... 39 Encoded CloseConnectionWithMessage Frame ............................................ 39 Library Practical Test ..................................................................................... 46
- vii -
Figure 25. Figure 26. Figure 27. Figure 28. Figure 29.
EncoderDecoderTest Screenshot ................................................................... 48 MapKeyTest Screenshot ................................................................................ 49 ConnectionRegistryTest Screenshot .............................................................. 50 IntegrationTest Screenshot ............................................................................. 51 WireShark Screenshot .................................................................................... 53
- viii -
1 Introduction
Peer To Peer architectures, abbreviated (P2P), are very successful networking architectures, and they are continuously developed and increasingly used, for the fact that they support efficient distribution of resources and are stable against disturbances such as bottlenecks, local network failures or denial of service attacks. Skype is one of the most famous and a leading P2P application, especially in solving P2P connection problems like running on peers from behind NAT devices which is known as the NAT traversal problem. The subsequent sections will describe in details the dissertation context as well as the dissertation objectives and the achievements done by this dissertation.
Hole Punching mechanism, adds extra complexity to the Hole Punching mechanism for the fact that TCP connection allows only binding to a specific port or sending data through that specific port but not both, but on the other hand, reliable sessions will be formed and that is easy to manage and eliminate the complexity that has to be added to the unreliable UDP connections in order to transfer reliable data over UDP.
1.3 Achievements
Researches on different Hole Punching solutions were undergone; these solutions have some points of strength as well as weaknesses. NatTrav library was tested thoroughly as described in chapter 3. According to OneDrum company requirements, the NAT traversal solution proposed by this dissertation for Cone based NATs as described in chapter 4, was successfully implemented using java, with the aid of Netty library and the TCP Hole Punching was performed as described in chapter 5, and tested as described in chapter 6.
Figure 1.
Since all the data stored on servers, so it is easy to control the data and maintain security aspects like authentication and authorization to manage the data access and changing of the data to be made by authorized clients.
-3-
Since data storage is centralized, it is easy to the network administer to update the data and therefore no data consistency problem.
As s disadvantage, the server can be a bottle neck if the clients' requests increase drastically, and to solve this problem using multiple servers will introduce other issues like data consistency and costs.
Since all the data stored in the server, if the server fails all the client will not be able to get the data, so the server is a single point of failure.
use of traditional client server architecture, instead of that, every host in peer to peer networks can act at a given moment either as a server responding to other client(s), or as a client requesting resources from other client, so the peers can be considered equal in peer to peer networks. But since every peer can offer its services to the other peers in the network, there must be a way to find the peers that hold the desired resource or service. Peer to peer systems typically implement an application layer overlay network or a virtual topology on top of the physical network topology. These overlays are used for indexing and peer discovery and are exchanged directly over the network. The P2P overlay network consists of all the participating peers as network nodes. P2P networks can be classified as structured, unstructured or hybrid according to the way the nodes in the overlay network are linked to each other. All peer to peer networks have one thing in common; a connection between the peer requesting a service or a resource, and the peer offering the service or the resource. The process of how those two peers find each other can be implemented in different ways. General topologies and ways of indexing will be explained in the following sections [13].
departures, and failures. Notable distributed networks that use DHTs include BitTorrent's distributed tracker, the Bitcoin monetary network, the Kad network, the Storm botnet, YaCy, and the Coral Content Distribution Network. In a DHT network, every node has a unique identifier and the efficiency of the overlay network has a direct impact on the scalability of the system where each node maintains a routing table containing pointers to a small number of other neighbor nodes, so that the incoming queries are forwarded to the node that is closest to the look up key. DHT systems vary in measuring the closeness of the requested node. The following sections briefly describe the most important DHTs and their characteristics [12].
2.2.2.1 Chord
Chord is a simple and common approach used in P2P networks. In the Chord overlay network every node is assigned to an m-bit index or identifier arranged counter clockwise in a virtual circle, this identifier is the hash code of the node's IP address. Also every keys is assigned to an m-bit identifier, this identifier is the hash code of a keyword, such as a file name. Every node maintains information about its direct neighbors in the ring i.e. its successor and predecessor. If there are N nodes and K keys, then each node is responsible for roughly K / N keys. Chord requires each node to keep a finger table containing up to m entries. The ith entry of node n will contain the address of successor (n + 2i). Using this finger table, the number of nodes that must be contacted to find a successor in an N-node network is O(logN) which is a faster approach to find the required node than if each node only knows its direct successor [11].
2.2.2.2 CAN
In contrast to the other described overlay networks, CAN uses a d dimensional Cartesian coordinate space on a d torus. Each peer is responsible for one zone in this space and peers are called neighbors, if they are responsible for adjacent zones to the local peer. Resources are mapped deterministically to a point in this space and belong to the node responsible for that area. -6-
A CAN node maintains a routing table that holds the IP address and virtual coordinate zone of each of its neighbors. A node routes a message towards a destination point in the coordinate space. First, the node determines the closest neighboring zone to the destination point, and then uses the routing table looks up that zone's node's IP address [11].
Peer
Figure 2.
Ring Topology.
to their children, and so on till the leaf nodes. Examples for such distributed systems are the Domain Name Service (DNS), Certification Authorities (CAs) or the USENET. All of them have in common that there are always levels of importance or referencing, and the work is distributed over that hierarchy [12].Figure 3 shows the Hierarchical topology.
Peer
Peer
Peer
Peer
Peer
Peer
Peer
Peer
Figure 3.
Hierarchical Topology
drunkard's walk and Lvy flight. Random walks are related to the diffusion models and are a fundamental topic in discussions of Markov processes [12].
Peer
Figure 4.
application is running. Search queries from the peers are directed towards the central server which searches its internal database for matches. If this search succeeds, the querying peer gets a result list with the peers offering the desired resource. To access this resource, a direct connection between the two peers is established. This direct connection between the peers distinguishes the centralized peer to peer topology from the client/server architecture, since no actual resources are stored on the central peer. The drawback in this architecture is that the central server can be a single point of failure. In case of central node failure, the whole system fails. In case of heavy load on the central server, this bottleneck limits the efficiency of the whole network. Napster is an example for applications that used centralized topology. Another type of hybrid networks is the super node; which is instead of having a centralized server, some of normal nodes get promoted to become local leaders for other nodes, sometimes they are called group leader nodes, super nodes or ultra nodes. The important fact about them is that they locally behave like central servers for a group of other nodes. But among the group of super nodes every one of them is equal. What makes a normal node a super node depends on the function of the application. Sometimes it is enough for a normal peer to become a super peer, if it has enough bandwidth to share, in other applications also the availability over time, or its reach ability in the network matters. The super node keeps a list of peers attached to it and exchanges maintenance messages with its neighbor super nodes.
Q eply
uery
uery
R eply
Peer
Peer
Super node
Super node
eply
eply
Super node
Super node
Peer
uery
Peer
Peer
Figure 5.
uery
Since super nodes only have to keep track of a relatively small group of attached peers, the bottleneck is reduced, and the failure tolerance is increased. Examples for this hybrid topology are Kazaa and its successor Skype. Figure 5 shows super node hybrid peer to peer topology [12].
- 12 -
Figure 6.
External hosts can send packets to the internal host via its external socket without any preceding connection attempts from behind the NAT device or any other restrictions. Figure 6 shows the full cone NAT behavior [12].
Figure 7.
Figure 8.
Figure 9.
Symmetric NAT
and finally in a Symmetric NAT, no reserved translation is used, so a new translation for every outgoing connection [12].
2.5.2 Upnp
UPnP is an abbreviation to Universal Plug and Play, which is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet - 16 -
gateways, Wi-Fi access points, mobile device, to discover each other's presence on the network and establish a connection between them. The UPnP was introduced by the Universal Plug and Play Forum which is a Forum consists of over eight hundred vendors involved in consumer electronics and network computing, to create a simple and robust way to connect stand alone devices made by different vendors. The concept of UPnP is an extension to plug and play technology used to automatically connect devices directly to a computer. UPnP uses Simple Service Discovery Protocol SSDP to discover the network to find the nearest control point and also broadcast the presence of a control point. But the UPnP usually is disabled by default, for a good reason. In 2001, the eEye company published a press release about three highly dangerous security vulnerabilities existing in all versions of Windows. For instance, a machine running Windows XP accessible from the internet could be easily attacked using a buffer overflow, if the UPnP service on that machine was enabled and the machine was directly exposed to the public internet [8].
2.5.4 STUN
The STUN protocol (Simple Traversal of User Datagram Protocol through Network Address Translator) is a relatively simple mechanism that allows applications to discover - 17 -
NATs and firewalls which are installed between them and the public internet. STUN also allows two applications, both behind a NAT device, establishing a direct UDP connection between them. STUN is often used in Voice over IP (VoIP) telephony together with the Session Initiation Protocol (SIP) to allow the telephony applications behind a NAT device to be reachable from the public internet [3].
2.5.5 TURN
TURN is an abbreviation for Traversal Using Relay NAT; it is a protocol that enables clients resides behind a NAT box, to receive incoming data over TCP or UDP. TURN usually used as plan B or the fallback strategy for STUN, if a specific NAT device refuses to work as demanded by STUN, in this case TURN will relay all the traffic. If a client wants to be available for other clients, it registers with a TURN server the server then forwards all incoming data addressed to the client from a third host over the already existing connection between the client and the TURN server. Because with TURN all traffic between two peers has to be relayed by the TURN server, it can only be used as a last resort, because the server must be available 24/7, with high bandwidth which leads to more costs as the network scales up [4].
messages, but the local NAT box added a translation entry on its table for the second client or in other words punching a hole in the NAT firewall. Now, when the second client sends data packets to the public address of the first one, to the exact IP and port where the previous message came from, the message this time will be forwarded throw the hole and the connection will be established. TCP can also be used to perform the Hole Punching mechanism, which was implemented in this project.
2.7.1 NatTrav
The NatTrav is another approach that was presented in a paper from J.L. Eppinger in 2005. While the paper gives a detailed description of the mechanisms used in that library, the Java source code was not published. In NatTrav paper the author suggested and implemented a library that offers the necessary services to traverse NAT devices using the TCP based sequential Hole Punching. It uses UDP for peer registration messages. It depends on connection brokers to allow establishing connections between two peers. In order to improve availability and scalability of the system, these connection brokers need to be replicated, but they are not part of the actual peer to peer network. Uniform Resource Identifiers (URIs) are used to identify and locate peers for connection establishment. However an existing java based library called NatTrav has been published, but it uses UDP Hole Punching method, and relaying method. Therefore the library could not be used for evaluation purposes of the paper. Furthermore, NatTrav paper lacks the support for UDP traversal, which might be required by multimedia streaming applications, while NatTrav library lacks the support of TCP Hole Punching, which is necessary in a reliable data transfer, and also the fact that TCP sessions are easy to manage. Chapter 3 will describe in details the behavior of NatTrav library recorded through several testing scenarios.
Figure 10.
- 20 -
- 21 -
2.7.3 STUNT
Simple Traversal of UDP through NATs and TCP too, which extends STUN to include TCP functionality. It is a java based framework that uses an efficient TCP NAT traversal mechanism. STUNT uses a server and a proxy which are not behind a NAT box, to predict the ports mapping rule used by the NAT device to traverse symmetric NATs. STUNT requires setting the TTL value field in the packets. In addition, the directory server where every client has to be registered has to be the same for all nodes. The library is based on a paper of Guha and Francis. They published the STUNT library to be tested and their clients could connect to other NATed clients in more than 85% on average, using the algorithm implemented in STUNT. However, SUNT concentrate on Symmetric NAT traversal and requires fiddling with standard TTL value [5].
2.7.4 JXTA
JXTA is an open source peer to peer framework introduced by Sun Microsystems in 2001. It is basically a set of XML based protocols and allows developing applications that can be run on virtually any Java enabled device, from cell phones up to main frames, in order to allow decentralized communication. JXTA uses relaying to allow NATed peers to connect to the JXTA peer to peer network. Peers behind a NAT device in JXTA called edge peers; are connected to reachable nodes called relay nodes. These relay nodes forward all messages addressed to the edge peers registered with them via Pipes which are virtual communication channels used by JXTA. A Rendezvous peer is a special purpose peer used to coordinate the peers in the JXTA network to propagate the messages if the peers are on different subnets. While relaying is a very reliable NAT traversal technique, the network performance drops dramatically if the relay node bandwidth is exhausted by all the relayed message traffic. The relay nodes can become bottlenecks very easily for all edge peers registered with them. JXTA is a very powerful framework and it offers many features to the developer, but the relay performance issues and the complexity of the JXTA are the most noticeable cones. An efficient NAT traversal framework should be simple to apply and uses the relaying technique as a last resort [6].
- 22 -
2.7.5 Skype
Skype is a very successful peer to peer network proprietary software application mostly used for multimedia communications. Since it is a non open source and most of the communication is encrypted, most publicly available technical information about it is reverse engineered or a prediction of what a Skype network looks like rather than it real topology and behavior. To do so, Baset und Schulzrinne ran various experiments using network monitoring tools. They gained deep insight into the Skype protocol and monitor Skype way of solving the NAT traversal problem. The Skype uses a hybrid overlay network consists of two different types of nodes, ordinary nodes and super nodes. Super nodes are ordinary nodes equipped with better bandwidth, CPU resources, memory and availability than ordinary nodes. The super nodes are the end points of ordinary hosts in the overlay network. Because they become super nodes if they are behind NAT devices, they can act as some kind of rendezvous server for other peers in the network in order to traverse the NAT devices. Skype uses a third type of node which is the credential server. This credential server keeps usernames unique and certifies the peers public keys used for the encrypted point to point connection. Even if this introduces a single point of failure to the system, but it is probably the only way that allow Skype to manage the communications and have control over the Skype network. Control over the network is important to Skype, since Skype offers additional paid services for calling to landline phones, mobile phones all over the world, and that depends on having full administrational control over the network to manage the financial functions like online account balance top up .While the NAT traversal mechanisms built into Skype seem to work very reliably, they are not available to P2P developers, even though if Skype is willing to publish some of its proprietary source code according to some articles, nothing was published related to NAT traversal techniques used by Skype at the time of writing this dissertation [10].
2.8 Summary
This chapter presented five different existing approaches that can help developers of peer to peer applications to overcome the NAT traversal problem. However, every approach lacks support in one or several aspects in regard to the dissertation objectives. NatTrav and JXTA only support TCP for data transport through NAT devices, but NatTrav Library uses UDP Hole Punching which forms unreliable UDP sessions, with the fact that - 23 -
some ISPs do not allow UDP, also it uses NIO library which is not efficient and fast as Netty while JXTA is complex to understand and uses only connection relay which is cost effective and inefficient. STUNT on the other hand has implemented excellent mechanisms for NAT traversal, but it uses a non default values for TTL field, also it uses NIO rather than Netty library, beside that the published java source code did not function as expected. Finally, although Skype seems to have perfect solutions for many NAT and firewall related problems, but they are proprietary and not available to the public, therefore, the concurrent TCP Hole Punching was adopted and implemented as described in chapter 4 and chapter 5.
- 24 -
Figure 11.
and NAT B. Windows firewall was enabled on host B demonstrated as Firewall B, and configured to allow UDP port 47411, which is the port used to connect to the instance of the application that will act like a broker or a relay. Running an instance of NatTrav at Host A to act like a broker without providing any parameter to the command line, this will bind to port 47411, then running instances of NatTrav on Host B and all other virtual machines, providing the destination socket in the command line, that is the IP address of Host A and port number 47411. The UDP Hole Punching was performed so that VM1 connects directly to VM3 and VM4 and terminating the instance of NatTrav running on Host A will not affect the connection. Figure 11 shows NatTrav test scenario1. Scenario 2 In this scenario, a network was created which composed of two physical hosts Host A and Host B, connected wirelessly. Two virtual machines were installed on each of these hosts demonstrated as VM1, VM2 on host B and VM3, VM4 on host A. VMware virtual NAT was enabled on both hosts demonstrated by NAT A and NAT B. Windows firewall was enabled on both host A and host B demonstrated as Firewall B, and both firewalls configured not to allow unsolicited TCP or UDP.
Figure 12.
Running an instance of NatTrav at Host A to act like a broker without providing any parameter to the command line, this will bind to port 47411, then running instances of NatTrav on Host B and all other virtual machines, providing the destination socket in the command line, that is the IP address of Host A and port - 26 -
number 47411. No connection was established, VM1, VM2 and B cannot connect to A, but allowing UDP port 47411 on firewall A, will enable VM1 and VM2 to connect to host A, however they can't discover VM3 and VM4. Enabling UDP port 47411 on both firewalls allows a relayed connection between VM1 and VM3. Figure 12 shows NatTrav test scenario2. Scenario 3 In this scenario, a network was created which composed of three physical hosts Host A, Host B and Host C; connected wirelessly. Host C is connected to the network without being behind a firewall or NAT box. Two virtual machines were installed on each of these hosts demonstrated as VM1, VM2 on host B and VM3, VM4 on host A. VMware virtual NAT was enabled on both hosts demonstrated by NAT A and NAT B. Windows firewall was enabled on both host A and host B demonstrated as Firewall B, and both firewalls configured to allow UDP port 47411. Figure 13 shows NatTrav test scenario3.
Figure 13.
Running an instance of NatTrav at Host C to act like a broker without providing any parameter to the command line, this will bind to port 47411, then running instances of NatTrav on Host B and all other virtual machines, providing the destination socket in the command line, that is the IP address of Host C and port number 47411.UDP Hole Punching was performed and a connection was established between VM1, VM2 on host B and VM3, VM4 on Host A, however - 27 -
VM1 could discover and connects to VM3, VM4 on Host A, but VM2 could only discover VM3 not VM4, which I believe is a UDP socket multi connection issue rather than a VMware related issue. Scenario 4 In this scenario, a network was created which composed of three physical hosts Host A, Host B connected wirelessly. Host C is connected to the network without being behind a firewall or NAT box. NAT32 which is a virtual NAT tool is installed on Host A which will allow multi NAT translations to the incoming connections from VM1 and VM2 on Host B. Two virtual machines were installed on each of these hosts demonstrated as VM1, VM2 on host B and VM3, VM4 on host A. VMware virtual NAT was enabled on both hosts demonstrated by NAT A and NAT B. Windows firewall was enabled on both host A and host B demonstrated as Firewall B, and both firewalls configured to allow UDP port 47411. Running an instance of NatTrav at Host C to act like a broker without providing any parameter to the command line, this will bind to port 47411, then running instances of NatTrav on Host B and all other virtual machines, providing the destination socket in the command line, that is the IP address of Host C and port number 47411. A relayed connection was established between VM1, VM2 on host B and VM3, VM4 on Host A, however VM1 could discover and connects to VM3, VM4 on Host A, but VM2 could only discover VM3 not VM4. Terminating the instance of NatTrav running on Host C will drop all the connections. Figure 14 shows NatTrav test scenario4.
Figure 14.
4 Design
For the reasons described in section 2.5 and summarized in section 2.8, and in order to fulfil the specification required by OneDrum, and also to meet the dissertation objectives; a new solution was created, designed and implemented. This chapter describes the design details.
- 29 -
Figure 15.
After the broker exchange NATed peers between the appropriate peers. Once a NATed peer receives the remote peer's information from the rendezvous server, it closes the connection with the server and start to send SYN connection request messages, concurrently and directly between each other using the same socket address that was used to register with the rendezvous server, The reason why they have to close the connection with the server because in TCP, a socket cannot be used for two simultaneous connections, so if they use different socket address in addressing the outgoing packets, NAT devices will translate the local address used in these packets into a new public address differs from the one recoded by the server previously and that will prevent performing the Hole Punching method. However, there is one disadvantage of closing a connection with a peer then reuse the same socket used in that connection to establish a new connection with another peer, which is after closing a connection, the socket used in that connection cannot be used for around four minutes, because after the connection closed the socket will enter the TIME_WAIT state and according to old operating systems, any socket is in the TIME_WAIT state cannot be reused. In newer operating systems they support the socket reuse option so_reuse, that can be added to the application code before calling the connect method, which allows using sockets that are in the TIME_WAIT state without having to wait. The idea behind both NATed peers start sending SYN connection request messages request concurrently is to get to the situation where SYN message from NATed peer X passes NAT X device before the SYN message from NATed peer Y reaches NAT X device, and the SYN message from NATed peer Y passes NAT Y device before the SYN message from NATed peer X reaches NAT Y device, in this way the NAT X device will not reject the SYN message from NATed peer Y because the same socket used as the source endpoint, was used in a message sent previously by X as the destination endpoint, not an unsolicited SYN message, and at the same time, the NAT Y device will not reject the SYN message from NATed peer X because the same socket used as the source endpoint, was used in a message sent previously by Y as the destination endpoint, not an unsolicited SYN message, thus depending on the operating system, one or both peers will respond with a SYN_ACK to the other peer's SYN message, and TCP connection(s) will be established between the two NATed peers traversing the NAT devices. In case the previously described situation did not happen due to delays in the network for software or hardware reasons, the two instances of the P2P application running on both NATed peers will simply try again - 31 -
and again until the previously situation met and they successfully connected, and they likely to succeed in the second try if they fail in the first try. One more thing to mention about the socket reuse option, is that it doesn't consume port numbers, because in case it is not enabled, then the peers should use new different port numbers in contacting another peer, other than those used in contacting the server, even if the connection with the server had been closed, and this is a port numbers consuming process, otherwise they have to wait for around four minutes in order to get the closed socket released from the TIME_WAIT state which is a time consuming process. It seems like most P2P application developers are not aware of the socket reuse address option which is crucial and recommended in P2P applications that uses Hole Punching mechanism to traverse the NAT devices.
RemoteEdgePeerInfoMessage, a class which is used by the broker to send the public socket address of the remote peer to every peer requesting to be connected to the remote pee rand talk on the same topic, its constructor has one parameter which is of type InetSocketAddress object, holding the socket address of the remote peer. RemoteEdgePeerInfoMessage(InetSocketAddress aSocketAddress) - 32 -
ConnectionCompletedMessage(String aPeerID) a class which is used by the peers to send their local peer ID to the remote peer when a connection established between the two peers, in order to confirm that a successful connection was established, it has one parameter which is of type string, holding the peer ID of the local peer. ConnectionCompletedMessage(String aPeerID)
CloseConnectionWithMessage(String aPeerID) a class which is used by the peers to send to the remote peer ID a close connection message, telling the remote peer to close the connection with the initiator, rather than closing the connection locally from the local peer, it has one parameter which is a string object holding the remote peer ID. Although this type of message was not used in the implementation but it adds more flexibility that can be useful to some P2P applications developed based on this library. CloseConnectionWithMessage(String aPeerID)
EdgePeerConnectionHandlerBroker class which handles the connections between the peer and the broker, and the EdgePeerConnectionHandlerPeer class which handles the connections between the peer and the other remote peers, the ConnectionBroker class which creates a connection broker, a broker side handler, the
ConnectionBrokerConnectionsHandler class which is responsible for handling the connections with the broker, the ConnectionRegistry class which is responsible for the logic of the broker, the MapKey class which is used for creating keys for the connection registry map, the Responder class which is needed to implement the call back interface methods, more details in chapter 5.
nettynattrav library package ConnectMessage RemoteEdgePeerInfoMessage EdgePeerConnectionHandlerPeer ConnectionCompletedMessag e CloseConnectionWithMessage MessageEncoder MessageDecoder ConnectionBroker ConnectionBrokerConnectionsHandler ConnectionRegistry Responder MapKey EdgePeer EdgePeerConnectionHandlerBroker
Figure 16.
nettynattrav Package
Figure 17 shows the commandline package which contain the classes that forms a simple application that works on top of this NettyNatTrav library and uses the library classes, the client class which is responsible for creating a peer, the server class which is responsible for creating a broker, more details in chapter 5. commandline package Server Figure 17. Client
Figure 18 shows the test package which contains all the test classes the unit testing classes and the integration test class, the ConnectionRegistryTest class is responsible for testing the ConnectionRegistry class using several test cases, the MapKeyTest class is responsible for testing the MapKey class, the EncodeDecodeMessageTest class is responsible for testing the encoding decoding process of a message, the IntegrationTest class is responsible for testing all of the software components working together, the ConnectionListenerLatch class is used for the integration test to call back when an event occurs, more details about all of these test classes in chapter 6.
ConnectionListenerLatch
Figure 18.
- 35 -
5 Implementation
This first section of this chapter will describe in details the set of requirements, which this dissertation aims to implement a solution for these requirements. The second section of this chapter will describe in details the design of the solution. The third section of this chapter will describe in details how the solution was implemented, what libraries were used in the implementation and show some parts of the code for key methods implementation.
5.1 NettyNatTrav
This section will describe and give in details what are the libraries that have been used and for what reasons they have been chosen. The solution was implemented in java using the Netty library for connection handling instead of the standard NIO library. The next section will describe in details the Netty library.
Other interesting features of Netty that make it the best choice to use as a framework to develop P2P applications since it was designed and written from scratch to provide the best experience in network application development, can be summarised as: Design Unified API for various transport types blocking and non blocking socket, also it is based on a flexible and extensible event model which allows clear separation of concerns, also it is highly customizable thread model single thread, one or more thread pools such as SEDA True connectionless datagram socket support, also it comes with well documented Javadoc, user guide and examples, that make it easy to use and understand. In addition to that it supports encryption in SSL/TLS and StartTLS for more security.
Figure 19.
Netty Framework
Other features to mention here like less resource consumption, minimized unnecessary memory copy, robustness, no more OutOfMemoryError due to fast, slow or overloaded connection, no more unfair read / write ratio often found in a NIO application under high speed network, also it runs OK in a restricted environment such as Applet and Google Android [7].
- 37 -
Figure 20.
The encoded RemoteEdgePeerInfoMessage object is composed of a type field that has the integer value of 2, and a length field representing the byte array length for the remote peer IP address string and another field contains the actual byte array of remote peer IP address string, and another field contains the integer value of the remote peer port number. Figure 21 shows the encoded RemoteEdgePeerInfoMessage frame.
Int Type
Figure 21.
- 38 -
The encoded ConnectionCompletedMessage object is composed of a type field that has the integer value of 3, and a length field representing the byte array length for the local peer ID string and another field contains the actual byte array of local peer ID string. Figure 22 shows the encoded ConnectionCompletedMessage frame.
Int Type
Figure 22.
The encoded CloseConnectionWithMessage object is composed of a type field that has the integer value of 4, and a length field representing the byte array length for the remote peer ID string and another field contains the actual byte array of remote peer ID string. Figure 23 shows the encoded CloseConnectionWithMessage frame.
Int Type
Figure 23.
channel, then the broker will bind or listen to port number 50000 on all the local host network addresses. Three connection options were used the tcpNoDelay, keepAlive to keep the connection alive even if no useful data being transferred or the peers are idle, and this is done by sending arbitrary data continuously , and reuseAddress option to allow the socket in the TIME_WAIT state to be used again without waiting for them to be released. The Broker runs with out providing any parameters.
public class Broker { public static ConnectionRegistry CR = new ConnectionRegistry(); bootstrap.setOption("child.tcpNoDelay", true); bootstrap.setOption("child.keepAlive", true); bootstrap.setOption("reuseAddress", true); bootstrap.bind(new InetSocketAddress(50000)); } } The ConnectionBrokerConnectionsHandler class is used to handle the connection after the broker was created and started listening to the specified port. The handler extends a SimpleChannelHandler, which is Netty abstract class declaring set of event listener, the ConnectionConnectionBrokerConnectionsHandler implements the MessageReceived event, once a message received the decoder will be invoked, if the decoded message is a ConnectMessage then the ConnectionConnectionBrokerConnectionsHandler will display the message content and pass these contents the ConnectionRegistry to perform the matching mechanism. If the decoded message is a ConnectionCompletedMessage then the ConnectionConnectionBrokerConnectionsHandler will display the remote peer ID indicating that a successful connection was formed between the broker and the peer. Finally, if the decoded message is a CloseConnebctionWith, then the ConnectionConnectionBrokerConnectionsHandler will retrieve the connection channel with the specified peer ID and closes this connection. The EdgePeer class is used to create an edge peer, perhaps behind a NAT. it requires two parameters to be supported at runtime, the remote IP address and port number to connect to, usually these are the connection broker public IP address and port number it's listening to. A simple filter to the parameter is used for initial checking that the number of parameter entered before continuing further. - 40 -
If the parameters were entered correctly then the edge peer will connect to the broker using the connect method that requires two parameters to be passed to it, the remote IP address and the remote port number, the local source port is not specified and it will be chosen arbitrarily from the available port numbers pool.
public
class
ConnectionConnectionBrokerConnectionsHandler
extends
SimpleChannelHandler { public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception { . (Check the message received and performs the relative action) .} }
The EdgePeer has a channel with two cached thread pools, and a channel pipeline which holds all the handlers and the codec to perform their actions on the data being transferred over the channel. It also define an inner interface EventListener that has three methods, messageEventCallBack, isConnectet and errorEventCallBack, methods that used as acall back technique when an event occurs theses methods are invoked to call the EdgePeer class back.
Public class EdgePeer { public static ChannelFuture connect(String aRemoteHostAddress, int aRemotePortNumber) {...} public static ChannelFuture connect(String aRemoteHostAddress, int aRemotePortNumber, int aLocalPortNumber) {...} }
Three connection options were used the tcpNoDelay, keepAlive to keep the connection alive even if no useful data being transferred or the peers are idle, and this is - 41 -
done by sending arbitrary data continuously , and reuseAddress to allow the socket in the TIME_WAIT state to be used again without waiting for them to be released. The EdgePeer also implements another connect method that requires three parameters to be passed to it, the remote IP address and the remote port number and the local source port which helps in performing the Hole Punching mechanism with the aid of socket reuse option. The EdgePeerHandlerBroker and EdgePeerHandlerPeer classes are used to handle the connection after the edge peer was connected with a remote host on the specified port. The handlers' classes extend a SimpleChannelHandler and each of them has a constructor that uses a listener which is the client's anonymous inner class EventListener which is a call back interfaces with three main methods that make it easier to test. The handler implements three methods described earlier in this chapter. The channelConnected event is used display the remote peer information and to create and send a ConnectionCompletedMessage to the other peer. The messageReceived event is used to connect to the remote peer once the public socket for that remote peer through RemoteEdgePeerInfoMessage object, and then closes the connection with the broker, if an exception occurs, due to the remote peer not available or the network fails. The exceptionCaught is used to retry connecting to the remote peer for a specified number of times, five times was set by default.
public class EdgePeerConnectionsHandlerBroker extends SimpleChannelHandler { public EdgePeerConnectionsHandler(EdgePeer.EventListener aClientEventListener, int aRemotePort,String aLocalPeerID) {..} public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e){..} public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {..} public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) throws Exception {. } } - 42 -
The MapKey object an object that holds the information that will be stored in the map for later retrieving of the necessary value.
public MapKey(String aPeerID, String aTopic) { public int hashCode() { .} public boolean equals(Object otherObj) { .} } It is constructor has two string parameters the first parameter is the peer ID of the destination or the recipient, and the second one is the topic of the connect request, those pair of information form the map key for the response channel entry in the map or value. The hashCode and equals methods were overridden with a new version of implementation than the default implementation, to make retrieving the values out from a map, faster, more efficient and accurate. The Responder object is the object responsible for the implementation of the anonymous inner class Response Channel methods. It holds the channel reference of the connection, when it is created in the ConnectionBrokerConnectionsHandler, the reference of the connection channel between the Broker and the EdgePeer is passed into it and stored in the responder object for later use when one of the methods is invoked, so that once a
public class Responder implements ConnectionRegistry.ResponseChannel { public Responder(Channel aChannel) {.} public void sendMessage(RemoteEdgePeerInfoMessage message) {.} public InetSocketAddress getSocketAddress() {.} }
sendMessage is invoked to send a message, the responder will send that message on the channel reference maintained earlier. Also the maintained channel reference is also used - 43 -
when the getSocketAddress method is invoked; this method will return the remote socket address used on the channel formed between the connected peer and the broker. The ConnectionRegistry object is used by the connection broker; it is responsible for registering the incoming requests from peers, and checks these request messages for a mach, and once the match occurs it will invoke the ResponseChannel anonymous inner class methods send and getSocketAddress. First it initiates a map object that has MapKey object as a key for the corresponding value which is the ResponseChannel object. When a connection request from a peer is received via a ConnectMessage object, it gets from the message the destination peer ID and the topic which forms the MapKey, and check if this key corresponds to a matching key that has been stored earlier in the map if so then send then it will send each remote peer the peer, the public addresses of the other address, using the ResponseChannel object stored in the map, otherwise if the key does not corresponds to a matching key then it store this key in the map. public class ConnectionRegistry { Map<MapKey,ResponseChannel> connectionRegistryMapTable = new HashMap<MapKey, ResponseChannel> (); public void registerConnection(ConnectMessage connectMessage, ResponseChannel responseChannel) {.} public interface ResponseChannel { public void sendMessage (RemoteEdgePeerInfoMessage emoteEdgePeerInfoMessage); InetSocketAddress getSocketAddress(); }}
and invoke the start method in it to start listen on a specific port number. The client class which is responsible for creating a peer, will create a new Edgepeer object, then invoke the openConnection method to connect to a connection broker, then it invokes a requestNatTravConnection method to send a connect message to the broker requesting connection with remote peers. If the connection with the broker was successful the connection with the remote peer was successful as well then the clients on both connected peers can exchange text messages, if any connection error occur due to network failure, broker failure or remote peer failure, a feed back to the user when a connection error occur will be given by displaying a message with the corresponding error code.
public class Server { public static void main(String[] args) { ConnectionBroker server = new ConnectionBroker(); server.start(LISTENING_PORT); }
public class Client { public static void main(String[] args) throws IOException { EdgePeer peer = new EdgePeer(cll1, LOCAL_PEER_ID); peer.openConnection(CONNECTION_BROKER_IP, CONNECTION_BROKER_PORT); peer.requestNatTravConnection(LOCAL_PEER_ID, remotePeerID,connectionTopic); ... ( send a text message) ... ( display and handle exceptions ) }
- 45 -
6 Testing
Two types of tests were performed, a practical test which involved building a small network with NATed peers, and a software test using JUnit4.0 library for unit testing and integration test. The next two sections will give more details about both of these tests.
Figure 24.
- 46 -
As shown in the figure 24, two NATed peers peer A and Peer B are running behind NAT devices, NAT A and NAT B respectively, peer A uses a private LAN IP address 10.0.0.2 and peer B uses a private LAN IP address 127.16.0.2. NAT A uses a public IP address 139.153.254.178 on its WAN port and a local IP address 10.0.0.1 on its wireless LAN port, while NAT B uses a public IP address 139.153.254.179 on its WAN port and a local IP address172.16.0.1 on its wireless LAN port. The connection broker is using a public address 139.153.254.89 and all peers contact this broker, requesting about remote peers public addresses, once those peers got the requested information they start trying to connect to each other simultaneously, while their connection with the broker is terminated.
method
is
used
to
test
the
encoding
and
decoding
process
of
RemoteEdgePeerInfoMessage object in the same way as testConnect method, and the testClose method is used to test the encoding and decoding process of a CloseConnectionWithMessage object in the same way as testConnect method. Figure 25 shows EncodDecodMessagetest eclipse screenshot.
Figure 25.
EncoderDecoderTest Screenshot
The MapKeyTest is a unit test class used to test the new overridden implementation of the equals and hashCode methods of the MapKey object. It creates three ConnectMessaqge objects, two of them only are identical, then it creates three MapKey objects based on the three ConnectMessage object created earlier, using the destination peer ID and the topic used in the ConnectMessage objects, this will form two identical MapKey objects. Then it checks the equal's method by asserting the identical MapKey objects and expecting the result to be true, while expecting the result to be false by asserting one of those two identical MapKey objects with the third MapKey object. The hashCode method is tested by asserting the hash codes value of the identical the identical MapKey objects and expecting the result to be equal, while expecting the result to be
- 48 -
unequal by asserting one of those two identical MapKey objects hash code value with the third MapKey object hash code value. Figure 26 shows MapKeyTest eclipse screenshot.
Figure 26.
MapKeyTest Screenshot
The ConnectionRegistryTest as shown in figure 27, is a unit test class used to test the ConnectionRegistry object behaviour. It creates, a ConnectionRegistry object and several different ConnectMessage objects composed of three different peers, it also creates and initializes three socket addresses, three mocked up ResponseChannel objects implementation, and three ArrayList objects, all of which corresponds to one of the specified peers. The SendMessage method implementation is mocked up using a new implementation which adds the message to be sent to a specified peer to its corresponding ArrayList object, while the new implementation of the getSocketAddress method will return the corresponding socket address previously created and initialized. Several test cases were performed to check variety of scenarios like two peers trying to connect to each other on the same topic, two peers trying to connect to each other on different topic, two peers trying to connect to each other on different two topics and many other test cases. - 49 -
Figure 27.
ConnectionRegistryTest Screenshot
awit() method, which will suspend a thread and set the timer. The eventAwit method create and initialise a Boolean check variable it will return true only if the timer is activated. When the countdown method is invoked in the messageEventCallBack method, it will activate the timer, set the Boolean check variable to true, and after the specified time elapses, the thread will enter the ready state. The integration test class creates and initializes five ConnectionListenerLatch objects, five Client objects and a Server object. The Server's start method will be invoked to bind the server to a specified port number, then each of the five Client objects will try to connect to the server by invoking the openConnection method, supporting the servers IP address and port number, the each Client object will send ConnectionRequestMessage by invoking the requestNatTravConnection method, then perform assertion based on the value of the Boolean variable of each Client object CountDownLatch which will return true if the countDown method has been invoked in the messageEventCallBack method, which in turn will only be invoked from the MessageReceived event on each Client object when a RemoteEdgePeerInfoMessage is received, other wise it will return false, to check that the a client receive the appropriate information from the server. In order to check that there exists a server listening to the port that the client is trying to connect to, assertions were made based on the isConnected method which will return true if there is no connection error, otherwise it will return false. Figure 28 shows IntegrationTest eclipse screenshot.
Figure 28.
IntegrationTest Screenshot - 51 -
7 Conclusion
7.1 Summary
According to the specification OneDrum required in a NAT traversal solution, researches on different Hole Punching solutions were undergone, since Hole Punching method is a simple, powerful and cost effective approach, these solutions have some points of strength as well as weaknesses. According to OneDrum company requirements, the NAT traversal solution proposed by this dissertation for Cone based NATs was successfully implemented using java, with the aid of Netty library and the TCP Hole Punching was performed, and tested.
7.2 Evaluation
Researches on different Hole Punching solutions were made; these solutions have some points of strength as well as weaknesses. NatTrav library was tested thoroughly as described in chapter 3. According to OneDrum company requirements, the NAT traversal solution proposed by this dissertation for Cone based NATs was successfully implemented using java, with the aid of Netty library and the TCP Hole Punching was performed successfully as described in chapter 4 and 5, and tested as described in chapter 6. The implemented solution was successful, according to the practical and software test achieved as demonstrated in chapter 6. The implementation focused on the cone based NATs for the reason it is widely used by most NAT devices vendors. Choosing Netty library was a good choice, because it absorbs a lot of the connections management complexity, and the latest versions of Netty support UDP in addition to TCP, which is advantageous to perform UDP Hole Punching if needed. Although implemented solution did not tackle the symmetric NATs, which requires more sophisticated code to predict the translation by monitoring couple of previous translations for the same peer and calculate the expected translation to be used next, which adds more unnecessary complexity to the implementation, according to [9], most NAT devices brands use cone based translation, only limited NAT devices, not even widely used brands, use Symmetric translation, and most NAT manufacturers are moving away from - 52 -
using the symmetric behaviour in their NAT devices. Also, the implemented solution does not support relaying of the connections as a last resort if the Hole Punching mechanism failed, but that is unnecessary since it was implemented to be integrated in JXTA to develop P2P applications, and JXTA relay all the connections. The implemented solution uses socket reuse address option, which might sounds to be problematic for the first instance in terms of data loss or multiplexing or even security attacks, but since at the network layer, all packets headers contain the protocol field, destination and source IP address fields, in addition to the destination and source port numbers obtained from the transport layer, it is very unlikely that another packet in the network has the same addresses mentioned, however, if that was the case it will cause problems such as data loss. The solution does not have any security aspects implemented, but Netty support encryption using SSL/TLS and StartTLS as described in 5.1.1. The implemented solution uses concurrent TCP Hole Punching, and according to the practical test described in 6.1, running WireShark as shown in figure 29, on one of the NATed peers showed that only one TCP three way hand shake connection established, although there were multiple SYN messages sent from both peers, since the same peers' sockets are being used in addressing both of the concurrent SYN messages.
Figure 29.
WireShark Screenshot
- 53 -
- 54 -
References
[1] [2] Bryan Ford, et al, Peer-to-Peer Communication Across Network Address Translators. J.L. Eppinger. TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem. reports-archive.adm.cs.cmu.edu, 2005. [3] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy. STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs).RFC 3489 (Proposed Standard), March 2003. [4] J. Rosenberg et al, Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN), Internet Draft, October 2008, link: http://tools.ietf.org/id/draft-ietf-behave-turn-11.txt [5] Paul Francis Saikat Guha. STUNT, Simple Traversal of UDP Through NATs and TCP too, link: http://nutss.gforge.cis.cornell.edu/stunt.php [6] [7] [8] [9] JXTA, Sun Microsystems, Java-based P2P Framework, link: http://www.jxta.org Netty Library, link: http://jboss.org/netty UPnP. Universal plug 'n' play group, link: http://www.upnp.org http://tools.ietf.org/html/draft-jennings-midcom-stun-results-02
[10] SA Baset and H Schulzrinne. An analysis of the skype peer-to-peer internet telephony protocol. Columbia University, New York, NY, 2004 [11] Kelaskar, M., et al A Study of Discovery Mechanisms for Peer-to-Peer Application. 2002 [12] Wikipedia, the free encyclopaedia, http://en.wikipedia.org [13] http://www.answers.com
- 55 -