服务原语相关知识汇编

“服务”在形式上是用一组原语来描述的,这些原语供用户实体访问该服务或向用户实体报
某事件的发生。服务原语可以划分为如表1 - 3所示的4类。
服务原语
原 语 意 义
请求(R e q u e s t) 用户实体要求服务做某项工作
指示(I n d i c a t i o n) 用户实体被告知某事件发生
响应(R e s p o n s e) 用户实体表示对某事件的响应
确认(C o n f i r m) 用户实体收到关于它的请求的答复
第1类原语是“请求”(r e q u e s t)原语,服务用户用它促成某项工作,如请求建立连接和发送
据。服务提供者执行这一请求后,将用“指示”(i n d i c a t i o n)原语通知接收方的用户实体。例
,发出“连接请求”(C O N N E C T _ r e q u e s t)原语之后,该原语地址段内所指向的接收方的对等
体会得到一个“连接指示”(C O N N E C T _ i n d i c a t i o n)原语,通知它有人想要与它建立连接。接
到“连接指示”原语的实体使用“连接响应”(C O N N E C T _ r e s p o n s e)原语表示它是否愿意接
建立连接的建议。但无论接收方是否接受该请求,请求建立连接的一方都可以通过接收“连接
认”(C O N N E C T _ c o n f i r m)原语而获知接收方的态度(事实上传输层以及其他层的服务用户要
绝建立连接请求不是采用C O N N E C T _ r e s p o n s e原语而是采用D I S C O N N E C T _ r e q u e s t原语)。
原语可以带参数,而且大多数原语都带有参数。“连接请求”原语的参数可能指明它要与哪
机器连接、需要的服务类别和拟在该连接上使用的最大报文长度。“连接指示”原语的参数可
包含呼叫者的标志、需要的服务类别和建议的最大报文长度。如果被呼叫的实体不同意呼叫
体建立的最大报文长度,它可能在“连接响应”原语中提出一个新的建议,呼叫方会从“连
接确认”原语中获知。这一协商过程的细节属于协议的内容。例如,在两个关于最大报文长度
的建议不一致的情况下,协议可能规定选择较小的值。
服务有“有确认”和“无确认”之分。有确认服务,包括“请求”、“指示”、“响应”和
“确认”4个原语。无确认服务只有“请求”和“指示”两个原语。建立连接的服务总是有确认
服务,可用“连接响应”作肯定应答,表示同意建立连接;或者用“断连请求”
(D I S C O N N E C T _ r e q u e s t)表示拒绝,作否定应答。数据传送既可以是有确认的也可是无确认的,
这取决于发送方是否需要确认。
为了使服务原语的概念更具体化一些,我们将考查一个简单的面向连接服务的例子。它使
用了下述8个服务原语:
1) 连接请求:服务用户请求建立一个连接。
2) 连接指示:服务提供者向被呼叫方示意有人请求建立连接。
3) 连接响应:被呼叫方用来表示接受建立连接的请求。
4) 连接确认:服务提供者通知呼叫方建立连接的请求已被接受。
5) 数据请求:请求服务提供者把数据传至对方。
6) 数据指示:表示数据的到达。
7) 断连请求:请求释放连接。
8) 断连指示:将释放连接请求通知对等端。
在本例中,连接是有确认服务(需要一个明确的答复),而断连是无确认的(不需要应答)。
与电话系统作一比较,也许有助于理解这些原语是如何应用的。请考虑一下打电话邀请你的姑
姑到家来喝茶的步骤:
1) 连接请求:拨姑姑家的电话号码。
2) 连接指示:她家的电话铃响了。
3) 连接响应:她拿起电话。
4) 连接确认:你听到响铃停止。
5) 数据请求:你邀请她来喝茶。
6) 数据指示:她听到了你的邀请。
7) 数据请求:她说她很高兴来。
8) 数据指示:你听到她接受邀请。
9) 断连请求:你挂断电话。
10) 断连指示:她听到了,也挂断电话。
用一系列服务原语来表示上述各步。每一步都涉及其中一台计算机内两层之间的信息
交换。每一个“请求”或“响应”稍后都在对方产生一个“指示”或“确认”动作。本例中服
务用户(你和姑姑)在N + 1层,服务提供者(电话系统)在N层。
服务和协议常常被混淆,而实际上二者是迥然不同的两个概念。为此我们再强调一下两者
的区别。服务是网络体系结构中各层向它的上层提供的一组原语(操作)。尽管服务定义了该层
能够代表它的用户完成的操作,但丝毫也未涉及这些操作是如何实现的。服务描述两层之间的
接口,下层是服务提供者,上层是服务用户。而协议是定义同层对等实体间交换帧、数据包的格式和意义的一组规则。网络各层实体利用协议来实现它们的服务。只要不改变提供给用户的
服务和接口,实体可以随意地改变它们所使用的协议。这样,服务和协议就完全被分离开来。
在O S I参考模型之前的很多网络并没有把服务从协议中分离出来,造成网络设计的困难,现在人
们已经普遍承认这样的设计是一种重大失策。


服务原语

  用户和协议实体间的接口,实际上是一段程序代码,但其具有不可分割性。通过服务原语能实现服务用户和服务提供者间的交流,与协议不同的是,服务原语用于服务提供者与服务用户,而协议是用于服务用户之间的通信。
  在同一开放系统中,(N+1)实体向N实体请求服务时,服务用户和服务提供者之间要进行交互,交互信息称为服务原语
  四种基本原语:
  请求(Request) 用户实体要求服务做某项工作 源(N+1)实体—>源(N)实体
  指示(Indication) 用户实体被告知某事件发生 目的(N)实体—>目的(N+1)实体
  响应(Response) 用户实体表示对某事件的响应 目的(N+1)实体—>目的(N)实体
  确认(Confirm) 用户实体收到关于它的请求的答复 源(N)实体—>源(N+1)实体


OSI 服务原语 

    在OSI环境中,服务原语是层服务被引用的工具。服务原语由原语名和原语参数两部分组成(类似编程时的程序调用和参数传递)。服务原语主要分为两大类:
(1)无确认的原语类型:发出的请求原语无需对方予以确认。
    XXXX.REQ   -->       XXXX.IND

(2)有确认的原语类型:发出的请求原语要求得到确认。
    XXXX.REQ   -->    XXXX.IND

    XXXX.CNF   <--    XXXX.RSP

 或:
    XXXX.REQ   -->    XXXX.IND
    XXXX.CNF   <--    XXXX.CNF                            

    由于各个层次可以相对独立开发,因此服务原语也确定了层次之间的接口。 上邻层利用服务原语来通知下邻层要做什么; 下邻层利用服务原语来通知上邻层已做了什么。



  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值