1. Trang chủ
  2. » Giáo Dục - Đào Tạo

Topology optimization for DHT based application layer multicast

22 34 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 22
Dung lượng 701,98 KB

Nội dung

Topology Optimization For DHT - based Application Layer Multicast Nguyen Ngoc Anh Faculty of Information Technology Hanoi University of Engineering and Technology Vietnam National University, Hanoi Supervised by Doctor Nguyen Hoai Son A thesis submitted in fulfillment of the requirements for the degree of Master of Information Technology June, 2012 Table of Contents Abstract Acknowledgements iii Abstract 1 Introduction 1.1 Motivation 1.2 Objectives 1.3 Contributions 1.4 Thesis structure 2 5 6 10 10 10 11 12 12 13 14 15 16 Background 2.1 Multicast 2.1.1 Introduction 2.1.1.1 IP Multicast 2.1.1.2 Application Layer Multicast 2.1.2 Application layer multicast protocols 2.1.2.1 Application Domain 2.1.2.2 Deployment Level 2.1.2.3 Group Management 2.1.2.4 Routing Mechanism 2.2 DHT-based multicast 2.2.1 Introduction of P2P Networks 2.2.1.1 Unstructured P2P Network model 2.2.1.2 Hybrid P2P Network model 2.2.1.3 Structured P2P Network model 2.2.2 DHT-based structure P2P networks iv TABLE OF CONTENTS 2.3 v 2.2.2.1 Chord Network 2.2.2.2 Content Adressable Network 2.2.3 DHT-based multicast 2.2.3.1 CAN-based multicast 2.2.3.2 Chord-based multicast 2.2.3.3 Scribe 2.2.4 Topology optimization issues for DHT-based multicast Related works on topology optimization for DHT-based multicast 2.3.1 SplitStream 2.3.2 Capacity Aware Multicast based on Overlay Network - CAMChord 2.3.3 DHT-based lightweight broadcast algorithms in large-scale computing infrastructures Bandwidth Adaptive Multicast 3.1 Overview 3.1.1 Node identifier 3.1.2 Finger table 3.2 Network Construction 3.3 Multicast method over Simulations and Evaluations 4.1 Simulation description 4.2 Evaluation 4.2.1 The depth of multicast tree 4.2.2 Control Overhead Conclusions Chord : BAM Chord 18 20 22 22 24 25 26 26 26 27 28 31 31 32 34 35 36 38 38 38 38 40 42 Abstract In recent years, Distributed Hash Table (DHT) becomes active and ongoing area of research at a lot of universities and labs DHT has many advantages: Decentralization, scalability, fault tolerance, load balancing, data integrity, and performance, Those properties make DHTs are very suitable for deploying multicast services at application layer and in fact, DHT-based network such as CAN, Chord, Pastry, Tapestry, etc can be used to implement Internet-scale application layer multicast However, early DHT-based multicast systems are insufficient in addressing all of these issues: Heterogeneous node capacity, large- scale multicast and dynamic membership Moreover, in those system, when one node joins into system through an arbitrary way, some factors are not considered: node’s bandwidth, node’s positon on DHT network (i.e node identifiers),… thus, the multicast tree can be built inefficiently and not balance in structure The solution for assigning an appropriate number of child nodes to each node is far from optimal in term of bandwidth: If the number of child nodes is too high, low capacity node will be overloaded, therefore slows the entire session multicast down If the number of child nodes is too low, high capacity nodes will be used inefficiently In this thesis, we study the method to optimize topology for DHTbased multicast We propose a DHT- based bandwidth adaptive multicast system that forcus on host heterogeneity, scalibility, fault tolerate In our system, node’s bandwidth is firstly considered, result of this process is the basis for determining the level of the node and correlatively caculating node’s identify Level of a node is used to define maximum number of its child nodes As a result, in our model, each node is assigned an optimal numbers of child nodes to forward multicast data Thus, our method can make tradeoff between depth of the multicast tree and bandwidth of every node and take advandtages of DHTs in maintaining multicast tree in churn overlay System chosen for implementation and avaluation is Chord This model is called Bandwidth Adaptive Multicast over Chord: BAM-Chord Chapter Introduction Today, Internet continues to grow rapidly, many communication requirements that we must deal with Cause of the explosion in data communications, demand on transferring large volumes of data to many destination quickly increases To solve bandwidth problems, multicast is a effective solution As the most cost-effective way of delivering the same data to a multiple receivers at the same time, multicast is suited to a large number of applications as mobile Internet, e-commerce, content rich applications, and multi-media services: television broadcast, video conferencing The word "multicast" is typically used to refer to network layer multicast - IP multicast and was proposed about some decades ago However, IP multicast still has not been widely deployed because of various technical and administrational reasons The disadvantages of implementing multicast at the IP level has led to an interesting application-level multicast Application layer multicast refers to the implementation of multicast capability at the application layer instead of network layer A number of application-level multicast systems have been proposed that are built using structured peer-to-peer (p2p) overlays Originally, distribute hash table (DHTs) were developed with applications like peer-to-peer file sharing Recent years, there has been considerable interest in applying DHTs to overlay multicast applications since it has many advantages: Decentralization, Scalability, Fault tolerance, Load balancing, and performance, Those properties make DHTs are very suitable for deploying multicast services at application layer and in fact, DHT-based network such as CAN, Chord, Pastry, Tapestry, etc has been already used to implement Internet -scale applicastion layer muticast However, early DHT-based multicast systems are insufficient in addressing a number of technical issues: - Heterogeneous Node Capacity: Node Capacity refers to its CPU power, memory, and network bandwidth - Large Any-Source Multicast Groups: A multicast tree that is optimal for one source may be bad for another source The system should allow any group member to send multicast messages to other members The group should scale to a very large number of hosts - Dynamic membership: Members may join and leave at any time The system must be able to efficiently maintain the multicast tree Moreover, in those system, one node join into system through an arbitrary way, thus, the multicast tree can be built inefficiently and not balance in structure The solution for assigning an appropriate number of children to each node is far from optimal in term of bandwidth: If the number of children is too high, low capacity node will be overload, therefore slows the entire session multicast down If the number of children is too low, high capacity nodes will be used inefficiently In this thesis, we study the method to optimize topology for DHTbased multicast We propose a DHT- based bandwidth adaptive multicast system that forcus on host heterogeneity, scalibility, fault tolerate System chosen for implementation and avaluation is Chord, a DHTs representative We extend Chord to be more flexible and it is called BAMChord: Bandwidth Adaptive Multicast Chord Our method can make tradeoff between depth of the multicast tree and out-degree of every node and retain the advantages of a DHT network In the scope of this thesis,we propose a model for deploying multicast service over DHT-based network This thesis not only introduces the background of P2P network, DHT-based network, overall view of DHT-based multicast and related technical issues, but also makes the following contributions: - Proposes an improvement that can optimize network topology This makes multicast tree more balanced and node's bandwidth adaptation This - Proposes an algorithm to find an optimal position when node joins into multicast session - Proposes a improvement model that can address technical issues in earlier existing systems Chapter Background 2.1 Multicast Unicast is a basic type of transmission in which information is sent from only one source to only one destination In another words, Unicast transmission is between one-to-one nodes This type of transmission is used at almost network protocols: IP, TCP, UDP, HTTP, FTP,…However, when one sender sends the same data to many receivers, it is not effective to use unicast Broadcast is a type of transmission in which information is sent from just one source but is received by all destinations connected to the network This would mean that every time a node use broadcast transmission, all the other node will receive that information Fig 1: Type of transmissions Multicast is a very much different from Unicast and Multicast in definition and application as well It is a type of transmission or communication in which the information is sent by one source to a set of destination Many people think is an excellent transmission method for multimedia: Internet radio broadcast, television broadcast, video conferencing, stock market tickers, slide presentations, etc However, multicast is also suited to a large number of other applications: file transfers to multiple locations, dynamic web page updates, online gaming, news feeds, chatrooms, Multicast is the most efficient method of delivering the same data to multiple receivers at the same time Servers send only one data stream to reach any number of end-users Using unicast, a server would need to send out as many streams as there are receivers This increases the CPU load, bandwidth required to reach that audience Using multicast, there will only be a single copy of the data streamed across any links, therefore, can decrease bandwidth without upgrading links and routers Due to the increasing number of application such as videoconferencing, multi-party games, private chat rooms, web cache replication and database /directory replication…, and a lack of widely deployment of IP multicast in all IP-based networks, there has been interest in multicast protocols that can be supported without relying on the IP multicast infrastructure, and not depend on multicast-capable routers This is the so-called application-layer multicast (ALM) IP Multicast The type of communication between one sender and one receiver (a connection between a Web browser and a server) can be addressed by basic TCP/TP network However, there is an emerging class of applications require multi-point communications between one or more senders and several receivers in order to work well In this case, data is sent from a sender to the receivers asynchronously as needed IP Multicast is designed to solve this problem IP multicast is a method of sending Internet Protocol (IP) datagrams to a group of interested receivers in a single transmission In IP multicast, router has to be equipped with multicasting capabilities Router actively participate in multicast and has a very important role Routers make copies of packets as need and forward towards multicast receivers In this model, all interested host form a multicast group for communicating with each other through sending a message to multicast router using multicast group membership discovery protocol as: IGMP (IPv4) or MLD (IPv6) After joining to a multicast group, a host can receive all data that are sent for that belonging multicast group without knowing the source address IP muticast has all of advantages of multicast transmision However, important issues such as routing, group management, address allocation, authorization and security, quality of Service (QoS) and scalability are not addressed effectively, IP Multicast has not been widely deployed 2.2 Application Layer Multicast The concept of application level multicast is implementation of multicasting functionality at application layer instead of network layer As a result, the multicast-related functionalities are moved from routers to end-hosts The basic idea of application-layer multicast is shown in Figure 3b: S establishes unicast connections and send data to D1 and D2; In turn, D1, D2 delivers data to D3, D4 via unicast connection respectively a IP multicast b Application Layer Multicast Fig 2: A Comparison between Ip multicast and application-layer multicast In IP multicast, data packets are replicated at routers inside the network In ALM, data packets are replicated at end hosts Logically, the end-hosts form an overlay network, and the goal of ALM is to construct and maintain an overlay for data transmission Since IP Multicast is implemented by network routers and avoids multiple copies of the same multicast packet on the same link ALM is implemented by application end-host and can not avoid multiple copies of the same packet on the same link Thus, ALM is less efficient than network layer multicast However, compared to IP multicast, application level multicast has some advantages:  First, most proposed ALM models not require any special support from network routers, therefore, ALM can be widely deployed  Second, ALM is more easily deployment than IP multicast because ALM avoids issues related to inner-domain multicast  Third, in recent years, numbers of improvements in ALM technology overcome its weakness and ALM become a up-and coming solution, DHT-based multicast is an example 2.3 DHT-based multicast 2.3.1 DHT-based Network In recent years, due to the advantages of P2P networks, they have been widely used in many ares: Instant Messaging, File Sharing, Collaborative Community, IP Telephony, High Performance Computing - Grid Computing… the P2P networks have become a focus of research at almost every major university Structured P2P network is a scalable, efficient, completely decentralized and self-organizing, and load balanced model Each node stores information of O(logN) neighbors Routing algorithm allows it looking up any key with O(logN) hop time Because of the routing algorithm based on globally consistent hash function, a set of keys are distributed equally to the key space However, this P2P network model faces to some challengers such as: avoiding bottlenecks in particular nodes, adaptation to nodes joining or leaving Distributed Hash Table (DHT) system -a structured P2P network representative– with many advantages, is a perfectly solution to solve these chalenges, and efficiently tackles all disadvantages of unstructured P2P networks In this network model, nodes are organized in a structure of key space: Ring, d-dimensional coordinate space, …and link with other nodes in a pre-determined way: finger table, neighbor table Routing and searching process is based on key These features is very suitable for multicast Some well known DHTs are Chord, Pastry, Tapestry, and Content Addressable Network were introduced about the same time in 2001 Since then this area of research has been quite active We will discuss about DHT in the next section 2.3.2 Chord Network Chord was introduced in 2001 by Ion Stoica, Robert Morris, David Karger, Frans Kaashoek, and Hari Balakrishnan Chord protocol is one of the first typical DHT-based protocols, an infrastructure that map file identifiers onto node identifiers The Chord protocol specifies how new nodes join the system, how existing nodes leave the system, how to find the locations of keys, and how to recover from the failure of existing nodes, provide effcient routing and searching process Fig 4: A Chord ring with bit identifier Notice how the finger table is organized and how K54 is looked up following Chord's algorithm Chord use consistant hashing function to assigns each node and key an m-bit identifier An hash function such as SHA-1 A node’s identifier is chosen by hashing the node’s IP address, while a key identifier is produced by hashing the key The term “key” refers to both the original key and its identifiers Similarly, the term “node” will refer to both the node and its identifier under the hash function The identifier length must be large enough to make the probability of two nodes or keys hashing to the same identifier negligible In Chord, all node identifiers are arranged in an “identifier circle” and the circle cannot have more than 2m nodes, where m is the number of bits in the key/node identifiers Pairs (id, key) ranges from to m Figure shows an identifier circle with m=6 The use of consistent hashing tends to load balancing purpose: each node receives the same number of keys 2.3.3 Chord-based multicast A representative of flooding-based approach is Chord-based multicast.In Chord-based multicast, when a node wants to send multicast messages to a number of nodes in a continuous range (called multicast range) of a Chord ring, it will lookup its finger table and determine all nodes which belong to the multicast range It then specifies the multicast range that each node will be responsible for and sends a multicast message with each responsible multicast range to each node Receiving nodes similarly select nodes belonging to the multicast range that they are responsible for from the list of nodes in their finger table They then send multicast messaages with new multicast ranges to these nodes Fig 5: An example of Chord-based multicast method In this example, Node sends messages to all nodes in the Chord ring 2.4 Topology optimization issues for DHT-based multicast Generally, DHT-based application layer multicast schemes will optimize topology of DHT-based overlay network to send multicast messages effectively Therefore,nodes in these systems not need to maintain extra links to other nodes in the overlay network, except the links to neighbor nodes defined by a DHT algorithm DHT-based multicast also gets benefits from failure recovery algorithms which are implemented in most of DHT networks However, early DHT-based multicast designs are insufficient in addressing all of following issues:  Heterogeneous output bandwidth of nodes: Since the number of child nodes of a node in a multicast tree is decided based on the DHT algorithm without consideration of node’s bandwidth capacity, a node with low bandwidth may become a bottleneck if it is an internal node of a multicast tree In the opposite, a node with high bandwidth may be wasted if it is a leave node of multicast tree Thus, system can not utilize the bandwidth capacity of the node to deliver multicast messages  Dynamic membership: The optimization of multicast trees must be achieved even when member nodes join or leave at any time Moreover, all multicast systems in create a multicast tree or mesh, but have no way of limiting its depth This way, the data path for delivering the message to nodes that are very deepin the tree could become significantly large This could become an issue in a heterogenerous, dynamic environmen Chapter Bandwidth Adaptive Multicast over Chord : BAM Chord 3.1 Overview Consider a multicast group of n nodes,which forms an overlay network like Chord A node which ID is will send multicast messages to all nodes within this overlay network The goal of our system is to build a wide and balanced multicast tree based on the structure of the Chord overlay network even when nodes join or leave at anytime and the bandwidth capacity of nodes is heterogeneous We consider that the relative relation between nodes in a Chordbased multicast tree depends on the positions of nodes (i.e node IDs)in a Chord ring and the links between nodes (i.e entries of finger tables of nodes) Since the structure of a Chord ring is used mainly for multicast and message routing in the ring,it is not necessary to create node IDs randomly Furthermore, the links between nodes should be created such that it results a wide and balanced multicast tree Therefore,the main ideal of our BAM-Chord system is to create a virtual wide and balanced multicast tree on a Chord ring The higher level a node is,the more child nodes the node has Each node in the virtual multicast tree is assigned with a node ID and finger table of a node must contain all child nodes of the node in the virtual multicast tree Real nodes will be assigned to node positions in the virtual multicast tree to form a real multicast tree.The size (i.e the number of nodes) of the virtual multicast tree is large enough to include all nodes in a real multicast tree Each newly joining node will select its node ID from a number of candidate IDs corresponding to nodes in the virtual multicast tree In order to utilize effectively the bandwidth of nodes while not creating a bandwidth bottleneck in the tree, candidate IDs are selected such that the number of child nodes of each ID is not over the maximum number of nodes that the joining node can forward Here, the maximum number of nodes that a node can forward is roughly estimated based on the out bandwidth of a node, which is estimated based on some bandwidth estimation method or based on the setting of users By the use of a virtual multicast tree and the assignment of real nodes to the tree, our system can build a wide and balanced multicast tree on a Chord ring while using the bandwidth capacity of nodes effectively Our mechanism is done completely decentralized to avoid a single point of failure The detail of our system is given in the next subsection 3.1.1 Node identifier In our system, when a source node wants to send multicast data, it will create a virtual multicast tree on a Chord ring, which root node is the source node Each node of the tree is assigned with an ID belonging to the Chord ring The ID of the root node of the tree is the ID of the multicast source node in the Chord ring A node level i of a node is defined as the distance (i.e the length) from the root node to the node To determine the structure of virtual multicast tree, out degrees l0, l1, … ln of nodes at each node level are predefined in which l1> l2 … >ln n is the height of the virtual tree and is also predefined The out-degree of a node defines the number of child nodes of the node in the virtual multicast tree The size (i.e the number of nodes) of the virtual tree is When a source node starts a new multicast group, the node will estimate the number of nodes that may receive the multicast data It also calculates a set of out-degrees l0, l1, … ln due to out-bandwidth distribution of nodes and estimated size of the multicast group that the node wants to send The out-bandwidth distribution of nodes can be estimated based on some experiments Suppose that the size of the multicast group is estimated as N and the bandwidths of joining nodes will be outbw1, … outbwN is the bit rate of the multicast data stream The value of l0, l1, … ln can be calculate as follows  l0=[ outbws/br], outbws is the out bandwidth of the source node  l1=[ outbwx0 /br], x0=l0  l2=[ outbwx1/br], x1=l0+l0l1  …  Ln=[ outbwxn/br], xn= Here, [x] means the nearest integer of x Each node in a virtual multicast tree will be assigned with a node ID as follows  ID of level-0 node (i.e root node) is  IDs of level-1 nodes are [1+x0.2m/l0], where x0Є{0…l0-1} There are -l0 IDs at level -1  …  IDs of level-n nodes are [n+ x0.2m/l0+ x1.2m/l0l1+ xn-1.2m/l011…ln-1] (1) where xi Є {0…li-1}, i Є{1…n} There are l011…lt-1 IDs at level –t Fig : An example of CAM- Chord, neighbors of x N=[0 31], cx=3 3.1.2 Finger table In Chord-based multicast, entries of a finger table of a node take two roles Firstly, they are used to route a message to the next node, which is close to the destination node Secondly, they are used to determine nodes belonging to the node’s responsible multicast ranges, so that the node can forward multicast messages to these nodes In our BAM-Chord system, we create links between nodes for both message routing and multicasting Since each node joins to a position corresponding to a node in the virtual multicast tree, it is necessary to create links from the node to nodes corresponding to child nodes in the virtual tree However, not all of nodes in the virtual tree are associated with real nodes since there are join/leave nodes and our joining method is done in a decentralized manner Therefore, we also add redundant links to the finger table of each node Concretely, a level-t node which ID is idn will have four types of entries in its finger table Here, succ(x) means that the successor node of the IDx since a node of IDx may not exit  lt entries linking to lt child nodes of level lt-1: succ(idn+1), succ([idn+1+2m/ l011…lt-1lt]),…, succ([idn+1+(lt-1)2m/ l011…lt-1lt])  lt-1-1 entries linking to lt-1-1 nodes of level lt-1: succ([idn+1+2m/ l011…lt-1]),…, succ([idn+1+(lt-1-1)2m/ l011…lt-1])  l1-1 entries linking to l1-1 nodes of level  l0-1 entries linking to l0-1 nodes of level 1: succ([idn+2m/ l01]),…, succ([idn+(l0-1)2m/ l0]) Source S which ID is has l0 entries: 1, succ([1+2m/ l01]),…, succ([1+(l0-1)2m/ l0]) 3.2 Network Construction When a source node wants to send multicast data, it creates a virtual multicast tree as described in the previous section When a node x wants to receive multicast data from a source node, it firstly contacts to a bootstrap node to receive information about the source node It then contacts to the source node to get the information related to streaming bit rate br and virtual multicast tree including the set of out-degrees of nodes in the tree l011…ln Suppose that the out-bandwidth of the node is bw, then the node should join to a position which node level t has out-degree of lt and lt ≤bw/br It calculates a number of candidate IDs at different levels and chooses an ID from candidate IDs A joining node calculates a number of candidate IDs by generating a number of sets of randomly values x0, x1, x3, x4, …, xt-1, xi Є{0,…,li-1}, i Є{0,…,t-1} Each candidate ID is calculated from the set of x0, x1, x3, x4, …, xt-1 based on (1) as follows [i+ x02m/l0 + x12m/l0l1+ …+ xt-12m/ l0 l1 … lt-1] The node then contacts with a bootstrap node and sends a join probe message to each node responsible for each candidate ID by the use of conventional routing alogorithn of Chord If a candidate ID is not already used by any node, the successor node of that ID will send a reply message In the case there are a number of available candidates IDs, the joining node will select an ID randomly All candidate IDs corresponding to the level t may be hold by other node In that case, the node will select a number of other candidate IDs which level is smaller than $t$ and probe the existence of nodes at these positions again If a node can not find any position in the Chord ring, it will ask the source node to increase the height of the virtual multicast tree When the height of the virtual multicast tree increases by one from n to n+1, the number of nodes in the virtual multicast tree will increase by l0 l1 … ln-1 3.3 Multicast method In our system, when a source node sends multicast messages to nodes in the multicast group which is structured as a Chord ring, it will look up its finger table and specifies the multicast range that each node in the finger table will be responsible for If the IDs of nodes to be send are put in clockwise order as ID0, ID1, ID2,… IDk , the multicast range that the node with ID of IDi, ≤ i ≤ k-1, is responsible for will be from its ID IDi to the ID of the next node minus one (i.e IDi+1-1) It then sends multicast messages with responsible multicast range to each node in the finger table Assume that a node, which ID is IDx and out-degree is outdegx receives a multicast message with responsible multicast range of [IDx, IDy] It first lookups its finger table to find all nodes in its responsible multicast range Assume that the IDs of nodes in the multicast range are put in clockwise order as ID0, ID1, ID2,… IDk-1 If the number of these nodes k is smaller than or equal to the out-degree outdegx of the node, the node will select all these nodes to send the multicast message with new responsible multicast range If the number of these nodes k is bigger than the out-degree outdegx of the node, the node will choose the node with ID of ID0 and a number of nodes from ID1, ID2,… IDk to send the multicast message The number of nodes to be sent must not be over the out-degree of the node and selected nodes must have higher levels then unselected nodes Chapter Simulations and Evaluations 4.1 Simulation description To evaluate the effectiveness of our BAM-Chord system, we built a simulation program and compare our BAM-Chord method with Chordbased multicast and CAM-Chord method through some aspects: The depth of multicasttree or the path length from a source node to leaf nodes, the number of links that each node must maintain The simulation program is implemented with the following parameters: - The bit length of the ID space is 32 - The estimated size of the multicast group is 5000 nodes - The out-degrees of nodes are taken from [2 20] uniformly Node joins and leaves randomly based on Paretod istribution \cite{Distribution} during simulation time At each time step, there are a number of node join and leave After each time step, we analyze the topology of the multicast tree to get performance results 4.2 Evaluation 4.2.1 The depth of multicast tree Figure shows the average path length of Chord, CAM-Chord and BAM-Chord, ie the depth of multicast tree or the number of the nodes that can be reach by multicast tree from the source node to leaf node Y axis indicates percentage of nodes and X axis indicates path length, ie the number of hops from source to leaf nodes Fig 7: Average path length It can be seen from Fig 7, BAM-Chord achieve the best result regarding to average path length and maximum path length in comparison with Chord-based multicast and CAM-Chord In Chord-based multicast, since the multicast tree is un-balanced, only 40% of nodes have the path length up to hops and 80% of nodes have path length up to hops The maximum value of path length is 13 In CAM-Chord, the multicast tree is more balanced than Chord-based multicast Therefore, 60% of nodes have path length up hops while about 95% of nodes have path length up to hops The maximum value of path length is 10 In the case of BAMChord, 100% nodes have path length up to hops It is because our method has optimized the positions of nodes in the BAM-Chord such that nodes with high bandwidth will tend to be put at high level and vice versa Fig 8: Maximum path length Fig 9: Average path length 32 time steps Moreover, the goal to built multicast tree in BAM-Chord is to obtain a balanced, wide and bandwidth adaptive muticast tree Figure shows the maximum value of path length in multicast tree The smaller maximum path length means multicast tree is wider It is clear from Fig that the multicast tree in BAM-Chord is widest At any time step, maximum value of path length of BAM-Chord is hops while in CAM-Chord it is 10 hops and in Chord it is 13 hops 4.2.2 Control Overhead We evaluate control overhead based on the number of links to neighbor nodes of each node Each node must exchange information with their neighbor nodes and this message exchange will cause control overhead As shown in Fig \ref{fig:link_per_node}, in Chord-based multicast about 73\% of nodes have the number of neighbor nodes up to 14 and the maximum number of neighbor nodes is 27 Fig 10: Average link number per node Fig 11: Average link number per time In the case of our BAM-Chord each node must maintain links to a larger number of neighbor nodes About 55.5% of nodes have the number of neighbor nodes up to 25 and the maximum number of neighbor nodes per a node is 36 However, our method is still more effective than CAMChord In the case of CAM-Chord, about 70.7% of nodes have the number of neighbor nodes up to 30 and the maximum number of neighbor nodes per a node is 62 On average, the number of links per node is 13.6 in the case of Chord-based multicast, 24.1 in the case of BAM-Chord and 27.4 in the case of CAM-Chord Chapter Conclusions DHTs are suitable for deploying many application because of their advantages There has been considerable interest in applying DHTs to application-layer multicast DHTs have many advantages that good for multicast applications: decentralization, scalability, fault tolerance, load balancing, and good routing performances In fact, many DHT-based application layer multicast have been proposed However, early DHTbased multicast designs are insufficient in addressing all of following techinical issues: Heterogeneous Node Capacity, Dynamic membership, Effective bandwidth utilization In this thesis, we have proposed BAM-Chord system: Bandwidth Adaptive Multicast over Chord Our system builds a virtual multicast tree on a Chord ring and let nodes join to positions corresponding to nodes in virtual multicast tree Our system optimizes the topology of multicast tree in two novel points Firstly, by the use of virtual multicast tree, our system allows nodes to select appropriate positions on a BAM-Chord ring based on their output bandwidth such that a node with high output bandwidth will have a high level in the multicast tree Secondly,each node will maintain a number of links to its neighbor nodes such that a wide and balanced multicast tree is constructed The simulation results show the efficiency of BAM-Chord in respect of average path length, control overhead comparing with Chord-based multicast and CAM-Chord ... ring 2.4 Topology optimization issues for DHT- based multicast Generally, DHT- based application layer multicast schemes will optimize topology of DHT- based overlay network to send multicast messages... optimization issues for DHT- based multicast Related works on topology optimization for DHT- based multicast 2.3.1 SplitStream 2.3.2 Capacity Aware Multicast based. .. application- level multicast Application layer multicast refers to the implementation of multicast capability at the application layer instead of network layer A number of application- level multicast

Ngày đăng: 06/03/2020, 00:12

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN