3.1 Overview This section provides a technical explanation of MultiLink Solutions' Remote Multicast Protocol. 3.2 Technical Foundation A universal revolution is underway in telecommunications. The changes taking place are having a dramatic impact on how individuals and institutions communicate and do business with one another. Government at all levels, retailing and finance, health care, education, and entertainment are among the areas of human activity profoundly affected by the technological advances now underway. Communication networks are arrangements of hardware and software that allow users to exchange packets of information. This information may be voice, sounds, graphics, pictures, video, text, or data. Most often the users are humans, but they also can be computer programs or devices. There are a certain number of questions involved in assuring effective use of network resources. These issues determine the performance of a given network: Routing What paths should the packets follow in the network? Flow Control How can one regulate the flow of information so as to avoid parts of the network becoming congested? Addressing What is a convenient way of specifying the addresses of the receiving nodes? Security How can the privacy of the information transmitted over the network and the integrity of the nodes of the network be maintained? Standards How can the characteristics of the nodes be described so that vendors can build compatible hardware and software? Presentation How can one enable many different types of terminal equipment to communicate? In order to answer these questions, most communication networks use a layered construction of services in which services of one layer are built on top of those of the layer immediately below. In such a network, only the interaction between layers need to be defined carefully, not the internal implementation of these protocols. This layered structure also brings simplicity since a given layer needs only to know how to interact with the two adjacent layers. In the late 1970's, to promote the compatibility of network designs, the International Organization for Standardization (ISO) proposed an architecture model called the Open Systems Interconnection Reference Model (OSI model). The OSI model is a layered architecture with seven layers. The bottom three layers respectively deal with bit transmission (i.e, transmission of information in its computer encoded "bit" form), packet (or message segment) transmission on one link, and with end-to-end packet transmission. The top layers construct communication services for user applications. The following is a summary of each layer. LAYER NAME TASK 1 PHYSICAL Transmission of bits. 2 DATA LINK Transmission of packets on one given link. 3 NETWORK End-to-end delivery of packets. 4 TRANSPORT End-to-end delivery of messages. 5 SESSION Setup and management of end-to-end conversations. 6 PRESENTATION Formatting, encryption and compression of data. 7 APPLICATION Network services (email, file transfers, etc.) The layer most visible to end-users. The current Internet uses the TCP/IP protocol to provide various services to users. IP (Internet Protocol) is the network layer protocol, and TCP (Transmission Control Protocol) the transport layer. However, these protocols are designed for point-to-point links and have limited performance and capabilities when it comes to the growing need for group communications. To respond to these new trends, IP-multicast was designed to eventually replace the existing IP. However the rest of the layers need also to be redesigned. And that is why RMP was created: To offer multicasting capabilities at an unmatched level of performance. MLS acnticipates its extensive market research will reveal that RMP is the fastest implemented reliable and secure communications protocol for groups of two or more destinations. A more detailed description of RMP follows. 3.3 Technical Description of RMP Current networking protocols (such as the Transport Control Protocol (TCP) standard and Novell's SPX) provide computer processes with reliable point to point communication. A computer process is a copy of a program executing on a computer, usually equivalent to an application such as a database or a word processor. This reliable communication is implemented on top of standardized unreliable point to point protocols such as the User Datagram Protocol (UDP) and Novell's IPX. Because Internet protocols such as TCP and UDP are standardized, processes on many different computer platforms and operating systems can use them to communicate with each other. However, point to point protocols do not work well for groups of computer processes that want to communicate together, because separate copies of each message have to be sent to each member of the group. RMP solves this problem and allows groups of processes to communicate easily, reliably, and efficiently, even in the face of hardware faults. RMP consists of a group naming service, a fault-detector, and a group messaging service. The messaging service handles communication between processes, the fault-detector detects when group members can no longer be communicated with, and the group naming service allows a single dynamic name to be used for each group, rather than having to use a list of static, previously assigned process identifiers. 3.4 Use of RMP RMP is a networking protocol. It is software that can be implemented either as part of the operating system, or as a library that users link to. The current implementation is built as a library on top of UNIX. The current version of RMP is implemented as a library because a library is easier to debug and maintain than an operating system implementation, and because it has better performance in many cases[REFERENCE]. RMP will be ported to a wide range of operating systems, including Microsoft Windows, Microsoft Windows/NT, IBM OS/2, and DEC VMS. Processes using RMP on any of these operating systems will be able to communicate together. Processes communicate with each other through function calls to the RMP Application Programming Interface (API). Communicating processes can be located on the same computer or spread across multiple computers connected by a Local Area Network (LAN) or Wide Area Network (WAN). Group communication in RMP is made easy by the use of process groups. In point to point protocols such as TCP, a process must learn the exact network identifier of the process it wants to communicate with before a connection is possible. RMP simplifies this process through the use of an integrated group naming facility. This facility allows a process to elect to communicate with one or more process groups, each of which is specified by a user-defined text string. For example, a database application for a given enterprise could be named "Database.OurEnterprise". A process group's membership can change dynamically as members add or remove themselves. As hardware faults are detected, the membership of affected groups is automatically updated. The group membership service is fully distributed, so that no central server has to be run to manage group changes. Members of process groups are divided into clients and servers. RMP's client/server model is similar to standard client/server computing, but is expanded by allowing communication with multiple simultaneous servers. In addition, the servers can reliably communicate between themselves. Servers are considered permanent members of a group, while clients are transient. Messages sent to the group as a whole are reliably sent to all of the servers. The group membership operations apply to servers only, because clients can only receive replies to messages they send, and not messages sent to the group as a whole. This allows hundreds or thousands of clients to all be part of a process group without having to change the membership of the group every time one of them wants to start or stop communicating with the group. Two of the biggest uses of RMP are to distribute client/server applications such as databases and to provide the communication layer for shared tools. Examples of shared tools are shared conferencing tools, shared editors, and Computer Supported Collaborative Work (CSCW) applications. For these applications, each communicating process is typically implemented as a server, since all of the applications are together serving each other. The other main application, distributing a server, involves running separate copies of it on multiple machines. RMP makes this easy with its built in fault-tolerance and extended virtual synchrony, explained below. Replicating a server results in both better availability and performance of the service. The service is made more available because it can tolerate some machine and network failures and continue running. In the past, this has only been possible through the use of expensive specialized hardware. Most computer systems which provide fault-tolerance do so by providing a back-up server which does nothing but sit around and duplicate the actions of the primary server. In the case of a failure, the backup server is in exactly the same state as the primary machine, and can take over immediately. Unlike these approaches, RMP allows all of the copies of the server to be in operation at the same time. When a client calls in with a service request, RMP will send the request to all of the servers in the group and notify one of them that it should handle the request. After that server is done handling the request, it reliably sends the result both to the other servers and to the client. For computation intensive (as opposed to network intensive) services, this multiplies the number of clients a service can support by the number of servers in the group. 3.5 Reliable and Ordered Communication In point to point communication, it is easy to define reliability and message ordering. Reliability in this context means that the two processes continue communicating in the face of temporary (transient) errors, and break their connection if errors or hardware faults stop them from communicating for an extended period of time (typically 15-60 seconds). If one of them can't communicate, then neither can the other. Messages are typically delivered to the other process in the same order they were sent. Reliability is more complicated when there is more than a single destination for a message, as one or more group members can fail away (due either to a software or hardware error) and the others should still be allowed to communicate. Even more problematic, a network fault can cause a network partition to occur. This breaks a group into two or more pieces. Members of each of these group fragments can communicate with other members in their fragment, but not to members in any other fragment. Depending on the level of consistency needed between different copies of shared data spread between the fragments, one or more of the fragments may still continue running. To solve this problem, RMP allows users to select the level of reliability they want their messages to be delivered with. The higher levels of reliability will guarantee that a message is delivered to all of the members in the group that continue to function, or to none of the members in a group that continue to function, no matter what hardware faults occur. This is very important in guaranteeing the consistency of replicated data for distributed services. Message ordering in groups is also more difficult to define. In group communication, not only does it matter what order a given process sends out its messages in, it also matters what how the messages from multiple group members are interleaved at different destinations. Because the computer networks in question are asynchronous, two machines A and B could each send a message, and one destination could receive A's message first, while the other receives B's first. RMP solves this by providing extended virtual synchrony. Messages sent with this service will arrive in the same order at all destinations. Because this is an asynchronous system, it is impossible to tell which machine "really" sent a message first. Instead, RMP allows messages to be sent with total ordering. A set of totally ordered messages will be delivered in the same order at all the servers in a group. The ordering may not be exactly the same as the order in which the messages were sent, but this does not matter for most applications. In addition, virtual synchrony provides a total ordering on error messages and group membership changes, so that all of the events in a group will appear to be happening synchronously. This provides the ease of programming advantages of a synchronous system with the performance of an asynchronous system. Like reliability, ordering can be specified by the user. Lower levels of ordering only order messages relative to messages sent from the same sender. The highest level of ordering guarantees that virtual synchrony will hold for a group even in the face of arbitrary hardware faults. 3.6 Efficient Group Communication In addition to the problems point to point links have with reliability and ordering of messages, using them for group communication is very inefficient, because each message has to be sent separately to each destination. For network intensive applications, this will reduce the performance of the application by a factor of one over the number of servers in the group. RMP provides its reliability and ordering guarantees without any major performance penalty. With RMP, two processes can communicate with each other almost as fast as with TCP, and this performance stays almost constant independent of the number of server processes in the group. RMP does this by making use of unreliable multicast protocols such as IP Multicast. IP Multicast is a new Internet protocol standard that is being supported by most major vendors. It provides an efficient unreliable datagram service to multiple destinations. There are now ports for most architectures, and its usage and support is constantly increasing. One packet sent to an IP Multicast group gets sent to all of the processes in the group. Instead of sending a separate packet to each process, IP Multicast routers maintain routing information about the group that allows a single packet to be sent to all machines, getting copied at the routers when necessary. The routers maintain a close approximation to the most efficient way of connecting the group members (called a minimum spanning tree) and they handle adding and removing pieces of this tree when processes join or leave a group. In addition, IP Multicasting makes use of hardware multicasting on links (such as Ethernet, FDDI, and Token Ring) that support it. Hardware multicasting allows one packet to be sent to multiple destinations on a link for the same cost as a packet sent to just one of them. Unlike broadcasting, multicast packets only go to the desired destinations, so they do not burden other computers connected to the network. This combination of multicast routing and hardware multicast support makes IP Multicasting much more efficient for group communication than other alternatives such as IP. For a group of N destinations, it can be up to N times more efficient in terms of network resources than a series of non-multicast packets. IP Multicast is especially attractive because it is the only protocol that supports unreliable multicast that spans multiple networks across large inter-networks such as the Internet. However, other protocols such as Novell's IPX also support multicast within a single LAN. The messaging system of RMP uses a novel and highly efficient technique for guaranteeing reliability that makes it the fastest known reliable communication protocol for groups of two or more destinations. On most LANs, RMP provides better performance to two or more destinations than any point to point protocol can even theoretically provide. Figure 1 [not included due to incompatibilities among company members' computers; will include in next update] shows a graph of the throughput (amount of data sent per second) of RMP, compared with all other point to point protocols. RMP handles group membership changes not due to system faults as a single message sent to the group, so performance does not noticeably degrade as servers join or leave a group. Because RMP allows replicated servers to all share the load of multiple clients, and because RMP's performance does not seriously degrade as the number of servers in a group increases, distributed servers that use RMP can run much faster than servers that do not use RMP. For many applications, this increase will increase by a multiple equal to the number of servers in the group. This also makes RMP suitable for coarse-grained parallel programming. Current research in progress may also make RMP suitable for fine-grained parallel programming by reducing the latency (the time it takes for a message to be delivered) of standard networking protocols by a factor of 10 or more.