北邮计算机网络第二讲体系结构.ppt

  1. 1、本文档共44页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
SDU:服务数据单元 SDU:完成第(N)层服务所需传递的数据单元。 (N)SDU (N)PCI (N)PDU (N)DATA PDU、SDU和IDU三者的关系: 为了传递(N+1)SDU, N实体可能将SDU分成几段,每一段加上一个报头后作为独立的协议数据单元PDU送出。 也可以是多个SDU合成一个PDU。 2.6面向连接服务与无连接服务 动态分配资源。(仅在数据传输 时占用资源。) (2) 不需要通信双方同时活跃 不能防止报文的丢失、重复或失序。 需要 VC标识 CO由表 几乎不受影响 由子网负责 参考模型 电话系统 邮政系统 特点 数据交换之前,首先建立连接,预先 申请资源,使用连接交换数据;数据交 换结束后,释放连接。 可靠性 提供可靠的报文序列服务。 CL 目的地址 的要求 必须提供完整的目的地址。 建立连接阶段,需要完整的目的地址, 数据交换阶段,仅需要连接标识。 适用情况 比较适合于在一定期间内要向同一目的地发送许多报文的情况。 适合于传送少量零星的报文。 分类及 示例 可靠消息流 例:文件传输 可靠字节流 例:远程登录 数据报 例:广播、组播 可靠的数据报 例:挂号信 2.7 服务原语 服务原语: 体系结构中,上层使用下层所提供的服务必须通过与下层交换一些命令,这些命令在OSI中称为服务原语。 四类服务原语 Request 请求原语 源(N+1)实体 ? 源(N)实体 含义: 一个实体希望得到某种操作的服务 Indication 指示原语 目的(N)实体 ?目的(N+1)实体 含义: 通知一个实体,有某个事件发生 Response 响应原语 目的(N+1)实体 ?目的(N)实体 含义: 一个实体响应一个事件 Confirm 证实原语 源(N)实体 ? 源(N+1)实体 含义: 返回对先前请求的响应 原语可以带参数,并且大多数原语都带参数。 1 连接请求的参数可能指明要与哪台机器连接、需要的服务类型和拟在该连接上使用的最大报文长度。 2 连接指示原语的参数可能包含呼叫者标志、需要的服务类型和建议的最大报文长度。如果被呼叫实体不同意呼叫实体所建议的最大报文长度,它可能在响应原语中作出一个反建议,呼叫方可从证实原语中获知它。 例如: T-CONN-REQ T-CONN-REQ(CED-ADDR, CNQ-ADDR) 被叫地址 主叫地址 第二讲 计算机网络的协议及体系结构 主要内容: 协议的概念 体系结构 服务(service)、协议(protocol)、服务访问点(SAP) 多层通信的实质 信息传送单元 PDU、SDU和IDU 面向连接服务与无连接服务 服务原语 OSI模型中各层的功能 2.1 协议的概念 协议: 在计算机网络中,为进行数据交换而建立的规则、标准或约定。 协议的三个要素: (1)语法: 数据与控制信息的结构或格式; (2)语义:需要发出何种控制信息,完成何种动作以及做出何种应答; (3)同步: 即事件实现顺序的详细说明。 举例: F Info C A F FCS 8 bit 16 > 0 8 8 8 Check field Transparent transfer field HDLC的帧结构 t 从 主 机 取 数 据 上 交 主 机 DATA1 DATA2 结点A 结点B ACK ACK 数据链路层协议 协议很复杂 协议必须将各种不利的条件事先都估计到,而不能假定一切情况都是很理想和很顺利的。 必须非常仔细地检查所设计协议能否应付所有的不利情况。 应当注意:事实上难免有极个别的不利情况在设计协议时并没有预计到。在出现这种情况时,协议就会失败。因此实际上协议往往只能应付绝大多数的不利情况。 著名的协议举例 占据两个山顶的蓝军与驻扎在这山谷的白军作战。力量对比是:一个山顶上的蓝军打不过白军,但两个山顶的蓝军协同作战就可战胜白军。一个山顶上的蓝军拟于次日正午向白军发起攻击。于是发送电文给另一山顶上的友军。但通信线路很不好,电文出错的可能性很大。因此要求收到电文的友军必须发送确认电文。但确认电文也可能出错。试问能否设计出一种协议,使得蓝军能实现协同作战因而一定(即100 %)取得胜利? 明日正午进攻,如何? 同意 收到“同意” 收到:收到“同意” … … … … … … 这样的协议无法实现! 结论 这样无限循环下去,两边的蓝军都

文档评论(0)

Epiphany + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档