Existing solution for streaming delivery

There are various solutions for streaming delivery using application-layer multicast. Some of them need a powerful streaming server to deliver the streams to each client, and these systems are usually provided by ISPs (Internet Service providers) or companies for charging.

The others do not use external servers but deliver the streaming by the user participating in the overlay network. The streaming source node handles most of the operations, including building the distribution delivery tree, forwarding each new coming client to an appropriate serving node, rebuilding the connections of some nodes in case of a serving node leaving, crash or failure due to software or hardware problems. Each function of these takes little times and may influence the quality of the system.

The method of live streaming delivery using application-layer multicast can be categorize into four classes. Following shows a representative work for each one that we have surveyed.

(1) StreamCast/OverCast [10, 11]: Figure 1-2 shows the architecture of

two-tiers. It use ISP’s proxy servers serve as the media servers to establish distribution delivery trees using the low layer routing algorithm built between every server’s routing table. It is expensive and these well-known proxy servers maybe easy to under attack.

(2) PeerCast [12, 13, 20]: a P2P architecture without any streaming server. The source handles the tree construction while peers joining, and tree reconstruction while peers leaves or failures. SN selection policy is based on random or locality policy by peer’s redirection. However, the policy may choose a SN with long distance between, even if finding a SN with very small hops between, it might still not guarantee the total delivery paths between the new coming node and the source are short. Currently, PeerCast is open-source and free to use.

(3) SplitStream [4]: A tree-based architecture but splits the streaming to N parties (strips called in the thesis), each part was delivered over one tree. Every node takes its role as a serving node in one tree, and a leaf node in the other N-1 trees. Each peer gives back to the network as much as bandwidth as it consumes, it is designed to overcome the unbalance forwarding load in single tree architecture. This method is used to reduce the influence of the node failures. The failure of any single node can only lead to the interruption of one tree over the architecture. However, the tree construction is complex and needs a streaming description method such as MDC (Multiple Description Coding) to identify each streaming part. Delay of each tree is not stable for real-time application. Figure 1-3 shows an example of multiple trees with seven nodes in logical view.

Figure 1-2 Two-tiers architecture

Figure 1-3 Multiple trees with seven nodes

(4) Improved Single-tree Approaches: Most of the Single-trees method are managed by the root, and they are good at delay, but sill have problems on the nodes leaves of failures. Zigzag [21] is a proposal from the University of Central Florida which addresses robustness problem of the single-tree architecture by splitting the role of the leader over two different entities, the head and the associate-head. Heads inherit all the administrative functions of the leader, except the responsibility of forwarding the data stream to others. Associate heads are picked between the non head peers of a

cluster and are delegated both the privilege to receive data from the higher layer and relay streams to their cluster-mates. In addition, all non-head peers of a cluster in a higher level can forward the streams to the associate-heads on the lower-level clusters.

Once their associate-head fails, the children can contact to their cluster head. Figure 1-4 illustrate the tree proposed on Zigzag. The improvements brought by these changes are the following (k is a constant value, k>3):

z Any peer cannot directly serve more than 6k-3 peers

z The worst-case number of peers that need to reconnect due to a crashed node is 6k-2

z Reconnecting is made easier in case of associate head failure, since the head is still alive and can pick a substitute associate head without burdening the server; if only the head fails , though, the data stream in the cluster is not disrupted and it’s possible to easily pick another head.

Figure 1-4 Zigzag’s Single tree

Multiple-source technology used in file-sharing environment may not appropriate for streaming multicasting. The drawback of multiple-source method are

(1) needs exchange massive messages for query the frames that the user lack of, (2) needs a method to avoid receiving the duplicated packets, (3) delay is not steady thus can not assure of real-time transmissions.

In this thesis we do not use mechanism similar to distributed hash table (DHT) such as Chord, or Content-Addressable Network (CAN) which are mostly used in recently peer-to-peer architecture. In the DHT method, most of these nodes in the tables do not actually request the content of the media from the source, but they have to relay the content for some nodes (once the software is executed and online, they are constructed into the DHT), this result in fairness problem. Another problem is that because our streaming data is transfer on single connection (for the infinity length streaming feature, it is not easy to index like a fix-length media file and obtain from multiple source), DHT is not appropriate for this need.