✏️ Introduction

multicast → one sender, multiple receiver

unicast → one sender, one receiver

broadcast → one second, all processes receive

receive vs. deliver

• receive happens at lower layer, ex: received from network
• deliver is a upcall from lower layer at host to application layer
• messages can be received and not delivered = these are BUFFERED

why ordering matters? there could be multiple updates at sender & receiver, how to order these?

🙋🏽 FIFO Ordering

this is a per-sender FIFO! order the messages from each sender in order of receiving, but don’t worry about ordering across senders

IMPLEMENTATION

• receiver maintains per-sender seq num
• maintain list at process i as Pi where each item is the multicast sequence num of the other processes in the group; ex Pi = [0, 0, 0, 0] for P1, P2, P3, P4
• when sending a message, increment self and send ONLY THIS NEW NUMBER in multicast; ex Pj[j] += 1
• when receiving a multicast, check if updated sequence num is the immediate next one
  • if yes Pi[j] + 1 == Pj[j] → deliver message
  • if not Pi[j] + 1 != Pj[j] → buffer under order is restored

➡️ Causal Ordering

• multicasts whose events are causally related must be received in a causally-obeying order
• BUFFER where necessary if intermediary update was not received yet
• concurrent events can be received in different orders at each process, doesn’t matter
• causal ordering is useful for things like social media (want to see the comment before the reply to the comment)

‼️ causal implies FIFO (but reverse is not true) ‼️

IMPLEMENTATION

• each receiver maintains vector of per-sender sequence numbers
• updating rules are similar to FIFO, but upon updating seq num send the ENTIRE VECTOR, not only the seq num → this helps to determine causality