T. Abdelzaher, A. Shaikh, F. Jahanian and K. G. Shin. "RTCAST: Lightweight Multicast for Real-Time Process Groups". Best Student Paper Award Winner, The Second IEEE Real-time Technology and Applications Symposium (June 1996).  Home/Search   Document Details and Download   Summary   Related Articles   Check

....to achieve active fault tolerance, database replication [7, 8, 9, 10] resource allocation and load balancing [11] are the common uses of a GCS. A real time GCS that provides the membership service and reliable broadcast communication to the application has also drawn attention of the researchers [12]. The aim of our ongoing project is to investigate ecient and scalable real time GCS. We propose a scalable ring protocol that provides fault tolerance to the application in the form This work was partly supported by Turkish Science and Research Council (TUBITAK) of Turkey and CNRS (Centre ....

T. Abdelzaher et all, RTCAST: Lightweight Multicast for Real-Time Process Groups, IEEE Real-Time Technology and Applications Symposium, June 1996.

....network. There are two approaches that have been used in choosing such an abstraction for broadcast protocols. One approach is to build upon the specific physical properties of the network. For example, there are several broadcast protocols that attain very high reliability for Ethernet networks [16] or redundant Ethernets [2, 5, 7] Such protocols can be very efficient in terms of the chosen metrics because one can leverage off of the particularities of the network. On the other hand, such protocols are not very portable, since they depend so strongly on the physical properties of the ....

T. Abdelzaher, A. Shaikh, F. Jahanian and K. Shin. RTCAST: Lightweightmulticast for realtime process groups. In Proceedings of the Second IEEE Real-Time Technology and Applications Symposium,1996,pp.250--259.

....even in the presence of joins and leaves. Atom exhibits constant message delivery latency in the absence of failures, even during periods when participants join or leave; this is in contrast to previous algorithms solving similar problems in the context of view oriented group communication, e.g. [1, 9]. When failures occur, Atom s latency bound is linear in the number of failures that actually occur; it does not depend on the number of potential failures, nor on the number of joins and leaves that occur. A key di#culty for an algorithm solving DAB is that when a process fails, the network does ....

....pioneered by Isis [4] Our service resembles those provided by GCSs; although we do not export membership to the application, it is computed and would be easy to export. GCSs, including those designed for synchronous systems and real time applications (e.g. Cristian s [9] xAMp [18] and RTCAST [1]) generally run a group membership protocol every time a process joins or leaves, and therefore delay message delivery to all processes when joins or leaves occur. Cristian s service exhibits constant latency only in periods in which no joins or failures occur; latency during periods with ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for real-time process groups. In IEEE Real-Time Technology and Apps. Symp. (RTAS), Jun 1996.

....even in the presence of joins and leaves. Atom exhibits constant message delivery latency in the absence of failures, even during periods when participants join or leave; this is in contrast to previous algorithms solving similar problems in the context of view oriented group communication, e.g. [1, 9]. When failures occur, Atom s latency bound is linear in the number of failures that actually occur; it does not depend on the number of potential failures, nor on the number of joins and leaves that occur. A key diculty for an algorithm solving DAB is that when a process fails, the network does ....

....group communication systems; although we do not export membership to the application, it is computed, and would be easy to export. View oriented group communication systems, including systems designed for synchronous systems and real time applications (e.g. Cristian s [9] xAMp [25] and RTCAST [1]) generally run a group membership protocol every time a process joins or leaves, and therefore delay message delivery to all processes when joins or leaves occur. Cristian s system uses an atomic broadcast primitive to agree upon group membership. Since, unlike CUP, the atomic broadcast service ....

[Article contains additional citation context not shown here]

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for realtime process groups. In IEEE Real-Time Technology and Applications Symposium (RTAS), June 1996.

....such as the type of failures it is designed to tolerate. This is especially true for multicast, which have been the basis for a large number of group communication services with varying semantics, including Isis [4] Horus [13] Transis [2] Totem [12] Consul [11] xAMP [14] and RTcast [1]. Often, each is different because it is oriented towards a particular type of application or a given execution environment. Our thesis is that the use of highly configurable software can make it easier to construct applications by simplifying the process of building custom middleware services ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for real-time process groups. In Proceedings of the IEEE Real-Time Technology and Applications Symposium, pages 250--259, Jun 1996.

....this paper) is also something that has been used by other researchers [23, 19, 25] However, they were used in a different perspective not related to real time and the handling of timing failures. Having group members that exclude themselves from the group upon failure detection is also used in [1]. However, they do not use a hierarchical structure for groups and the excluding members do so by crashing. Another difference is that in our case it is possible to reach an agreement before making the decision to leave or not the group. 4. Group management and timing failures As we explained ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for real-time process groups. In Proceedings of Real-Time Technology and Applications Symposium, Boston, MA, June 1996. IEEE.

....to achieve active fault tolerance, database replication [3, 15, 9, 7] resource allocation and load balancing [10] are the common uses of a GCS. A real time GCS that provides the membership service and reliable broadcast communication to the application has also drawn attention of the researchers [1]. The aim of our ongoing project is to investigate ecient and scalable real time GCS. We propose a scalable ring protocol that provides fault tolerance to the application in 1 This work is being supported by Turkish Science and Research Council (TUBITAK) of Turkey and CNRS (Centre National de ....

T. Abdelzaher et all, RTCAST: Lightweight Multicast for Real-Time Process Groups, IEEE Real-Time Technology and Applications Symposium, June 1996.

....are provided to support Atomic Broadcast. When a node receives a corrupt message it will destroy the message tail which will prevent any node from receiving this message. The sender will also notice this and resend the message. Additional examples of Atomic Broadcast solutions can be found in [ASJS96] and [LS96] 2.3 Membership Agreement Membership Agreement is used to achieve a consistent view of the current membership of a group of processors. This is important for example when a part of a distributed application loses its membership due to a failure. Via the membership agreement correct ....

....of a group of processors. This is important for example when a part of a distributed application loses its membership due to a failure. Via the membership agreement correct processors may then adapt themselves to the situation. Much research has been done on Membership Agreement, for example [ASJS96, Cri91, RB93, KGR91] and DACAPO which recommends a two level membership; one for the correct nodes and one for a user defined application membership [LS96] 2.4 Redundancy management 2.4.1 Replica Determinism One major problem with replicated processes is to ensure Replica Determinism i.e. to ensure that all ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: lightweight multicast for real-time process groups. In Proc. of IEEE Real-time technology and Applications Symposium, Boston, 1996.

....subsequent time intervals of length x a new failure occurs. In practice, we do not expect sequences of failures to occur very often. Thus, the expected delay of our algorithm is very low, and it is very close to the delay 1 achieved when no process fail. This is superior to previous results (see [2]) which introduced linear latency regardless of the number of failures. Unlike most group communication systems providing similar services (e.g. 10, 21, 6] in our algorithm processes can join and leave without introducing delays to communication between active participants. It was challenging ....

....when joins occur without failure, while not compromising consistency if failures occur near the time of a join. 1.1 Related work Dynamic atomic broadcast is provided by several group communication systems. Most of these do not address QoS issues. The only exception that we are aware of is RTCAST [2]. RTCAST achieves a latency bound which is linear in the number of processes, regardless of the number of failures. Moreover, the failure model assumed in RTCAST is weaker than the one we assume. There, it is assumed that if a process p fails, and a correct process q receives, from the network, ....

[Article contains additional citation context not shown here]

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for realtime process groups. In IEEE Real-Time Technology and Applications Symposium (RTAS), June 1996.

....using the algorithms of [KD96, FV97] which implement Atomic Broadcast atop group communication systems providing totally ordered multicast. Several group communication systems provide totally ordered multicast; most do not address QoS issues. The only exception that we are aware of is RTCAST [ASJS96]. RTCAST assumes a stronger failure model than we do in this paper, and does not work with our failure 4 ZIV BAR JOSEPH, IDIT KEIDAR, TAL ANKER, NANCY LYNCH model. Furthermore, RTCAST achieves a latency bound which is linear in the number of processes, and not constant as we do (cf. Section 7) ....

....and renegotiation into account when analyzing the cost of the normal operation of the algorithm. 16 ZIV BAR JOSEPH, IDIT KEIDAR, TAL ANKER, NANCY LYNCH 7. Related Work The only previous work that we are aware of addressing QoS guarantees of totally ordered multicast primitives is RTCAST [ASJS96]. The failure model assumed in RTCAST is weaker than the one we assume. There, it is assumed that if a process p fails, and a correct process q receives, from the network, some message m sent by q before its failure, then every other correct process will receive m as well. In contrast, we allow ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for real-time process groups. In IEEE Real-Time Technology and Applications Symposium (RTAS), June 1996.

....the previous solution. To put Wombat s goals and performance in perspective, we briefly discuss the history of group membership protocols and the needs of today s cluster applications. 1. 1 Group Membership In the last decade, a large body of work on group membership problem has been published [1, 2, 3, 4, 5, 6, 8, 9, 13, 14, 16, 17]. All of these papers discuss solutions for the group membership problem, but not all of them have the same goals or provide the same guarantees. Other papers discuss this range of goals and try categorize these protocols [11, 12] Some of the discussion from [12] is borrowed here, to help place ....

Tarek Abdelzaher, Anees Shaikh, Farnam Jahanian, and Kang Shin. Rtcast: Lightweight multicast for real-time process groups. In In Proceedings of the IEEE Real-Time Technology and Applications Symposium, pages 250--259, June 1996.

....their monolithic counterparts. While a number of systems have explored this design space with respect to standard communication protocols, fault tolerance, and security [BHSC98, Hay98, HP91, RBM96] only a few have attempted to combine modularity with real time guarantees [SBS93, SVK97, TMR96, ASJS96] This is not surprising given the inherent tension between the two: ensuring predictable and timely execution requires careful control over virtually all aspects of a system s behavior, while a major rationale for providing configurability is, in essence, to facilitate construction of multiple ....

....control applications such as robotics and sensor based systems. Both the port based approach and the intended application domain are different from our work, which makes the challenges of providing real time guarantees in that system quite different than in RTD channels. CORDS [TMR96] and Armada [ASJS96, ABD 99] have adopted principles from the x kernel to add coarse grain modularity and a limited degree of configurability to real time systems. Both of these approaches allow a real time system to be constructed as a stack of real time services such as the real time group communication ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for realtime process groups. In Proceedings of the IEEE Real-Time Technology and Applications Symposium, pages 250--259, Jun 1996.

....of interest in mind, there are two general approaches one might approach designing a broadcast protocol. One approach would be to build upon the specific physical properties of the network. For example, there are several broadcast protocols that attain very high reliability for Ethernet networks [16] or redundant Ethernets [2, 5, 7] Such a protocol can be very efficient in terms of the chosen metrics because one can leverage off of the particularities of the network. On the other hand, such a protocol is not very portable, since it depends so much on the physical properties of the network. ....

T. Abdelzaher and A. Shaikh and F. Jahanian and K. Shin. RTCAST: Lightweight multicast for real-time process groups. In Proceedings of the Second IEEE Real-Time Technology and Applications Symposium, 1996, pp.250--259.

....in many application areas. For example, safety critical systems usually require hard guarantees on system response time to avoid catastrophe, while multimedia applications perform better with at least soft guarantees. Numerous different types of real time services and systems have been developed [2, 3, 8, 9, 14, 20]. However, most such systems are targeted for specific applications, which makes them rigid and unable to accommodate the different requirements of a variety of application types. This is especially true for real time communication services found in distributed systems, where applications often ....

....including Chimera [18] Delta 4 [14] HARTS [10] Mars [8] MK [16, 19] RTMach [20] and TTP [9] While suitable for their target application areas, the lack of support for configurability and customization in such systems typically limits their applicability to new areas. Two exceptions are [2] and [19] which have adopted principles from the x kernel to add coarse grain modularity and a limited degree of configurability to certain real time communication services. Real time channel abstractions similar to the one described in section 3 have been developed elsewhere as well. In some ....

[Article contains additional citation context not shown here]

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for real-time process groups. In Proceedings of the IEEE Real-Time Technology and Applications Symposium, pages 250--259, Jun 1996.

....In the present implementation, the number and identities of the machines which run SoftBus is stored in a static configuration file. It is reasonably straightforward to extend this architecture to allow new machines to subscribe to the SoftBus dynamically using a group membership service such as [25, 6, 2]. 3.4 Data Agent The data agent abstracts away remote communication between sensors, actuators, and controllers. When an interface module of some component has data to send to another the data agent first queries the registrar for information about the target component. If it is a remote one, ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for real-time process groups. In IEEE Real-Time Technology and Applications Symposium, Boston, Massachusetts, June 1996.

....always be used by the scheduler. The real time community has recognized that many functions may 55 This work was done cooperatively with T. F. Abdelzaher. Further details of the QoS Negotiation protocol, including its incorporation into middleware services called RTPOOL, are provided in [1] and [2]. 0 1 2 3 4 5 6 7 8 9 10 11 12 0 1 2 3 4 5 6 7 8 9 10 11 12 M6 M7 M6 M5 M6 s msg M6 s msg Proc1 Comm M7 s msg 119 be written with the flexibility to trade off result accuracy with resource requirements. Furthermore, often the relative accuracy may be captured numerically so that software can ....

T. F. Abdelzaher, A. Shaikh, F. Jahanian, and K. G. Shin, RTCAST: Lightweight Multicast for Real-time Process Groups, in: Proceedings of the Second IEEE Realtime Technology and Applications Symposium, Boston, Massachusetts (1996).

....it needs on that machine) the task can be wired to that machine by calling a wire task( primitive. 5.4.3 Pool Membership API A membership algorithm is used to maintain a consistent view of the current membership of the shared resource pool. Our group membership algorithm is a derivative of [2]. The only interface the user sees to that algorithm is the subscribe to pool( call which causes the machine on which the call was executed to join the named pool. Typically, when the application starts up on a given machine, it executes the join primitive which broadcasts a join request to the ....

....machine creates a singleton pool of itself and attempts to run the application on its own. The machine designates itself as the group leader for the pool (initially, consisting of itself only) When a group leader receives a join request from a different machine, it broadcasts a membership message [2] to all group members including the new machine. 112 When a new machine subscribes to (joins) the pool each machine in the pool adds the new member to the group. Since the new machine does not run any application task, its unfulfilled potential reward is zero. Due to our load sharing heuristic, ....

[Article contains additional citation context not shown here]

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin, "RTCAST: Lightweight multicast for real-time process groups," in IEEE Real-Time Technology and Applications Symposium, Boston, Massachusetts, June 1996.

....5.1. 2 Dynamic Adaptation to Changing Resource Pool Size In order to maintain a consistent view of the distributed resources (machines) available to the a QoS provider at any given time, the processing nodes that belong to the provider run a group membership algorithm which is a derivative of [7]. When a new QoS provider is created, a new resource pool is formed. Other machines can join the pool using the subscribe to QoS provider( call which causes the machine on which the call was executed to join the resource pool of the named provider. Due to our loadsharing heuristic, machines whose ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin, "RTCAST: Lightweight multicast for realtime process groups," in IEEE Real-Time Technology and Applications Symposium, Boston, Massachusetts, June 1996.

....with this configuration to verify experimentally the behavior of the implemented protocol layers. The RTCAST layer was tested first to verify its support for system consistency, then the ACSA layer was added, and the system was tested for deadline guarantees. These tests are further described in [19]. Though the user level server implementation was adequate for functional testing, we found that performance testing which heavily loaded the server led to unpredictable behavior in terms of message delivery order. The original x Kernel 3.2, as well as OSF CORDS, use a thread per message model in ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin, "RTCAST: Lightweight multicast for real-time process groups," in Proc. IEEE Real-Time Technology and Applications Symposium (RTAS '96), pp. 250-- 259, Boston, MA, June 1996.

....hard real time systems. For example, TTP [10] is a time triggered distributed real time system: its architecture is based on the assumption that the worst case load is determined apriori at design time, and the system response to external events is cyclic at predetermined time intervals. RTCAST [18] is a lightweight fault tolerant multicast and membership service for real time process groups which exchange periodic and aperiodic messages. The service supports bounded time message transport, atomicity, and order for multicasts within a group of communicating processes in the presence of ....

T.Abdelzaher, A.Shaikh, S.Johnson, F.Jahanian, and K.G.Shin. Rtcast: Lightweight multicast for real-time process groups. In IEEE Real-Time Technology and Applications Symposium, 1996.

....with real time guarantees. RTCAST uses a logical token ring to enforce both causal and total ordering on messages delivered to the group, and it totally orders group membership changes with respect to messages. Based on the published performance evaluation of our actual RTCAST implementation [27], we parameterized the protocol stack and tuned the simulation to accurately reflect the real performance of the protocol. Since the performance of RTCAST compares very favorably with the published performance data of other group multicast protocols (most notably Totem [1] and Horus [3] we ....

T. Abdelzaher, A. Shaikh, S. Johnson, F. Jahanian, and K. Shin, "RTCAST: Lightweight multicast for real-time process groups," Technical report, Dept. of Electrical Engineering and Computer Science, University of Michigan, 1997. To appear in IEEE Transactions on Software Engineering.

....using various delivery semantics such as FIFO, causal, or total ordering while providing a consistent membership view of participants believed to be accessible. A number of group communication systems also provide explicit support for real time applications. For example, TTP [9] RTCAST [10] and XPA [11] provide guaranteed response time by exploiting real time operating system features or special purpose hardware support. Other approaches including the fail awareness framework [12] quasi synchronous model [13] and Cactus [14] are based on the best effort paradigm. One of the ....

....systems, improving both throughput and latency compared to systems of comparable size composed using a single process group. Our simulation was carried out using Opnet, version 3.5.A. To implement a group communication service within the simulation, we used the actual production code for RTCAST [10], a group multicast protocol we have developed which provides predictable, atomic message delivery with real time guarantees. RTCAST uses a logical token ring to enforce both causal and total ordering on messages delivered to the group, and it totally orders group membership changes with respect ....

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin, "RTCAST: Lightweight multicast for realtime process groups," in Proceedings IEEE Real-Time Technology and Applications Symposium (RTAS '96), pp. 250--259, June 1996.

No context found.

T. Abdelzaher, A. Shaikh, F. Jahanian and K. G. Shin. "RTCAST: Lightweight Multicast for Real-Time Process Groups". Best Student Paper Award Winner, The Second IEEE Real-time Technology and Applications Symposium (June 1996).

No context found.

ABDELZAHER, T., SHAIKH, A., JAHANIAN, F., AND SHIN, K. 1996. RTCAST: Lightweight multicast for real-time process groups. In IEEE Real-Time Technology and Applications Symposium (RTAS '96). Boston, MA, USA, 250--259.

No context found.

T. Abdelzaher, A. Shaikh, F. Jahanian, and K. Shin. RTCAST: Lightweight multicast for realtime process groups. In IEEE Real-Time Technology and Applications Symposium (RTAS), June 1996.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC