Table 1 - uploaded by Kiyohide Nakauchi
Content may be subject to copyright.
Source publication
Application-level multicast (ALM) is being increasingly recognized as a solution to support multipoint applications without the need for a network layer multicast protocol. Though several ALM systems have been proposed, all the multicast functions are independently developed and integrated into individual applications. However, we can find out the...
Similar publications
In this paper we investigate separation problems for classes of inequalities valid for the polytope associated with the Steiner tree packing problem, a problem that arises, e. g., in VLSI routing. The separation problem for Steiner partition inequalities is NP-hard in general. We show that it can be solved in polynomial time for those instances tha...
The rise of the Internet of things (IoT) poses massive scalability issues for location-based services. More particularly, location-aware publish and subscribe services are struggling to scale out the computation of matches between publications and subscriptions that continuously update their location. In this demonstration paper, we propose a novel...
![Figure 17: Execution time (in µsec) for the 1-phase algorithm of [1]...](profile/Sartaj-Sahni-2/publication/220331981/figure/fig1/AS:393931654221825@1470932033269/Execution-time-in-sec-for-the-1-phase-algorithm-of-1-and-our-1-phase-algorithm-for_Q320.jpg)
Efficient algorithms to construct multibit tries suitable for pipelined router-table applications are developed. We first enhance the 1-phase algorithm of Basu and Narlikar [1], obtaining a 1-phase algorithm that is 2.5 to 3 times as fast. Next, we develop 2--phase algorithms that not only guarantee to minimize the maximum per-stage memory but also...
Citations
... Although a few UDP-based reliable multicast protocols, such as NORM [3], have been developed, we note that IP multicast pushes all packets sent to a multicast address to all group members simultaneously, which can be problematic in scenarios where different members may have different resource constraints, consequently some may prefer to get specific subsets of the data first. A more commonly adopted approach is to build a middleware overlay to connect all participants in a distributed applications [27,43], avoiding the cost of × TCP connections by paying the complexity of setting up and maintaining the overlay, together with increased vulnerability due to the overlay failure. ...
Distributed dataset synchronization, or Sync in short, plays the role of a transport service in the Named Data Networking (NDN) architecture. A number of NDN Sync protocols have been developed over the last decade. In this paper, we conduct a systematic examination of NDN Sync protocol designs, identify common design patterns, reveal insights behind different design approaches, and collect lessons learned over the years. We show that (i) each Sync protocol can be characterized by its design decisions on three basic components - dataset namespace representation, namespace encoding for sharing, and change notification mechanism, and (ii) two or three types of choices have been observed for each design component. Through analysis and experimental evaluation, we reveal how different design choices influence the latency, reliability, overhead, and security of dataset synchronization. We also discuss the relationship between transport and application naming, the implications of namespace encoding for Sync group scalability, and the fundamental reason behind the need for Sync Interest multicast.
... HyperCast [16] provides socket-like Java APIs based on Delaunay Triangulation methodology [17]. RelayCast [18] is a middleware that can accommodate various applications with different cost criteria. ...
This paper presents a new middleware called ALMware for supporting development and performance evaluation of ALM (application layer multicast) protocols on real environments. To facilitate the development of ALM protocols, ALMware provides APIs which allow protocol developers to re-use typical operations used in existing ALM algorithms. Some additional APIs for transmitting video and audio between peers also mitigate the cost of writing application codes. Performance evaluation on real environments is also supported by ALMware. To prove the usefulness of ALMware, we have implemented well-known but different types of ALM protocols, ALMI, NARADA, NICE and OMNI, and conducted various kinds of performance evaluation experiments on PlanetLab, which clearly demonstrate the usability of ALMware. We believe that this is the first effort made to develop this kind of ALM supporting middleware.
... The authors in [10] present a middleware for unstructured application layer multicast only. They decompose the ALM component into several functional units, e.g., a metric esti-mator or a logic net to maintain and optimize the overlay network. ...
Recent efforts are made to construct a globally accessible group communication service by a simultaneous use of network and application layer multicast. Such hybrid approaches provide native multicast to group members wherever available, but relocate data distribution and duplication from the network to applications or gateways if needed. Such services require an abstract programming interface to allow for a transparent use by applications. The contributions of this paper are twofold. First, we explore the problem space of designing a protocol stack for hybrid group communication that covers structured P2P networks. Second, we propose a transparent API that encapsulates a middleware abstraction layer for implementing hybrid multicast, and allows for overlay-underlay agnostic programming.
... However, the process of electing super nodes is complicated, since unreliable endhosts work as rendezvous points. The multi-path tree is built by the multi-path routing protocol [25]. The redundant tree paths which are substituted when tree partition is caused by end-host's leave or failure are beforehand given to each end-host. ...
... The time interval of DVMRP routing message exchanges is 60 sec. The minimum gradient [25] in the multi-path routing protocol is 0.1. The routing metric in both protocols is a hop count from H1 on an overlay network. ...
... 2. Overlay Socket incorporates only single ALM technique [8] into the middleware on Socket API. In this paper and [25], we define the fundamental functions as functional units, and investigate to deal as the components with the individual algorithms proposed to each functional unit. RelayCast can meet the fundamental requirements from various applications by selecting the appropriate components. ...
SUMMARY Application-level multicast (ALM) is a novel technology for multipoint applications, such as large scale file distribution, video and audio streaming, and video conferenc- ing. Although many ALM mechanisms or algorithms have been proposed, all the multicast functions have been independently developed and integrated into individual applications. In such a situation, the development of ALM applications includes a lot of redundancy. Our goal is to improve the efficiency of developing ALM applications by reducing the development redundancy and to provide application developers with a middleware on which various ALM applications can be efficiently developed with min- imum efforts. To this end, we develop a functional unit oriented ALM middleware, namely RelayCast. RelayCast provides a min- imum but fundamental set of functionality as a functional unit, and constructs the basis on which additional and specific func- tions (i.e. codec, video capture, etc.) for each application are implemented. Some functional units contain several components with different algorithms, and RelayCast meets the requirements of various applications by choosing the appropriate component. In this paper, we propose RelayCast architecture, and present the implementation and experiments of a prototype.
... However, the process of electing super nodes is complicated, since unreliable end-hosts work as a rendezvous point. The multi-path tree is built by multi-pass routing protocol [25]. The redundant path to decrease repair time at tree partition caused by end-host's leave or failure, is beforehand given to each end-host. ...
... Each end-host restricts the maximum number of logical links to 5, and only the source end-host, H1, limits it to 3. The time interval of DVMRP routing message exchanges is 60 seconds. The [25] in multi-path routing protocol is 0.1. The routing metric in both protocols is a hop count from H1 on an overlay network. ...
... and[25]. Overlay Socket incorporates only single ALM technique[10] into the middleware on Socket API. ...
Application-level multicast (ALM) is a novel technology for multipoint applications, such as large scale file distribution, video and audio streaming, and video conference. Though several ALM systems have been proposed, all the multicast functions have been independently developed and integrated into individual applications. In such a situation, the development includes a lot of redundancy. Our goal is to develop RelayCast, the middleware which provides the common functions of ALM to eliminate the redundancy. RelayCast has some functional units which support fundamental and minimum functions respectively, and realizes one complete ALM system by cooperation of the units. The functional unit contains several components with different algorithms, and RelayCast meets the requirements of various applications by choosing the appropriate component. In this paper, we propose the RelayCast architecture, and present the implementation and experiment of a prototype.
... The Grid architecture emphasizes the identification and definition of protocols and services first to be followed by APIs and SDKs [18]. RelayCast suggests finding the common functions of ALM systems and incorporating them into a middleware [19]. ...
Multipoint distribution of data is a requirement for various types of applications in such areas as distance learning, multimedia conferencing and group collaboration. The economy of scale of multicast transport for multipoint distribution is not in doubt. The challenge is to develop technologies that will satisfy the varied requirements of these applications. However, IP Multicast has proven difficult to deploy on a large scale, and it can not satisfy the requirements of the plurality of multicast applications. Many multicast protocols have been proposed as alternatives to the open service model of IP Multicast. But no one set of protocols is capable of satisfying the various, often at odds, service requirements of multicast applications with heterogeneous multicast receivers. This paper proposes a middleware approach to provide core protocols, functions and interfaces, the combination of which can be selected and customized to meet the specific demands of various multicast-based applications. At its core, the proposed middleware solution will allow the routing of both datagrams and streams, using multiple channels and variants of the standard transport protocols, over clustered trees that scale well for large number of hosts in a multicast group.
... The majority of these proposed solutions (for example [27], [31] and Re-layCast [32]) typically involve having the members of a multicast group selforganize into an essentially random application level mesh topology. In order to construct distribution trees rooted at each possible traffic source, a traditional multicast routing algorithm, such as DVMRP [14], is used over the topology. ...
... HyperCast 2.0 is the Java implementation based on two methodologies, HyperCast [7] and Delaunay Triangulation [8] and provides socket-like Java APIs. RelayCast [10] is middleware to aim at adapting to various applications that require different metrics (bandwidth, delay or both), by component-based design and implementation. ...
In this paper, we propose new middleware written in Java based on an application level multicast protocol. This mid-dleware is designed for multi-party video communication systems such as video chatting systems where multiple video streams are multicast simultaneously on overlay net-works. The main contribution of our middleware is that it provides two types of QoS control mechanisms on overlay networks suitable for such an application. One is inter-stream QoS control, which controls the number of video streams on overlay links based on priority given to those streams. Another is intra-stream QoS control which pro-vides congestion control on each overlay link. Also, our middleware has a quick recovery mechanism against end hosts' failure/leave. Our experimental results have shown that our middleware could realize a video chatting applica-tion without causing serious delay and jitter, which is con-sidered inevitable in application level multicast protocols.
... This tool is famous for its distribution of live video in SIG-COMM2002 conference HyperCast [11] provides socket-like Java APIs based on Delaunay Triangulation methodology in Ref. [12]. RelayCast [13] is a middleware to aim at adapting to various applications that require different metrics. Our research group has also presented Java implementation of EMMA [14]. ...
In this paper, we propose a new middleware, which sup-ports implementation and evaluation of Application Layer Multicast (ALM in short) protocols in real environments. The middleware provides many functions by which it can largely reduce the time and effort required for ALM proto-col prototyping, performance evaluation and tuning. By us-ing those functionalities, we have easily implemented several well-known application layer protocols and successfully per-formed their performance comparison in real environments. As an example, we have implemented ALMI, NARADA, NICE and OMNI as ALM protocols, and compared their performance on PlanetLab. We believe that this is the first effort made to develop this kind of ALM supporting middle-ware.
A Distributed Concensus System (DCS) is a key component for a distributed system, maintaining and consenting over distributed state, as often required in distributed filesystems, cryptocurrencies and other applications. The prevalent mechanism to distribute the information needed to reach consensus in a DCS is through an iterative diffusion with the goal of distributing the (updated) information to at least the majority of DCS participants. Such diffusion is not just costly in maintaining the needed communication relations but also incurs latency in performing the diffusion itself. When looking closer at the goal of achieving the majority rule, however, one may wonder of the lack of multicast being used for achieving the same goal. This paper thus returns to the original intention of how to distribute information to a large set of users and outlines reasons for why multicast has not been widely used thus far. We evaluate the potential gain in doing so, based on an analytical model for the diffusion latency in an iterative diffusion DCS, bounded through empirical studies in an Ethereum system.
