Multicast 组播

通信模式

Unicast

一个进程向另一个进程发送消息
尽力而为：如果信息传送，就没有被破坏
可靠的：保证信息能传送
有序：信息传送(deliver)的顺序与发送的顺序一致

Broadcast

一个进程向所有进程发消息

Multicast

一组进程内，一个进程向其他进程发消息。

Deliver(m):传递由组播发送的消息到调用进程 到应用层
Receive(m):只是接收到消息

基本组播（Basic Multicast）

用可靠的unicast 操作：

B-multicast(group g,message m):对每个在组G内的每个进程p,send(p,m)
进程receive(m)的时候:进程p执行B-deliver(m)

如果
(1)组播进程不出错
(2)Unicast 是可靠的
(3)发送方不崩溃
我们认为信息可以最终传送到组内

可靠组播（Reliable Multicast）

可靠组播满足以下三个性质

完整性 Integrity

一个正确的进程只传递（deliver）同样的信息最多一次。

有效性 Validity

如果一个正确(correct)的进程组播消息m,它最终自己也将传递m
Liveness for sender

协定 Agreement

如果一个正确(correct)的进程传递消息m,其他正确的进程终将传递m
（要么所有都能传递到，要么所有都传不了）

有效性和协定保障了整体的活性（overall liveness):如果一些正确的进程组播了信息m，那所有正确进程都会传递信息m。

例子
如果一个进程B-multicast到一半崩溃了，其他一半进程deliver了m,另一半没有。就破坏了协定（Agreement）

实现R-multicast

用到一个B-Multicast在进程中

初始化
已收到的是一个空集

进程p需要R-multicast 到整个组g

当B-deliver(m)基本传递到进程q，g=group(m)哪组传的消息
在m不在收到的组的情况下，就把他添加进去(因为大家都在传，就防止收到重复的信息)

如果q不是组播信息的进程。他就自己也组播这个信息

最后有效传递M（如果是重复的消息就不能有效传递到应用层）

比较低效，因为每个消息被发送到每个进程会有|g|次。但是满足协定。
有效性是因为他自己组播消息也会收到消息。
完整性是因为每个消息只会有效传递一次

有序组播 Ordered Multicast

1.FIFO ordering
2.Casual ordering
3.Total ordering

FIFO 排序

如果一个正确的进程发出multicast(g,m),然后发出multicast(g,m’)，那么每个正确进程会在传递m’传递m

但是如果是不同的发送方的组播可以不管。

因果排序（Causal Order）

组播中发送事件有因果关系，那么他们传递这些事件也是相同的因果关系。

如果Multicast(g,m)->multicast(g,m’) ，->表明g的成员之间发送的消息引起的发生在先关系，那额传递肯定是m’在m之后

因果排序 VS FIFO

Causal Ordering => FIFO Ordering
如果一个组播协议实施因果排序，那他肯定也是FIFO ordering
相反FIFO不能证明有因果排序

例子：
下图是FIFO排序，对比从同一个process出发的红绿两条线是按顺序到达的

但是下图不是因果排序。组播M1应该在M3之前到达P2。
如果M1:1到达P3在M3:1之后，这个就是satisfy casual order。

全排序 Total Order

保证所有进程以同样的顺序传递所有的组播。
全排序并不关心组播发送的顺序。
如果一个正确的进程在传递M之前传递M’,那么其他的进程也在传递M之前传递M’。
例子

在所有进程中，传递顺序都是M1:1,M2:1,M3:1，M3:2

因果排序vs全排序

全排序不能保证因果
因果也不能保证全排序

例子：
以下是满足因果排序的

但是下图不满足全排序，在圈出来的两个地方的两个信息传递的顺序不一样。

混合排序组播

Causal-total hybrid协议满足因果和全排序

实现排序组播

实现FIFO order

每一个进程都维护一个数组。比如进程1 P1[2]记录着最后从P2收到的最后的序列数。

组播时，将自己序列号Pj[j]自动加一
将序列号和信息一起组播出去

在传递信息时，如果进程i收到进程j的组播，序列号是S。如果序列号S等于当前序列号加一，那么就可以直接传递给应用层
否则先存储在buffer中，直到收到想要的序列
例子：
当从一个进程出发的信息没有按顺序传递，就先缓存
收到按顺序的，再更新

一个值得注意的是，P3发送[2,0,1,0]P4收到的时候更新[1,0,1,0]然后从P1收到才更新为[2,0,1,0]

实现全排序

在不同的进程中用相同的序列号计数。
两种方法：
1.Using a centralized sequencer
2.A decentralized mechanism(ISIS)

Sequencer based total ordering

选一个进程作为leader或者作为sequencer。
这个顺序者会维护一个序列号S
S初始化为0，如果传递一条组播信息m，S++,然后组播信息m和S
全排序组播就是把信息发给全组和顺序者
如果一个进程收到组播
Pi维护一个本地收到的序列号Si
只有以下三个条件满足才能传递m
1.收到了从顺序者传过来的m的顺序
2.这个顺序 S=Si+1
然后传递给应用层，并Si++

ISIS

基本原理：收到消息后先发回建议序号给发送者，发送者再根据这些序列号来产生一个协定的序号。

发送者组播：

收到组播的进程：
1.回复一个建议序列号
（1）大于观测到的协议序列
（2）大于之前自己建议过的序列号
2.将信息存储在优先队列中
（1）用序列号排序
3.记录信息是未传递

发送者会选择一个协定的序列号，这个序列号会是发送者收到所有建议序列号中最大的。然后把协定序列号附在信息上，再次组播

收到第二次组播之后，把信息的序列号改成协定序列号。然后重新在等待序列里排序。并把信息标为“deliverable”,然后传递在优先队列队首的可传递信息。

有重复的问题，排序就很麻烦，这个时候写成 进程和序号

建议序号：必须高于这个进程中所有的建议序号和他所收到的协定序号
协定序号：顺序者收到的所有建议序号的最大值

证明ISIS能保证全排序

假设有两个信息一个m1，一个m2，两个进程p1 p2。
p1在m1之前传递m2
当p传递m1的时候，m1肯定是位于等待队列的头部，
那么m2有以下三种可能 ：
1.m2已经在p的队列中，并且是可传送的
可以认为finalpriority(m1)<finalpriority(m2)
2.m2在p的队列中，但是还不是可传递的
finalpriority(m1)<proposedpriority(m2)<=finalpriority(m2)
3.还不在p的队列中 说明还没有接收
finalpriority(m1)<proposedpriority(m2)<=finalpriority(m2)

所以任何一种情况都不可能
finalpriority(m1)>finalpriority(m2)

实施因果排序

和FIFO 组播类似
每个进程Pi都维护一个数组 Pi[1…N]
Pi[j]是Pi从Pj收到的最后的序列号

因果组播，先把自己的序列号加一，再将其附上信息进行基本组播
接收到了基本传递（B-deliver）({m,V[1…N]}),存储这个信息，直到满足以下条件：
1.这个信息是从Pj发送给Pi的下一个
V[j]=Pi[j]+1
2.所有发生在m之前的其他组播都在Pi收到了
V[k]<=Pi[k] k!=j

如果以上两种情况满足
那么就可以传递m
以及设置Pi[j]=V[j]

例子：
在m之前的一些组播没有收到，因此需要buffered

树状组播和Gossip

B-multicast 用 unicast sends的话
会有冗余的包裹

所以如何解决消息冗余的问题？

树状组播

只将消息发送给子集的进程


或者也可以将路由器也包括进去，这样又能少发送一些
IP组播

但是如果任何一个节点崩溃？

Gossip

随机传送消息给b个节点，然后其他节点收到这个消息后也随机传送消息给b个节点

对比起之前两种方法，不需要构建树，比起unicast更加有效率

组播总结

类型

1.基本 Basic
2.可靠的 Reliable
3.顺序：FIFO,Causal,Total
4.以上所有的组合

传送信息的机制

1.unicast
2.树状和gossip
3.Gossip:更加的scalable 并且 可以处理失败

标签：收到,组播,传递,Multicast,分布式系统,进程,序列号,排序
来源： https://blog.csdn.net/fragile98/article/details/113880738