Group Communication EEE465 2001 Reference: CDK00 chapter 4

1
Group CommunicationEEE465 2001Reference
CDK00 chapter 4

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
Multicast Messages

• a multicast message is a message sent by one
  process to a group of processes
• interesting issues
• ordering
• ensuring that messages are received in
  appropriate orders at all sites
• arrival guarantees
• providing the appropriate level of guarantee of
  message arrival
• implementation
• efficiency, reliability, monitoring, hold-back,
  negative acknowledgement, reliable and atomic
  multicast, totally ordered atomic multicast

3
Why Multicast?

• fault tolerance based on replicated services
• all servers receive and act on service request,
  therefore fulfilled even in the event of server
  failure
• locating objects in distributed services
• key problem in distributed systems is finding
  remote objects multicast lookup is one approach
  (e.g., Jini)
• improved performance through replicated data
• changes in values must be multicast to replicas
• multiple update
• multiple, simultaneous notification that
  something has happened

4
Ordering

• unordered
• messages are processed at each site in
  undetermined and possibly different orders
• causally ordered
• all messages are processed at all sites in an
  order which respects the possibly caused
  relation
• totally ordered
• all messages from all sites are processed in the
  same order at all receiving sites

5
Arrival Guarantees

• A message transmitted by atomic multicast is
  either received by all of the processes in the
  receiving group or by none of them
• membership in the receiving group must be defined
  such that failed processes are not in groups
• used when it is essential to ensure that all
  processes in the group proceed in lock-step
• Atomic multicast is expensive. Alternatives
• reliable multicast
• network or process failure may prevent delivery
  to some group members, but otherwise the message
  will be delivered to all
• unreliable multicast
• the message is sent once, and may or may not be
  received by anyone

6
Sample Implementation

• public class SocketExample
• private DatagramSocket socket
• void sendMulticast(List recipients, byte
  buffer)
• Iterator i recipients.iterator()
• while (i.hasNext())
• try
• Recipient recipient (Recipient)i.next()
• DatagramPacket message new DatagramPacket(
• buffer, buffer.length,
• recipient.address, recipient.port)
• socket.send(message)
• catch (IOException e)
• i.remove()

import java.net. import java.util. import
java.io.IOException
public class Recipient public InetAddress
address public int port
7
Efficiency

• sample implementation is inefficient
• doesnt take advantage of any broadcast or
  multicast facilities offered by underlying
  network
• e.g., Ethernet LAN broadcast
• typically at machine, rather than process level
• general purpose multicast facility should support
  multicast to arbitrary processes
• may be multiple processes on a single machine
• should take advantage of LAN broadcast where
  possible
• must be able to span beyond LAN
• e.g., IP Multicast (M-bone)

8
Reliability

• sample implementation is unreliable messages may
  not arrive at some recipients
• messages may be dropped en route
• originator may fail part-way through transmission
• unacceptable if application demands atomic or
  totally ordered multicast
• to efficiently achieve reliable and atomic
  multicast
• monitoring and acknowledgements
• multicast completion by recipients
• hold-back
• negative acknowledgement

9
Monitoring Acknowledgements

• monitoring
• checking group members from whom replies are
  expected to detect failure
• typically deemed failed if no response after N
  communication attempts
• acknowledgements
• requires some form of acknowledged protocol
• once the sender has received acknowledgements
  from all recipients, it knows that reliable
  multicast has succeeded
• if no acknowledgement after some time t, retry

10
Completion by Recipients

• if originator fails, one of the recipient
  processes must complete the multicast
• requires recipient to
• identify that originator has failed, and
• identify that multicast is incomplete
• protocol that allows this is
• originator multicasts messages
• recipients reply to originator
• originator multicasts completion notice
• recipients monitor originator for completion
  notice
• if not received after some time t, assume
  originator has failed and redo multicast as new
  originator
• improve performance next multicast from an
  originator indicates completion of previous

11
Hold-back and Negative Ack

• hold-back
• since messages may be received out of order,
  sometimes necessary to hold back (delay
  processing of) received messages until preceding
  messages are received
• negative acknowledgement
• avoids sending acknowledgements by asking only
  for retransmission of messages not received
• requires that each message have a sequence
  number, so recipients can identify missing
  messages
• for completion by recipients, requires recipients
  maintain history of all previously received
  messages
• not space efficient
• normally addressed by including occasional
  positive acknowledgements in the protocol

12
Totally Ordered Atomic Multicast

• total ordering and atomicity often combined
• requires globally unique, totally ordered
  sequence numbers for all messages
• recipients hold-back all early messages
• problem is generating sequence numbers
• use logical (counting) or physical (clock)
  timestamps
• logical timestamps produce an arbitrary total
  ordering of messages, usually by means of a
  vector of sequence numbers from each process in
  the group
• physical timestamps require clock synchronization
• use a sequencer process
• sequencer assigns timestamp and handles
  multicast all other processes send via the
  sequencer
• use a fully distributed protocol

13
Recap Multicast Messages

• a multicast message is a message sent by one
  process to a group of processes
• interesting issues
• ordering
• ensuring that messages are received in
  appropriate orders at all sites
• arrival guarantees
• providing the appropriate level of guarantee of
  message arrival
• implementation
• efficiency, reliability, monitoring, hold-back,
  negative acknowledgement, reliable and atomic
  multicast, totally ordered atomic multicast

14
Next Class Socket-based IPC