[互联网]03-进程间通信.pptVIP

客户—服务器通信 超时 一旦超时，返回服务器故障，很少这样处理。 doOperation发出多次请求都超时，则返回异常 重复的请求 根据超时处理的约定，服务器可能接到重复的请 求，因此协议设计成通过检查请求ID，过滤来自同一个client的重复请求。 如果服务器还没有发送应答，则完成操作后发送应答。 客户—服务器通信 应答信息丢失 如果已经发送应答，再次执行操作，获得结果。 注意，在这种情况下需要实现幂等操作，例如，往一个集合中增加元素 ，相反，在一个 队列后面增加数据项增不是幂等操作。 保留历史 服务器保留已发送的应答消息的记录，避免重 复操作 保留多少历史？如果服务器只想保留一个结 果，只要客户端一次发一个请求即可。 如果为大量的客户服务，即使保留一个结果也 很大负担。 定期清理。 客户—服务器通信 RPC Exchange Protocal The request protocol（RP） 不需要返回，不需要确认的情况 The request-reply protocol（RRP） 大多数客户服务器模式使用，不需要确认，因为服务器应答可作对客户请求的确认，而客户的下一请求被看作是对应 答的确认。 The request-reply-acknowledge replay protocol（RRAP） 确认可以使server端丢弃一些保留的记录，节省存储开销。 客户—服务器通信 在TCP上实现RRP 成本高，但是不需要处理重发和过滤 的情况 连续的请求和应答可以使用同一个 流，以减少建立连结的成本 课堂讨论 进程间交换信息的数量往往比传送的数据总量 对性能的影响更大。交换信息的时间 = A + B A=进程处理消息的时间（固定的） B =网络传输率×消息的长度。 A比B更大，因为进程处理消息在客户端和服 务器都要进行 。 ? 例如：发送数据要涉及系统调用，接收到 消息需要读缓冲区,判断是否重发等等。如 果一个协议涉及的多轮消息的交换，会导 致A增大，而使整体性能的下降。 试着改进以下现有的RRA协议，减少消息的传 输。 课堂讨论 Client Server 取消未发出去的确认消息 课堂讨论  发送请求捎带上一次确认  接受请求 发送应答  client request 1 reply 1 request 2  server 接受应答 设置时间，延迟T时间后 发出确认  接收到确认 第3章 进程间通信 引言 Internet协议的API 外部数据的表示和编码 客户—服务器通信 组通信 实例介绍 总结 组通信 使用组通信的场合 组播（multicast) 协同操作，例如：视频会议，聊天室 事件通知（event notification） 例如：jini系统的查找服务就是利用多播让有兴趣的用 户知道它的存在。 利用副本提供容错服务 客户的请求被组播到一组副本对象上，所有副本做相 同的操作 利用副本提供更好的性能 有更多的数据可以访问，实现负载平衡。例如：Web Cache. 数据更新时利用组播将新的数据通知各个副本 在自组织网络中发现服务 向周围一组服务器地址发送，寻找发现服务 组通信 IP Multicast –组通信的实现方案 D类IP地址可以定义多播地址 组的成员是动态的 IPv4 多播路由器 本地网络的广播 MTTL – 规定多播消息可以经过的路由器的数量 多播地址的范围 永久的组 – 224.0.0.1 to 224.0.0.255 临时的组 –其它地址，将 TTL设为较小的值 故障模型: 不可靠的多播 应用层多播 第3章 进程间通信 引言 Internet协议的API 外部数据的表示和编码 客户—服务器通信 组通信 总结 总结 两种不同的通信模块 Datagram Socket: based on UDP, efficient but suffer from failures Stream Socket: based on TCP, reliable but expensive 编码解码 CORBA’s CDR(common data representation) and Java serialization RRP协议 Base on UDP or TCP 多播 IP 多播是简单的多播协议 END 第3章 进程间通信 第3章 进程间通信 引言 Internet协议的API 外部数据的表示和编码 客户—服务器通信 组通信 总结 引言 进程间的通信 在通信双方的进程维护着消息队列， 发 送进程将消息先放到发送方缓冲区，并 通过通信信道到达目的主机的接收的缓 冲区，接受进程从缓冲区取出数据。 引言 两个传输层的协议： UDP：进程间通信的最简单的形式。 每次发送一个独立的报文包，每个报 文包都带