09分布式
Group communication
IP多播:
多播系统模型
基础多播
Reliable 可靠多播
- R-multicast实现方法包括
- 对于封闭组如何实现
可靠多播中的附带机制
Reliable Delivery
Group Membership Service
IP组播
- Group view
- View Delivery
- View-Synchronous Group Com.
Group communication
multicasting多播通信:将单个消息几乎同时发送到一组进程的机制
多播是指将消息几乎同时发送给一组选定的接收者(即进程或节点)。这与单播(unicast,一对一)和广播(broadcast,一对全部)相对。多播可以是网络层面的,如IP多播,也可以是应用层面的,通过算法在节点间分发消息来模拟。
要实现这个应用需要考虑静态组(固定的,不会随时间变化)和动态组(群组成员可以动态加入和离开),多播与单播
好处:效率高:同时向n个进程发送一条消息而不是向n个进程发送n个消息,减少带宽;交付得到保证:如果使用单播,消息发送失败会导致只有一部分进程收到消息,消息的顺序也有问题
三种行为:
- 不可靠的多播:不能保证发送顺序,消息只传输一次
- 可靠多播:尽最大努力向组内所有成员发送消息
- 原子Atomic多播:消息要么会被全部接收,要么一个都不收
IP多播:
它支持将消息传输到进程的群组。这种机制广泛用于需要高效群组通信的应用,比如视频会议、流媒体广播和实时应用
- 多播IP地址:
- IP多播使用特殊的IP地址范围(224.0.0.0到239.255.255.255),这些地址被划分用于多播传输,而不是指向单个设备的单播传输。
- 动态群组成员资格:
- IP多播支持动态群组成员资格,意味着进程可以随时加入或离开多播群组。
- 使用UDP传输消息:
- IP多播通常使用用户数据报协议(UDP)来传输消息。UDP是一个简单的传输层协议,提供了基本的消息发送机制,但不保证消息交付,没有重传机制,也不确保消息顺序。
- 多播路由器:
- 多播路由器的作用是在本地网络和互联网上路由多播消息。它们管理多播流量并确保多播数据包能够到达所有订阅了特定多播地址的成员。
- Mbone(多播主干网) :
- Mbone是一个非正式的、支持在互联网上传输IP多播包的路由器网络。它不是一个物理网络,而是构建在现有的互联网基础上的一个虚拟网络。
- 使用生存时间(TTL)值:
- TTL值可以用来限制多播消息的传播距离。每经过一个路由器,TTL就减一。当TTL达到零时,数据包将不再被传输。
- 应用场景:
- IP多播主要用于集群、服务器农场等内部网络,这些场景中需要有效率的、目标群组的数据分发。
IP多播提供了一种有效的方式来同时向大量用户发送数据,这可以大大减少网络带宽的需求,并降低服务器的负载,因为相同的数据不需要单独发送给每个用户。然而,IP多播在互联网范围内的应用由于需求、复杂性和缺乏普遍支持而受限。在许多情况下,它更适用于受控的网络环境,如局域网或组织内部网络。
多播系统模型
基础多播
- 向静态组所有进程传递消息。B-multicast(g,m), B-deliver(m)
- 它的实现建立在保证消息传递的假定单播协议上比如TCP
- send(p,m)向进程p发送m
- receive(m)应用层收到m
- 对于B-multicast(g,m),每一个p属于g,所以利用send(p,m)实现;receive和B-deliver一样
- 多线程可以同时发送多个单播消息
- 这将遭受ACK-implosion:发送者需要接收到一个来自接收者的确认信号,以表明消息已经被成功接收。当使用单播消息来实现多播时,每个接收者都会发送一个ACK回到发送者。如果群组很大,这将导致发送者收到大量几乎同时到达的ACK
- 缓冲区爆满;ACK会被丢弃;丢弃后重传会进一步加大系统负载;造成严重的网络拥塞
- 为了解决这些问题,可以使用基于IP多播的多播服务。IP多播允许发送单个数据包到一个多播组地址,而不需要单独向每个成员发送消息
- 就是模拟多播,一次性给好多个发送消息,本质是单播多次使用
Reliable 可靠多播
- Guaranteed Delivery:基础多播服务确保了消息至少被递送一次。
- 完整性(Integrity) :正确的进程p最多只传送一次消息m;m属于组m,m被sender(m)发送。意思就是该消息一定是由属于相同群组的发送者通过多播操作发送的。
- 有效性(Validity:如果一个正确的进程多播了一个消息,它最终会deliver这个消息
- 一致性(Agreement) :如果一个正确的进程deliver了m,那么group(m)中的其他正确进程最终都将deliver m
- R-multicast(g, m) :可靠地将消息
m
发送到群组g
。 - R-delivery(m) :应用程序进程可靠地接收消息
m
。
R-multicast实现方法包括
- IP多播:假设IP多播通常能够成功传输消息。
- 附带确认(Piggy-backed ACKs) :作为多播消息的一部分发送的确认信息。
- 否定确认(NAKs) :当一个进程检测到它漏掉了一个消息时发送。
对于封闭组如何实现
- 每个进程
p
为它所属的每个群组g
维护一个序列号 Spg(初始为零),记录p
发送到g
的消息数量。 - 同时,每个进程记录来自群组
g
中其他进程q
的最新消息的序列号 Sqg。 - 当进程
p
向群组g
多播消息时,它会附带当前的 **Spg**值和形式为 **<q, Rpg** > 的确认信息。-
- 所以p会发送一个这样的东西呗[<q1,R1>,<q2,R2>, <q3,R3>, <q4,R4> ]
-
- 发送消息后,
p
会将 Spg增加 1。 -
可靠多播中的附带机制
- 附带机制允许接收者知道它们可能漏掉的消息。
- 进程仅在消息带有的序列号
S
从p
等于**Rpg** +1 时,才会R-deliver
针对群组g
的消息。 - 递送消息后,Rp
g立即增加 1。 - 如果到达的消息序列号
S
小于或等于 Rpg,则丢弃该消息,因为它已经递送过了。 - 如果
S
大于**Rpg** +1或者确认中的R
大于 Rpg,则意味着存在尚未接收的一个或多个消息,这些消息可能已经丢失。 - 对于序列号
S
大于 **Rpg** +1 的消息,进程会将它们存储在一个保留队列中。 - 对于缺失的消息,会通过发送NAKs到原始发送者或收到足够序列号确认的其他进程
q
来请求重新发送。 -
- Incoming Messages(进入消息) :
- 这代表了发送到该进程的多播消息。
- Hold-back Queue(保留队列) :
- 当消息到达时,它们首先进入保留队列。这里会根据消息的序列号来决定它们是否已经准备好被递送。如果消息到达的顺序不是按照序列号顺序的(例如,由于网络延迟或丢包),那么它们将被放在保留队列中,直到缺失的消息到达。
- Delivery Queue(递送队列) :
- 一旦一个消息的前一个消息(基于序列号)被递送,它就可以从保留队列移动到递送队列。递送队列是一个有序队列,确保消息以正确的顺序被递送到上层应用。
- Message Processing(消息处理) :
- 当消息在递送队列中时,它将按顺序被传递到应用层进行处理。这个过程通常称为“deliver”。
- When delivery guarantees are met(当递送保证满足时) :
- 只有当所有的递送保证都被满足时(例如,保证递送的消息是按照正确的顺序和完整性),消息才会从递送队列中被递送。如果某个消息需要等待它的前一个消息,它会继续留在保留队列中。
Reliable Delivery
略,在平板上
Group Membership Service
群组成员管理服务(Group Membership Service,简称 GMS)是分布式计算系统中的一个关键组件,负责管理群组成员及其多播通信的动态变化。GMS 允许系统能够适应成员的加入、离开或故障。这项服务的主要目标包括:
- 提供群组成员变更的接口:
- GMS 提供了一个接口,允许群组的创建和销毁,以及成员的添加和删除。通过这个接口,可以动态地管理群组的构成,反映出群组随时间的自然变化。
- 实现故障检测器:
- GMS 还包括故障检测器,监控群组成员是否存在崩溃或常见的故障。这个检测器会标记服务为“怀疑中”(Suspected)或“非怀疑中”(Unsuspected),基于成员的响应和活动状态。
- 通知成员成员关系的变化:
- 一旦群组的成员构成发生变化,GMS 会通知所有成员。例如,如果有新成员加入或现有成员被排除,群组中的每个成员都会收到更新的成员列表。
- 执行群组地址扩展:
- GMS 管理群组标识符,用于将消息与一组应接收传入多播消息的群组成员地址关联起来。这确保了当发送者向群组发送消息时,消息能被正确地发送到所有当前的群组成员。
总的来说,GMS 是维持群组通信有效性和一致性的关键部分。它确保了即使在成员变更和网络故障的情况下,群组中的所有成员都能够及时地获得关于群组状态的正确信息,并且所有成员能够继续进行协调一致的通信。在现实世界的应用中,如分布式数据库、多用户在线游戏、以及实时协作工具中,GMS 都发挥着不可或缺的作用。
IP组播
IP组播(IP Multicasting)是一种网络通信方法,允许数据从一个发送者发送到多个接收者,通过IP网络实现。在群组成员服务(GMS)的背景下,它具有以下特点和限制:
- 支持动态加入/退出群组: IP组播允许参与者动态地加入或退出群组,使得网络中的成员可以根据需要动态地加入或离开特定的通信群体。
- 支持地址扩展: IP组播允许消息通过单一的发送操作传递给一组特定的接收者,而不需要为每个接收者单独发送消息。这种方式可以提高网络效率。
- 不支持故障监控和群组变化通知: 与完整的群组成员服务不同,IP组播不提供故障监控或通知群组变化的功能。这意味着它无法检测网络中的节点故障或通知群组成员的变化。
- 群组成员维护本地视图: 为了实现适应网络成员变化的需求,每个成员维护一个本地视图,记录当前群组的成员信息。这个本地视图允许系统根据群组成员的变化来调整其操作方式,以适应不同的能力集或引入新的功能
Group view
群组视图是当前群组成员的有序列表,每个成员都用其独特的进程标识符来识别。
例如,群组视图可以根据进程加入群组的顺序生成。当发生群组成员的变化时,比如新成员加入或现有成员离开,群组视图会随之而变。这些变化会触发生成新的群组视图,并且在每次成员变化发生时,这些视图会被传递给所有当前的群组成员。
举例来说,考虑一个初始为空的群组g:
- 当一个进程p加入群组时,生成了第一个群组视图v0(g) = {p}。
- 不久之后,另一个进程p’加入群组,生成了群组视图v1(g) = {p, p’}。
- 稍后,p’离开了群组,生成了群组视图v2(g) = {p}。
这些群组视图是由群组成员服务(GMS)在每次发生变化时生成的,并且会被传递给所有当前的群组成员,以确保所有成员都具有相同的视图,了解当前群组的成员情况。这种方式确保了所有群组成员都具有相同的视图,了解当前群组的实时状态。所以,每次成员加入或离开群组时,都会生成一个新的群组视图,而不是更新已有的视图。
View Delivery
群组视图的传递类似于多播消息的传递方式:
- GMS传递视图: 当群组中的成员发生变化时,群组成员服务(GMS)会传递新的群组视图给所有的成员。
- 视图的唯一标识符: 每个群组视图都有一个唯一标识符,通常是一个整数值,用于定义它们的顺序。这个标识符保证了视图之间的顺序关系。
- 成员跟踪下一个视图: 每个成员都会跟踪下一个要接收的群组视图。如果一个成员收到的视图比它预期接收的视图要晚,那么该视图就会被存储在一个等待队列中,直到合适的时机再进行处理。
- 视图传递的实现需满足三个要求:
- 顺序性(Order): 如果进程p接收到视图v(g),然后接收到视图v’(g),则在v(g)之前,没有其他进程q(不等于p)可以在p之前接收到v’(g)。
- 完整性(Integrity): 如果进程p接收到视图v(g),则视图v(g)中必须包含p。也就是说,p是该视图的成员之一。
- 非平凡性(Non-triviality): 如果进程q加入一个群组,并且从进程p(p不等于q)变得永久可达,那么最终q会始终出现在p接收到的视图中。这确保了新加入的成员会被及时地包含在群组视图中。
View-Synchronous Group Com.
群组通信可以通过使用群组视图来进一步增强,以限制接收到的消息是否能够或者应该被传递。
- 群组视图的作用: 使用群组视图可以在系统中建立一个概念性的分界线。每当传递一个新的群组视图时,这条线在系统中划出一个界限。每条消息都必须在这条线的一侧一致地传递。
- 考虑一个包含进程p和q的群组g: 当进程q向群组发送一条消息m后突然崩溃。当进程p从进程q接收到这条消息时,只有在q属于当前群组视图v(g)的情况下,p才会传递消息m。
- 消息传递的限制: 这意味着,只有当消息在p接收并传递新的群组视图之前被p接收到时,消息m才会被传递给p。如果消息m在p接收到新视图之后才到达,它将不会被传递给p。
这种机制确保了消息的一致性,并在群组视图的基础上加以限制,以保证消息的可靠传递。通过使用群组视图,系统可以确保在发生群组成员变化时,消息的传递和处理方式得到正确的控制,从而保持通信的稳定性和准确性。
视图同步群组通信(View-Synchronous Group Communication)提供的额外保证包括:
- 一致性(Agreement):
- 正确的进程会在任何给定的视图中按照相同的顺序传递相同的视图序列和消息集合。
- 完整性(Integrity):
- 如果一个正确的进程p传递了消息m,那么它将不会再次传递m。
- 此外,p属于消息m的群组(group(m)),并且发送m的进程在p传递m的视图中。
- 有效性(Validity):
- 正确的进程始终传递它们发送的消息。
- 如果系统未能将一条消息传递给任何进程q,它会通过传递一个新的视图,将q排除在外,通知存活的进程。
- 这个新的视图会在存活的进程中的任何一个在其传递消息之后的视图中立即被传递。
这些保证确保了系统中消息传递的一致性、完整性和有效性。一致性保证了各个进程看到的视图和消息是相同的,完整性保证了消息不会被重复传递,而有效性则保证了发送的消息最终会被正确地传递给接收方。当某个消息未能被传递时,系统会通过传递新的视图通知其他存活的进程,并及时纠正这个问题。