IP multicast – An implementation of multicast communication

IP multicast – An implementation of multicast communication

IP multicast • IP multicast is built on top of the Internet Protocol (IP). Note that IP packets are addressed to computers – ports belong to the TCP and UDP levels. IP multicast allows the sender to transmit a single IP packet to a set of computers that form a multicast group. The sender is unaware of the identities of the individual recipients and of the size of the group. A multicast group is specified by a Class D Internet address – that is, an address whose first 4 bits are 1110 in IPv4.

At the application programming level, IP multicast is available only via UDP. An application program performs multicasts by sending UDP datagrams with multicast addresses and ordinary port numbers. It can join a multicast group by making its socket join the group, enabling it to receive messages to the group. At the IP level, a computer

belongs to a multicast group when one or more of its processes has sockets that belong to that group. When a multicast message arrives at a computer, copies are forwarded to all of the local sockets that have joined the specified multicast address and are bound to the specified port number. The following details are specific to IPv4:

Multicast routers: IP packets can be multicast both on a local network and on the wider Internet. Local multicasts use the multicast capability of the local network, for example, of an Ethernet. Internet multicasts make use of multicast routers, which forward single datagrams to routers on other networks, where they are again multicast to local members. To limit the distance of propagation of a multicast datagram, the sender can specify the number of routers it is allowed to pass – called the time to live, or TTL for short. To understand how routers know which other routers have members of a multicast group.

Multicast address allocation: As discussed in Chapter 3, Class D addresses (that is, addresses in the range 224.0.0.0 to 239.255.255.255) are reserved for multicast traffic and managed globally by the Internet Assigned Numbers Authority (IANA). The management of this address space is reviewed annually, with current practice documented in RPC 3171. This document defines a partitioning of this address space into a number of blocks, including:

·        Local Network Control Block (224.0.0.0 to 224.0.0.225), for multicast traffic within a given local network.

·        Internet Control Block (224.0.1.0 to 224.0.1.225).

·        Ad Hoc Control Block (224.0.2.0 to 224.0.255.0), for traffic that does not fit any other block.

·        Administratively Scoped Block (239.0.0.0 to 239.255.255.255), which is used to implement a scoping mechanism for multicast traffic (to constrain propagation).

Failure model for multicast datagrams • Datagrams multicast over IP multicast have the same failure characteristics as UDP datagrams – that is, they suffer from omission failures. The effect on a multicast is that messages are not guaranteed to be delivered to any particular group member in the face of even a single omission failure. That is, some but not all of the members of the group may receive it. This can be called unreliable multicast, because it does not guarantee that a message will be delivered to any member of a group.

Java API to IP multicast • The Java API provides a datagram interface to IP multicast through the class MulticastSocket, which is a subclass of DatagramSocket with the additional capability of being able to join multicast groups. The class MulticastSocket provides two alternative constructors, allowing sockets to be created to use either a or any free local port. A process can join a multicast group with a given multicast address by invoking the joinGroup method of its multicast socket. Effectively, the socket joins a multicast group at a given port and it will

receive datagrams sent by processes on other computers to that group at that port. A process can leave a specified group by invoking the leaveGroup method of its multicast socket.

Multicast peer joins a group and sends and receives datagrams

Reliability and ordering of multicast

The effect of the failure semantics of IP multicast on the four examples of the use of replication

·        Fault tolerance based on replicated services: Consider a replicated service that consists of the members of a group of servers that start in the same initial state and always perform the same operations in the same order, so as to remain consistent with one another. This application of multicast requires that either all of the replicas or none of them should receive each request to perform an operation – if one of them misses a request, it will become inconsistent with the others. In most cases, this service would require that all members receive request messages in the same order as one another.

·        Discovering services in spontaneous networking: One way for a process to discover services in spontaneous networking is to multicast requests at periodic intervals, and for the available services to listen for those multicasts and respond. An occasional lost request is not an issue when discovering services.

·        Better performance through replicated data: Consider the case where the replicated data itself, rather than operations on the data, are distributed by means of multicast messages. The effect of lost messages and inconsistent ordering would depend on the method of replication and the importance of all replicas being totally up-to-date.

·        Propagation of event notifications: The particular application determines the qualities required of multicast. For example, the Jini lookup services use IP multicast to announce their existence

Communication between Distributed Objects

The Object Model

Five Parts of the Object Model

An object-oriented program consists of a collection of interacting objects

Objects consist of a set of data and a set of methods

In DS, object’s data should be accessible only via methods

Object References

Objects are accessed by object references

Object references can be assigned to variables, passed as arguments, and returned as the result of a method

Can also specify a method to be invoked on that object

Interfaces

Provide a definition of the signatures of a set of methods without specifying their implementation

Define types that can be used to declare the type of variables or of the parameters and return values of methods

Actions

Objects invoke methods in other objects

An invocation can include additional information as arguments to perform the behavior specified by the method

Effects of invoking a method

The state of the receiving object may be changed

A new object may be instantiated

Further invocations on methods in other objects may occur

An exception may be generated if there is a problem encountered

Exceptions

Provide a clean way to deal with unexpected events or errors

A block of code can be defined to throw an exception when errors or unexpected conditions occur. Then control passes to code that catches the exception

Garbage Collection

Provide a means of freeing the space that is no longer needed

Java (automatic), C++ (user supplied)

Distributed Objects

Physical distribution of objects into different processes or computers in a distributed system

Object state consists of the values of its instance variables

Object methods invoked by remote method invocation (RMI)

Object encapsulation: object state accessed only by the object methods

Usually adopt the client-server architecture

Basic model

Objects are managed by servers and

Their clients invoke their methods using RMI

Steps

The client sends the RMI request in a message to the server

The server executes the invoked method of the object

The server returns the result to the client in another message

Other models

Chains of related invocations: objects in servers may become clients of objects in other servers

Object replication: objects can be replicated for fault tolerance and performance

Object migration: objects can be migrated to enhancing performance and availability

The Distributed Object Model

Two fundamental concepts: Remote Object Reference and Remote Interface

o   Each process contains objects, some of which can receive remote invocations are called remote objects (B, F), others only local invocations

o   Objects need to know the remote object reference of an object in another process in order to invoke its methods, called remote method invocations

o   Every remote object has a remote interface that specifies which of its methods can be invoked remotely

Remote and local method invocations

Five Parts of Distributed Object Model

·        Remote Object References

o   accessing the remote object

o   identifier throughout a distributed system

o   can be passed as arguments

·        Remote Interfaces

o   specifying which methods can be invoked remotely

o   name, arguments, return type

o   Interface Definition Language (IDL) used for defining remote interface

Remote Object and Its remote Interface

·        Actions

o   An action initiated by a method invocation may result in further invocations on methods in other objects located indifference processes or computers

o   Remote invocations could lead to the instantiation of new objects, ie. objects M and N of following figure.

·        Exceptions

More kinds of exceptions: i.e. timeout exception

RMI should be able to raise exceptions such as timeouts that are due to distribution as well as those raised during the execution of the method invoked

·        Garbage Collection

Distributed garbage collections is generally achieved by cooperation between the existing local garbage collector and an added module that carries out a form of distributed garbage collection, usually based on reference counting