**EVALUATION OF A TOPOLOGICAL DISTANCE ALGORITHM FOR CONSTRUCTION OF A P2P MULTICAST HYBRID OVERLAY TREE**

Sergej Alekseev1 and Jörg Schäfer2

1Department of Computer Science and Engineering, Computer Networks and

OS,Frankfurt University of Applied Sciences, Germany

2Department of Computer Science and Engineering, Distributed Systems,Frankfurt

University of Applied Sciences, Germany

**ABSTRACT**

In the last decade Peer to Peer technology has been thoroughly explored, becauseit overcomes many limitations compared to the traditional client server paradigm. Despite its advantages over a traditional approach, the ubiquitous availability of high speed, high bandwidth and low latency networks has supported the traditional client-server paradigm. Recently, however, the surge of streaming services has spawned renewed interest in Peer to Peer technologies. In addition, services like geolocation databases and browser technologies like Web-RTC make a hybrid approach attractive.

In this paper we present algorithms for the construction and the maintenance of a hybrid P2P overlay multicast tree based on topological distances. The essential idea of these algorithms is to build a multicast tree by choosing neighbours close to each other. The topological distances can be easily obtained by the browser using the geolocation API. Thus the implementation of algorithms can be done web-based in a

distributed manner.We present proofs of our algorithms as well as experimental results and evaluations.

**KEYWORDS**

Distributed algorithms, peer-to-peer (P2P), hybrid, overlay multicast tree, live streaming

**1.INTRODUCTION**

Peer-to-Peer (P2P) streaming has become more and more popular nowadays again after interest in general P2P has generally decreased following the initial enthusiasm in the late 90 – partially due to the ubiquitous and quick availability of high speed, high bandwidth and low latency networks which has supported the traditional client-server paradigm in the last decade. The central strength of P2P streaming systems is the capability of sharing resources so that larger (and more costly) servers can be replaced by smaller (and cheaper) computers. The P2P networks are build usually as a logical overlay network. The contribution of this paper is the construction and management of a P2P multicast tree streaming overlay where the nodes are physically close to each other in the underlying network.

In this paper we present two algorithms. The first is the joining algorithm that each node runs when it enters the system. The essential idea of the algorithm is to construct a multicast tree structure by finding a suitable neighbour in the overlay multicast tree and considering resources of peers. The second algorithm handles a host leaving that occurs gracefully or accidentally. For both algorithms we provide full mathematical proofs of minimality features. In addition, we present some experimental results and evaluations. And finally we conclude our paper with remarks on possible future work

**2.RELATED WORKS**

In recent years a number of P2P-based applications for stream delivery have been developed –e.g. Zattoo (http://zattoo.com), PPTP(http://www.pptv.com)and ctoshape (https://octoshape.com).

To improve the scalability and to optimise the usage of resources in the P2P network, several approaches have been proposed. In [1] various problems that arise due to the fact of P2P systems being highly dynamic and heterogenous are examined. It focuses especially on resilience mechanisms. In [2] and [6] an overview of application and network layer mechanisms are presented and the Mesh and Multiple-Tree P2P overlays are compared.

Several applications have been developed for various categories of mesh based P2P streaming.The authors of [8] and [7] present a hybrid approach for overlay construction and data delivery in an application-layer multicast. The HyPO approach in [7] optimizes the overlay by organizingpeers with similar bandwidth ranges in a geographical area into a mesh overlay. The ToMoapproach in [7] combines the strong points of a tree-based structure and a mesh-based data delivery to a two-layer hybrid overlay. The mTreebone of [9] is a collaborative tree-mesh design that leverages both mesh and tree structures. The key idea is to identify a set of stable nodes to construct a tree-based backbone with most of the data being pushed over this backbone. AnySee [5] is a mesh based P2P system in which resources are assigned based on their locality and delay.

In the present work we propose algorithms to construct a tree based multicast overlay based on topological distances.Similar approaches are described in [12], [3] and [14]. Already in [20] an architecture has been proposed for designing a global internet host distance estimation service.However, only relatively recently geographical information has become practically available from freely available geolocation databases [16], and therefore ideas which have been of theoretical value only have now become practical, see also [19]. The approach used in [12] and [3] organizes the peers into a hierarchy of clusters such that the neighboring peers are grouped into the same cluster. The overlay network is build from the cluster leaders to the other members recursively. In [14] a locality-aware P2P overlay construction method, called Nearcast, is proposed which builds an efficient overlay multicast tree by letting each peer node choose physically closer nodes as its logical children. Whereas there is rather comprehensive coverage of theoretical P2P algorithms and mathematical theorems on some of them like e.g. the T-Man protocol, see [4], up to our best knowledge, no minimality results have been proven for the overlay networks like the one described above but rather simulation results have been computed. In our work we propose algorithms which minimise the routing costs, usage of peer resources and end-to-end delay based on the topological location of peers. We provide a proof for the minimality of routing costs and provide evidence for keeping end-to-end delay low.

**3.PROPOSED APPROACH**

The concept of P2P multicasting [11], [12] is often applied to reduce the costs needed to deploy and to maintain services related to streaming of various content to many users, e.g. VoD, IPTV,radio, news channels, etc. In this paper, we propose an approach to the construction of a P2P overlay multicast tree with the goal to solve the following important problems:

Optimal routing between peers: Transmission at an overlay P2P-network might be inefficient, especially when the P2P-network is randomly constructed. This stems from the fact that the distance between peers physically or topologically is not considered by constructing the P2P-network.

• **Optimal usage of peer resources:** Peer resources include available bandwidth, processing power and storage space.

• **End-to-End delay:** The end-to-end delay is the latency, accumulated peer by peer, for the delivery of a data packet along the overlay path from the source host to an end host. To reduce this delay the height of the multicast tree should be kept small.

• **Handling of peer connections**: In practice the P2P-network need to deal with peers joining the network and peers that leave voluntarily or due to failure.

To overcome these problems, we propose algorithms for the construction and the management of an overlay P2P-network. Our algorithms use the topological distances between peers to guarantee the optimal routing costs. We define two data structures, a topological search tree and a P2P multicast tree (fig. 1). The search tree is used to find the nearest peer to be attached to the multicast overlay. This a special case of the Nearest Neighbour Search (NNS) or closest point search problem. Donald Knuth named this problem the post office problem [10]. The problem relates to an application of the assignment to the next post office. In our case the problem is reduced to the search in the tree and adapted for the search of an optimal usage of peer resources. The P2P multicast tree is used for the actual data transfer.

Figure 1.Topological search tree and p2p multicast tree structure.

**4.P2P OVERLAY MULTICAST TREE CONSTRUCTION AND MAINTENANCE**

**4.1.DEFINITIONS AND PRELIMINARIES**

To identify the topological position of hosts in a network, a unique H-dimensional coordinate C is assigned to each host. The idea to use the network coordinates is based on considerations from [13], [14] and [15]. In contrast to the algorithms presented therein, we use in our approach two data structures: the search tree Ts for searching the nearest neighbour according the topological position in the network and the multicast tree T to connect hosts to a P2P overlay multicast network.

The multicast overlay tree is defined as T = (V, E), where V is a set of vertices, which represent the end hosts, and E is a set of directed edges, which represent data delivery streams between the end hosts

The multicast overlay tree is defined as T = (V, E), where V is a set of vertices, which represent the end hosts, and E is a set of directed edges, which represent data delivery streams between the end hosts.

The search tree Ts is considered as an H-layered topological tree. According to the topology of the search tree Ts for each vertex v ∈ V the network coordinate C(v) is defined as follows:

The geographical information can be easily obtained from the freely available geolocation databases [16] by using the programming interfaces described in [17] and [18].

the hierarchical common network distance is D = 3.The last common coordinate LLC of two vertices is the last identical coordinate in the order of C0, C1, . . . Ci, formally:

**4.2. JOINING ALGORITHM**

To construct a multicast overlay tree the joining algorithm connects the hosts to an overlay network by analysing the geolocation information provided by the end hosts. The algorithm can be implemented in a centralized or a distributed manner. The pseudocode of the jo ining algorithm is shown in fig. 2.

Figure 2. The pseudocode of the JOIN algorithm

Figure 3 illustrates an example of the joining nodes to an existing overlay network. Initially the overlay multicast tree contains only a source host S and the search tree Ts includes the coordinates C(S) (fig. 3a). To attach the new node V1 the joining algorithm extends the search tree Ts by the adding the coordinates C(v1) and determines the nearest host by traversing the search tree Ts. The nearest neighbour can be easily found by a simple tree traversing in O(logn) time. The new host v1 is attached to the host S (fig. 3b). The fig. 3c illustrates the attaching of the host v2 to the multicast overlay tree.

Figure 3. An example of the algorithm JOIN execution

To show that the routing in the constructed multicast tree T is optimally organised, we assign to each edge e = {v0, v1} a topological distance value D(e) := D(v0, v1), that represents the routing costs between the vertices v0 and v1. It is easy to check that D satisfies all axioms of a metric which is important for the minimality results presented in the sequel (only the triangle inequality is non-trivial). The sum of all distances S(T) is defined as

and is a measure of the total routing costs in the tree in idealised units, see also section 5. The lower the value S(T) is, the less routing overhead is necessary to deliver the content to each vertex in the multicast tree. The topological distance can be thought of a proxy for the “real” distance measured as End-to-End-Delay or other QoS parameters. In the literature (see e.g. [21]) it has been argued, that the topological distance is a reasonable proxy in practice. As we will show in section 6 this is confirmed by our experimental results.

Now we show that our algorithm constructs a multicast tree T with minimal routing costs. In other words it is not possible to construct another multicast tree T1 with S(T1) < S(T ).

**Theorem 1:** The algorithm JOIN (fig. 2) constructs a tree T with the minimal S(T) value.

**Proof:** The correctness of the algorithm is proved by induction on the number of vertices in T.

**Base case**: T = ∅ or |T | = 1 are trivially minimal.

**Induction step:** Assume that S(T ) is minimal for n connected vertices. Let Vn+1 be the next vertex added to the multicast tree T and V ∈ T is the nearest neighbour of Vn+1 (fig. 4a). Let us show that S(T ) + D(V, Vn+1) is minimal.

Consider any multicast trees T t, where vn+1 not connected to v. We will see that there is no tree with S(T t) < S(T)

Figure 3. An example of the algorithm JOIN execution

But (8) contradicts inequality (7). Thus S(T) + D(v; vn+1) is minimal.

The algorithm JOIN (fig. 2) may construct different trees depending on selection of the nearest neighbour and the order the nodes joining, however the next theorem shows that S(T) is not affected.

Theorem 2. All trees constructed by the algorithm JOIN (fig. 2) have the same S(T) value.

Proof. Assume that algorithm JOIN (fig. 2) constructs two different trees T0 and T1 for the same set of vertices (end hosts) with S(T0) ≠S(T1). According to theorem 1 the value of S(T0) and the value of S(T1) are minimal. Since S(T0) ≠ S(T1), it follows that either S(T0) or S(T1) is not minimal. So the assumption must be incorrect.The algorithm JOIN (fig. 2) solves the routing costs problem, mentioned in the section 3.However the algorithm does not consider the usage of peer resources. As next we present an extension of the algorithm JOIN to solve the peer capacity problem.

**4.3. Management of Peer-Resources**

To manage the usage of peer resources the attribute resource capacity is assigned to each host in the network model. The resource capacity of an end host, denoted by R(υ), is a maximum number of outgoing links e € E, which can be served by the vertex v. The value R(υ) is calculated based on available bandwidth and other resources of the peer.

The pseudocode of the joining algorithm with the peer-resource management JOINR is shown in fig. 6 (we call υ in LCC(new, n) iff LCC(new; υ) = LCC(new, n)). To join a

Figure 6. The pseudocode of the JOINR algorithm

new node the algorithm JOINR finds the nearest neighbour n, similar to the algorithm JOIN (fig. 2). Instead to attaching the node directly to the nearest neighbour n found, the algorithm checks all existing hosts with the same topological distance as the vertex n, whether one of the vertices has enough resources to forward the data link to the new node. For that the last common coordinate LCC according the definition 5 (section 4.1) is calculated. If one appropriate host υ is found the new node is attached and the resource capacity attribute of the host v is updated.Otherwise the algorithm checks again all reachable hosts and verifies if the new node can be inserted between a host υ and any hosts connected to v with D(ne,; υ) ≤ D(υx, υ). Figure 7 illustrates an example of the algorithm JOINR execution. We define for this

Figure 7. An example of the algorithm JOINR execution

example the following condition In other words each host is able to maintain three outgoing links.

Initially the overlay multicast tree contains only a source host S and the search tree Ts includes the coordinates C(S) (fig. 7a).

To attach the new node v1 the algorithm JOINR adds the coordinates C(υ1) to the search tree Ts and determines the nearest host of υ 1 (fig. 7b). The host v1 is attached to the host S and the R(S) value is updated accordingly R(S) = 3 – 1 = 2.

Figure 7c illustrates the attaching of the host υ2. After updating the search tree Ts the algorithm JOINR checks all potential nearest neighbours, reachable from the LLC = RIPE. In order to find the LLC-value, it is enough to traverse backwards the search tree Ts from the vertex υ2 until the first branch. The potential nearest neighbours of υ2 are the hosts S and υ1, because D(S, υ2) = D(υ1; υ2) = 2. The host v2 is attached to the host S and the R(S) value is updated accordinglyR(S) = 2 – 1 = 1.

The attaching of the host v3 (fig. 7d) is similar to the previous step. The R(S) value is pdated to R(S) = 1 – 1 = 0. The host S can not maintain any further outgoing links. The last figure 7e illustrates the attaching of the host υ4. The nearest neighbour of υ4 is S. But R(S) = 0 and there are no other free potential neighbours with the same topological distance. The algorithm JOINR checks in this case all potential nearest neighbours v whether any hosts vx with D(υ, υ4) ≤ D(υ, υx) is connected to v. In our case:

So the algorithm JOINR inserts the host v4 between S and υ1 and updates the R(υ4) value accordingly R(υ4) = 3 – 1 = 2.

Proof. The algorithm JOINR consists of two parts, each one performing a loop on the potential nearest neighbours v of the host new.

The first part is reduced to the algorithm JOIN (fig. 2) and proved by induction (theorem 1) . If the first loop detects a nearest neighbour, then it must have at least one free outgoing link to attach a new vertex. So S(T) is minimal and R(T) is solved.

The second loop is only executed if all potential nearest neighbours have no capacity. According the precondition 9 each vertex must be able to serve at least one outgoing link. It follows that one of the potential nearest neighbours must be connected to a vertex x with the topological distance D(υ, x) _ D(υ, new) (fig. 8a). The vertex x is reconnected to the vertex new (fig. 8b). D(υ, x) = D(new, x), because v is one of the nearest neighbours of new. This step can be reduced to the algorithm JOIN (fig. 2) and proved by induction

Figure 8. Proof of the second loop

(theorem 1). So S(T) is minimal. According the precondition 9 the vertex new must be able to serve an outgoing link to x and R(T) is solved. In the next section we present an extension of the algorithm to reduce the end to end delay

**4.4. End-to-End Delay**

Figure 9. The pseudocode of the JOINRE algorithm

**4.5. Reconstruction Algorithm**

**5. EVALUATION METRICS**

As a basis for performance evaluation, the following raw-data and statistics about p2p applications are generated by our platform:

• Signaling and connection state events as described in [26]

• Geolocation and the available bandwidth information about peers

• Topological network coordinates according the definition in [27]

• The p2p overlay topology as a graph

• Sent/received and lost packets by each peer

• Round trip time (RTT) between two peers

• Delay and jitter time of received packets

Figure 10. The pseudocode of the reconstruction algorithm

Based on the collected data we are calculating the following metrics (explained in section 5.1) to evaluate the performance and other network characteristics of the WebRTC sessions:

• Link Stress (LS), Average Link Stress (ALS), and Topological Link Stress (TLSj) for each layer j

• Resource Usage (RU) and Topological Distance Sum S(T)

• Peer Degree (PD) and Peer Stretch (PS)

• Latency and End-to-End Delay (EED)

• Absolute/Relative Delay Penalty (ARDP or RDP)

• Absolute Peer Join and Reconfiguration Delay

• Total Sent/Received Bytes

• Packet Retransmission

**5.1. LINK STRESS, RESOURCE USAGE/TOPOLOGICAL DISTANCE SUM, PEER DEGREE AND PEER STRETCH**

**Link Stress, Average Link Stress, and Topological Link Stress**

**Peer Degree and Peer Stretch**

Peer Degree (PD) is the number of incoming and outgoing links. Peer Stretch (PS) is the ratio between the length of the data path from the server to a peer in our multicast tree to the length of the shortest path between them in the underlying network

**5.2. LATENCY, END-TO-END DELAY AND ABSOLUTE/RELATIVE DELAY PENALTY**

**End-to-End Delay**

In the literature, End-to-End Delay (EED) is the RTT between two neighbouring peers, see [14]. To avoid any confusion with the (topological) End-to-End Delay defined in eq. 10, we denote the (topological) End-to-End Delay by T-TED in the sequel, in particular in table 5 and figure 14.

**Latency**

Latency as defined in [23] is a metric measuring the end-to-end delay from the source to the receivers, as seen by the application. It includes the propagation and queuing delays of individual overlay links, as well as queueing delay and processing overhead at end systems along the path. We ideally wish to measure the latency of each individual data packet. However, issues associated with time synchronisation of hosts and clock skew adds noise to our measurements of one-way delay that is difficult to quantify. Therefore, we choose to estimate the round trip time (RTT). By RTT, we refer to the time it takes for a packet to move from the source to a recipient along a set of overlay links, and back to the source, using the same set of overlay links but in reverse order. Thus, the RTT of an overlay path S-A-R is the time taken to traverse S-A-R-A-S. The RTT measurements include all delays associated with one way latencies, and are ideally twice the end-to-end delay.

**Relative Delay Penalty**

Relative Delay Penalty (RDP) is defined as the ratio of the delay between the source and a receiver along the overlay tree to the unicast delay between them.

**Relative Delay Penalty**

Relative Delay Penalty (RDP) is defined as the ratio of the delay between the source and a receiver along the overlay tree to the unicast delay between them.

**5.3. TOTAL SENT/RECEIVED BYTES AND PACKET RETRANSMISSION**

These metrics just count the total number of bytes for send and received bytes and the total number of packet retransmissions.

**6. EXPERIMENTAL EVALUATIONS**

In this section, we report and discuss the results for the performance evaluation of the proposed approach using a topological tree (TT), in comparison with the Balanced Binary Tree (BBT) scheme. We choose BBT for comparison because it has the optimal broadcasting time of logarithmic order and many approaches and applications are based on th is scheme

Figure 11. The platform architecture

We have implemented aWebRTC [29] based platform for testing and monitoring p2p broadcasting algorithms. The platform provides an WebRTC based interface for implementing p2p algorithms and a monitoring interface to collect performance information. Figure 11 shows the system architecture of our platform deployment. Referring to this figure, each end system contains of a device with a WebRTC capable browser. The p2p algorithm is running on the central server. The end hosts initialise the join process by loading a web page with a video element and submits the topological coordinate, calculated via HTML5 Geolocation Browser API [30], to the central data base. The browser sends a JOIN-request to the central server, establishes a peer connection and relays streams. Each host sends the performance statistics to the monitor asynchronously. The monitor is responsible for logging the performance information of the joined hosts as mentioned in section 5.

We executed many experiment with our cooperation partner on Vietnamese-German University (VGU), which covers two continents, several subnetworks in the different cities in Germany and Vietnam. Each experiment consists of the broadcasting a video stream and a randomly organized joining process. The duration of each experiment is three minutes. The number of hosts was increased from 10 to 100 hosts.

From the all experiments, we present a selected experiment of a small size in detail, which includes 7 hosts from Germany and 8 hosts from Vietnam. The collected and calculated statistics of this experiment are transferable to the experiments with the larger number of hosts and the derived trends are very similar. The figure 12 represents the balanced binary tree and the figure 13 the topological broadcast tree with the corresponding search tree according our aproach. The collected performance statistics for balanced binary and topological broadcast tree are listed in the tables 1 and 2 accordantly.

Figure 12. The balanced binary tree with 15 nodes

Figure 13. The topological tree with 15 nodes and the corresponding search tree

**6.1. METRICS**

**Link Stress**

We cannot directly measure the link stress as it is impossible to capture the data at the source. However the link stress (per message, compare remark in section 5.1) can be estimated by calculating the ratio of all packets over the max number of packets going over a link of a certain level – ignoring the (negligible) number of lost packets, see table 2. The result is depicted in table 3. As one can see from the figures, the link stress in the case of the balanced binary tree is particularly high for the level 6 and 4 links corresponding to continent and national links, namely 6.22 and 1.94. Our on topological distance based algorithm measures show a link stress of one by construction. Henceforth, also the average link stress ALS is much higher (4.12) than in the optimal case, see table 4. This corresponds to the S(T) which is 29 Vs 67 and is indeed smaller for our algorithm as it should be.

Table 3. Link Stress

**Resource Usage**

As a consequence, the resource usage RU of our algorithm is much smaller than the resource usage of the Balanced Binary Tree Algorithm, see table 4. The Normalized Resource Usage of our algorithm is close to the optimal one, whereas the Normalized Resource Usage of the Balanced Binary Tree Algorithm exceeds the one of the DVMRP by a factor of 30, see as well table 4. If one compares S(T) and RU, one deducts that RU magnifies the lesser efficiency of

BBT vs. TT compared to S(T). This is seemingly due to the effect of the higher link stress amplifying the delay penalties of the intercontinental links.

Table 4. Aggregated Performance Measures

**Peer Degree and Peer Stretch**

Peer Degree (PD) of both algorithms is mostly identical. The balanced binary tree algorithm has by definition one incoming and a maximum two outgoing links. In the topological algorithm we defined for all nodes the R(v) = 2 (maximum number of outgoing links) for the better comparison. However, the topological tree has a node of just one outgoing link. The Peer Stretch (PS) of the Balanced Binary Tree in comparison to our algorithm has the lower value: PS(BBT) = 3, whereas PS(TPT) = 5. The balanced binary tree has always the optimal peer stretch by definition. But the multicast tree should not have small stretch to keep the end-to-end delay short. On the contrary, our measurements show that this is counterproductive.

**Delays**

The end to end delays (ADPs) are depicted in table 5 and figure 14 for 8 destination nodes. As one can see from the numbers, the delays for our algorithm are less than half of that of the Balanced Binary Tree Algorithm. The delays are also more predictable as the standard deviation shows4. The T-EED is less for our algorithm compared to BBT.

Table 5. Delays in Milliseconds and T-EED

**Messages Sent**

As depicted in table 4 we send roughly the same amount of messages (677517 and 662746 messages resp.) in both scenarios.

Figure 14. End-to-End Delays and T-EED for Destination Nodes

**7. CONCLUSION**

In this paper we presented a novel multicast tree construction and maintenance approach based on the topological network coordinates of the end hosts. The algorithms presented in this paper were developed to achieve the following desirable properties:

• Minimal routing overhead in the underlying network

• Optimal resource management of the hosts

• Short end-to-end delay

We evaluated our approach theoretically and by execution several experiments in the real network. Compared to the balanced binary trees our approach improves significantly the performance metrics of a multicast overlay tree. Our future work will concentrate on collecting, analysing further performance data in a real environment and improving our algorithms.

**ACKNOWLEDGEMENTS**

The authors would like to thank Nhu Tran Quang from Vietnamese-German University for supporting our experiments and Johannes Kinzig from Frankfurt University of Applied Sciences for the support in preparation of statistics.

**REFERENCES**

[1] Abboud, O., Pussep, K., Kovacevic, A., Mohr, K., Kaune, S., Steinmetz, R., Enabling Resilient P2P Video Streaming, Multimedia Systems, Vol. 17, No. 3, p. 177-197, June 2011

[2] Jurca, D., Chakareski, J.,Wagner, J., Frossard, P., Enabling Adaptive Video Streaming in P2P Systems, IEEE Communications Magazine, p. 108-114, June 2007

[3] Tran, D. A., Hua, K., Do, T., ZIGZAG: An Effcient Peer-to-Peer Scheme for Media Streaming, Proc. of IEEE INFOCOM, Vol.2, pp.1283-1292, 2003

[4] Márk Jelasity and Ozalp Babaoglu, T-Man: Gossip-based overlay topology management, 3rd Int.Workshop on Engineering Self-Organising Applications (ESOA’05), Springer-Verlag, pp. 1-15, 2005

[5] X. Liao, H. Jin, Y. Liu, L. M. Ni, D. Deng., AnySee: Peer-to-peer live streaming. In Proceedings of IEEE International Conference on Computer Communications, Barcelona, Spain, 2006

[6] Magharei, N., Rejaie, R., Yang G., Mesh or Multiple-Tree: A Comparative Study of Live P2P Streaming Approaches, 26th IEEE International Conference on Computer Communications-INFOCOM, pp. 1424- 1432, 2007

[7] H. Byun and M. Lee, HyPO: A Peer-to-Peer based Hybrid Overlay Structure, IEEE ICACT 2009,Feb. 2009

[8] Awiphan, S., Zhou Su, Katto, J., Two-layer Mesh/Tree Overlay Structure for Live Video Streaming in P2P Networks, proc. 7th IEEE Consumer Communications and Networking Conference (CCNC), pp. 1-5, 2010

[9] F.,Wang, Y., Xiong, and J., Liu, mTreebone: A Collaborative Tree-Mesh Overlay Network for Multicast Video Streaming, IEEE Transactions on Parallel and Distributed Systems, Vol. 21, No. 3, pp. 379-392, March 2010

[10] Donald Knuth, The Art of Computer Programming, Addison-Wesley, Vol. 3,1973

[11] Zhang, X.Y., Zhang, Q., Zhang, Z., Song, G., Zhu, W., A Construction of Locality-aware Overlay Network: mOverlay and its Performance, IEEE Journal on Selected Areas in Communications, pp. 18-28, 2004 [12] Banerjee, S., Bhattacharjee, B. Kommareddy, C., Scalable application layer multicast, Proc. ACM SIGCOMM Conf., ACM Press, New York, 2002

[13] Abboud, O., Kovacevic, A., Graffi, K., Pussep, K., Steinmetz, R., Underlay Awareness in P2P Systems: Techniques and Challenges, IEEE International Parallel and Distributed Processing Symposium, 2009

[14] Xuping Tu, Hai Jin, Xiaofei Liao, and Jiannong Cao, Nearcast: A locality-aware P2P live streaming approach for distance education. ACM Transactions on Internet Technology, Vol. 8 – Issue 2, 2008

[15] T. S. Eugene Ng, Hui Zhang, Predicting internet network distance with coordinates-based approaches. Proc. of IEEE INFOCOM, New York, Vol. 1, pp. 170–179, 2001

[16] James A. Muir and Paul C. Van Oorschot, Internet geolocation: Evasion and counterevasion, Journal ACM Computing Surveys, Vol. 42 – Issue 1, No. 4, December 2009

[17] Editor: Andrei Popescu, Geolocation API Specification, W3C, 22 December 2008

[18] Editor: Philip Olson, PHP Manual – Geo IP Location, The PHP Documentation Group,2014,http://php.net/manual/en/book.geoip.php

[19] Chao Dai, Yong Jiang, Shu-Tao Xia, Hai-Tao Zheng, and Laizhong Cui. A traffic localization strategy for peer-to-peer live streaming. In 2013 IEEE Symposium on Computers and Communications, ISCC2013, Split, Croatia, 7-10 July, 2013, pages 495–501, 2013

[20] Paul Francis, Sugih Jamin, Vern Paxson, Lixia Zhang, Daniel F. Gryniewicz, and Yixin Jin. An architecture for a global internet host distance estimation service, Proceedings of IEEE INFOCOM, 1999

[21] Ethan Katz-bassett, John P. John, Arvind Krishnamurthy, David Wetherall, Thomas Anderson, and Yatin Chawathe. Towards IP Geolocation Using Delay and Topology Measurements, IMC, 2006

[22] Y. H. Chu, S. G. Rao, S. Seshan, and H. Zhang, A case for end system multicast, in Proc. of ACM SIGMETRICS, 2000

[23] Y. H. Chu, S. G. Rao, S. Seshan, and H. Zhang, Enabling conferencing applications on the Internet using an overlay multicast architecture, In Proceedings of ACM SIGCOMM, p55-67, 2001

[24] W. Wang, D. Helder, S. Jamin, and L. Zhang, Overlay Optimizations for End-host Multicast, Networked Group Communications, 2002

[25] Wenjie Wang and Cheng Jin and Sugih Jamin, Network Overlay Construction under Limited End-to- End Addressability, In Proc. of IEEE INFOCOM 05, 2004

[26] S. Alekseev, C. von Harscher and M. Schindler, Finite State Machine based Flow Analysis for WebRTC Aplications, Fourth International Conference on Innovative Computing Technology (IEEE

INTECH), University of Bedfordshire, Luton, UK, 2014

[27] S. Alekseev, J. Schäfer, A New Algorithm for Construction of a P2P Multicast Hybrid Overlay Tree Based on Topological Distances, The Seventh International Conference on Networks & Communications (NeCoM 2015), Zürich, Switzerland, 2016

[28] Miguel Castro, Michael B. Jones, Anne-Marie Kermarrec, Antony Rowstron, Marvin Theimer, Helen Wang and AlecWolman, An Evaluation of Scalable Application-Level Multicast Built Using Peer-to-

Peer Overlays, Infocom’03, 2003

[29] Adam Bergkvist, Daniel C. Burnett, Cullen Jennings, Anant Narayanan, WebRTC 1.0: RealReal-time Communication Between Browsers, W3C Working Draft 10 February 2015 https://www.w3.org/TR/webrtc/

[30] Andrei Popescu, Google, Inc, Geolocation API Specification, W3C Editors Draft 11 July 2014 http://dev.w3.org/geo/api/spec-source.html

%d bloggers like this: