本组交流和讨论图文演示课件.pptVIP

本组交流和讨论 尹婷： OS Support for General_Purpose Routers 周模： END-TO-END ARGUMENTS IN SYSTEM DESIGN ANTS：A Toolkit for Building and Dynamically Deploying Network Protocols 系统设计中的“端对端”观点 END-TO-END ARGUMENTS IN SYSTEM DESIGN J.H. Saltzer, D.P. Reed and D.D. Clark M.I.T. Laboratory for Computer Science 讨论的问题 在分布式系统中，对于某项功能，放在哪个模块上实现比较好？ 特别是，在通讯系统这一模块中，应该实现哪些功能，不应该实现哪些功能？ Main Contribution 给出一种在分布式环境中，进行系统边界确定时需要考虑的设计原则： “端对端”的设计原则：与应用相关的计算和控制工作是在发送和接收的“端点”进行，网络只完成具有共性的基本处理工作 。 Main Ideas 运用“端对端”的设计原则 人们往往倾向功能实现的底层化，而作者认为将功能放在底层实现，与其付出的代价相比，不一定是最好的选择，性能优劣是参照标准； 端对端观点强调将尽可能多的功能放在通信系统的端点上 。 Main Ideas 最好在通信系统的端点上，而不是系统中间的设备上处理类似安全性、抑制重复消息和从系统故障中恢复这样的功能，因为这些功能仅能在端点上得到完全实现。在中间设备中构建对这些功能的支持可能会增强性能，但它迫使不需要这些功能的应用程序为支持它们而付出代价。随着时间的推移，为了支持过去的应用程序而构建到网络中的优化与现在的应用程序的关联变得越来越少。 可靠的数据传输 主机A上的文件传到主机B上 1、由于磁盘系统的硬件错，A读出的文件可能是错的； 2、程序本身、通讯系统等在缓存、复制数据过程中可能出错； 3、在缓存、复制数据的过程中，处理器和内存可能有瞬态错误； 可靠的数据传输（Cont.） 4、通讯系统可能丢失、改变包中的位，丢包，重发包 5、在整个过程中，主机可能崩溃 决定某个功能是否放在某模块中实现，应该运用“端对端”的设计原则，考察性能。 例如： 一个模块实现了某个功能，多个上层应用需要该模块的支持： 1、因为此模块处于较低的层次，没有足够的信息，最终，功能的实现可能还是需要靠上层应用来完成。 2、上层应用需要该模块的支持，但不需要该模块提供的这项功能——性能损失！ 数据的安全传输 “端对端”的加密 链路加密 VS “端对端”的加密 重发消息 是否是重发的消息，有时只有上层应用能够判断，通讯系统判断不了 例如：远程用户登录一个分时系统，由于无响应，该用户连续登录几次——只有系统本身知道是重发的登录请求； 多主机事务需要检测参与主机是否崩溃或恢复，消息丢失或者延迟会引起重发——只有系统本身的监测程序才能判断是否是重发的消息。 FIFO 分布式应用不能依靠通讯系统提供的消息发送FIFO来保证一个结点发起的事务在多个结点按照正确的顺序执行，必须有一个上层应用来完成这项功能。 事务管理 分布式数据存储系统SWALLOW 支持远程读和写； 读或写消息包含的信息：访问对象、版本、访问类型（读/写）、写入的值（如果是写操作）； 事务管理（Cont.） 底层通讯系统不理会消息是否是重发的。 因为： 1、如果是重复的写请求，SWALLOW系统本身通过请求消息的版本信息就可判断出来； 2、如果是重复的读请求， SWALLOW就产生一个相同的应答，由读请求的发起者判断来自服务器的重复应答。 事务管理（Cont.） 底层通讯系统也不进行发送确认 1、如果是写操作，SWALLOW的上层应用告诉写请求的发起者：写结果已经保存好了； 2、如果是读操作，所读出的值已经足够起到确认的作用。 “端”的确认 依据需求来确认“端” 实时交谈等情况下声音数据流的传输 VS 下载音频文件等情况下声音数据流的传输 开放操作系统 不应该将某项功能的实现永久固定在较低层的模块上，而应该提供一种选择——可以让低层模块实现，也可以让上层应用自己来实现。 通用路由器的OS支持 OS Support for General_Purpose Routers Larry L. Peterson, Scott C. Karlin, and Kai Li Department of Computer Science Princeton University 面对的问题 路由器处理的任务很简单： 基于包的目标地址来转发包。 存在这