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 126.96.36.199 to 188.8.131.52) 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 (184.108.40.206 to 220.127.116.11), for multicast traffic within a given local network.
· Internet Control Block (18.104.22.168 to 22.214.171.124).
· Ad Hoc Control Block (126.96.36.199 to 188.8.131.52), for traffic that does not fit any other block.
· Administratively Scoped Block (184.108.40.206 to 220.127.116.11), 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
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
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
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
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
Provide a means of freeing the space that is no longer needed
Java (automatic), C++ (user supplied)
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
Objects are managed by servers and
Their clients invoke their methods using RMI
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
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
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.
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
Copyright © 2018-2020 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.