第6章组通信(免费阅读).pptVIP

第6章 组通信 在前面几章中,我们介绍了进程间通信IPC机制用于两个进程间实现信息交换的情况.本章将介绍一组进程之间的IPC问题,也称为组通信. 6.1 单播和组播的比较 在前面已讨论过的IPC中,数据从源进程(发送者)发送到某个目标进程(接收者).这种形式的IPC称作单播,即将信息发送到耽搁接收者,与之相对的组播则是将信息发送个多个接收者.单播提供一对一IPC;组播支持一对多IPC,请参见图6.1. 单播IPC和组播IPC比较 尽管大多数网络服务和网络应用都使用单播IPC,但组播在即时消息、群体、在线会议，交互式远程学习等应用中非常有用，它也可用于实时在线拍卖等应用。组播也非常适合用于出于容错目的而进行的服务复制。 服务复制指维护某项服务的多个副本。在发生失败时增强服务可用性的常用技术是复制数据和支持服务的系统。 容错指一项应用在一定范围内允许系统出现故障的能力。 在采用了组播技术的应用网络中，一组进程形成一个组播组。组内的每个进程都可以发送和接收消息。组内任何一个进程发送的消息都可以被组内其他所有的参与进程接收到。进程也可以选择离开组播组。 在网络会议等应用中，一组进程利用组播技术实现互操作，交换音频，视频和/或文本数据。 如前所述，本章将集中与服务层，特别是针对应用的IPC机制。 6.2 组播API原型 支持组播功能应用的应用程序接口必须提供下列基本操作： （1）加入。 该操作允许一个进程加入某个特定的组播组。已加入组播组的进程成为该组的成员，并有权接收所有发往该组的组播消息。在某一时刻，一个进程可以同时是一个或多个组播组的成员。注意，对该操作及其他组播操作，需要有一种命名方案，来唯一地标识每个组播组。 （2）离开。 该操作允许一个进程退出组播组。离开组播组的进程不再是该组播组的组成员，并且从此以后无法接收任何发往该组的组播消息，但该进程仍然可以是其他组播组的成员。 （3）发送。 该操作允许进程向当前参与该组播的所有进程发送消息。 （4）接收。 该操作允许组成员进程接收发往该组播组的消息。 在6.5节中，我们将介绍Java的组播API及使用该API的示例程序，届时，读者将看到如何使用Java语法提供这些基本操作。但在介绍该内容前，我们将先探讨一些与组播相关的热点主题。这些主题来源于组播的一对多的特性。 6.3 无连接及面向连接组播 基本的组播机制是无连接的。如果能考虑到组播的一对多通信特征，那么其原因就不言自明了。在一个由n个进程组成的组中，如果在一个发送者与同一组内其他的每个进程都建立一个连接，那么总共需要n-1个连接。此外，n个进程中任一进程都可能是发送者，因此每个进程都要维护到所有其他进程的连接，最终总共需要n*(n-1)或大约n*n个连接。如果n-1非常大，连接总数数将非常之大。 此外，无连接IPC适合于一种常用的组播应用：那些需要进程见实时传输音频或视频数据的应用（这里所说的实时数据传输，指发送和接收之间的延迟应接近0）。当传输音频或视频数据时，采用无连接通信后的延迟降低超过了面向连接通信所带来的优点。例如，当发送动画数据时，接收者更容易容忍偶尔丢帧引起的图像失真（在无连接通信中可能发生），但不愿意经历连续帧之间可察觉到的延迟（这在面向连接通信中，是可能发生的）。 延迟纸数据传输的延时。 6.4 可靠组播及非可靠组播的比较 进程发送组播消息时，组播机制的运行时支持负责将消息传递给组播组的所有当前成员。由于进程可能驻留于不同主机上，消息传递需要独立运行于这些系统上的协作机制提供支持。由于存在网络链路失败、网络主机的缺陷、路由延迟、软硬件差异等因素，不同接收者在发送和接收单播消息之间的时间差不同。对于地理位置相近的不同主机来说，在向他们传递消息时时间差不会很大，但如果他们散布于广域网上时，情况就不同了。 此外，由于网络、主机或者运行时支持的错误和/或失败，消息也可能根本不会被一个或者多个进程接收。 有些应用（如视频会议）能容忍偶尔消息丢失或乱序，但也有一些应用（如数据库应用）无法接受这些异常情况。 因此，在应用中使用组播机制时，选择适合该应用特征的传输机制非常重要。否则，就需要在应用逻辑中提供一定的措施，来处理消息传递中可能发生的异常。由于该原因，有必要根据消息传递特征对组播机制进行分类。 6.4.1 非可靠组播 组播系统的最基本功能是尽力将消息传递给每个参与进程，但不保证消息能正确传递到每个进程。因而进程发送的任何消息可被零个或多个进程接收。在最佳情形下，消息可以正确无误地被所有进程接收。在最坏情形下，没有一个进程能正确接收到消息。在其他情况下，消息可被部分进程（而不是所有进程）接收，或者部分进程可