IM通讯协议总结之三SIMPLE协议

2.SIMPLE协议

SIMPLE(SIP Instant Messaging and Presence LeveragingExtensions)是SIP的扩展协议,其资料找到一篇中文的文档及一篇RFC3428文档,中文的文档主要讲是对SIMPLE协议的presence介绍,FC3428主要讲对SIP扩展的即时通讯的介绍。

通过查找资料得知应用此协议的软件:原MSN版本4(现已无法使用),无法抓取SIMPLE协议的数据包;外国软件Bria,可以使用,但只能抓取打电话的SIP协议数据包,其它通讯聊天及视频会议的情景需要付费才能使用,因此也未抓取到数据包。

下面从Presence与InstantMessage两个模块介绍SIMPLE协议。

2.1.基于 SIMPLE 协议的Presence 介绍

“presence”,也作“presenceinformation”,中文一般译为“呈现”,用以传达某一用户通过一组设备进行通信的能力和意愿。拿常见的MSN Messenger来举例,MSN v7.5为用户提供的可选状态有:联机、忙碌、马上回来、离开、接听电话、外出就餐和显示为脱机。这些状态便称为“presence 状态”,它们表征了用户当前处于的某种状态和用户进行通信的意愿。同时,这些状态还反映出与该用户进行通信的能力,比如若用户处于“脱机”状态的话,别的用户便不能用即时消息与之通信。因此,一个最简单的presence过程如下:一个用户(称为watcher)订阅(SUBSCRIBE)他感兴趣的另一用户(presentity)的presence状态,presentity接受订阅请求。以后presentity的状态发生变化之后他会发布(PUBLISH)自己的新状态,这个新状态会通知(NOTIFY)给watcher。(注:watcher、presentity等概念严格上来说指网络中的通信实体,这里为了解释方便将他们进行了扩展,也泛指人)

2.1.1基于 SIMPLE 协议的 presence 体系结构

SIMPLE 符合 RFC2778 提出的 presence 模型,其结构图如下:

各实体功能如下:

Presence Service:接收、存储和分发presence information。Presence Service既可以是一个物理实体上的server,也可以只是presentity和watcher之间的直接通信。在具体实现中前者比较常见,后者是P2P的模式。

Presentity:用于提供presence information给Presence Service。

Watcher:向Presence Service请求获取Presentity的presence information或自身的watcher information。

Principal:指单个的人、程序或者设备,也可以是人、程序、设备的集合体。对于Presence Service 来说,各个Principal是不同的。

Presence User Agent:为Principal提供手段来操作0个或者多个Presentity,Principal操作Presence User Agent改变Presentity的状态。是Principal和Presentity交互的interface。

Watcher User Agent:类似Presence User Agent,Principal通过其来操作0个或多个Watcher,Watcher收到Presentity的新状态之后也通过Watcher User Agent呈现给Principal。

Presence Protocol:定义了Presentity和Presence Service,Watcher和Presence Service之间交换消息的一组标准。

2.1.2消息流程

情景设定:

假设本 presence 系统的域名是“cintel.net.cn”,系统中有一下几个实体:

Presence Server:系统中的presence服务器。负责接收和处理所辖域内用户的 订阅、发布状态请求;通知用户其订阅的状态信息发生改变;处理添加和删除好友;处理添加和删除黑白名单;管理维护所辖域内用户数据等。其 SIP-URI 为“sip:ps.cintel.net.cn”,FQDN为“ ps.cintel.net.cn”

A:代表用户A。在网络中是一个终端(可以是软终端或者硬终端),集watcher和presentity实体功能于一身。用于向Presence Server发送订阅(SUBSCRIBE)别的用户状态的请求;自己状态发生变化时向PresenceServer发布(PUBLISH)新的状态;接收和处理Presence Server发来的状态通知(NOTIFY);利用XCAP协议发送和接收添加删除好友、黑白名单的请求和响应等。其在系统中的AOR为“sip:[email protected]”,FQDN为“ a.cintel.net.cn”。

B:与A类似,AOR为“sip:[email protected]”,FQDN为“b.cintel.net.cn”。

C:与A类似,AOR为“sip:[email protected]”,FQDN为“c.cintel.net.cn”。

由于pidf只定义了基本的状态,如basic元素中的“open”和“close”两种状态(前者表示当前的通信状态可用(最常见的就是表示可以发送即时消息),后者表示当前的通信状态不可用),详细一点的状态信息比如“busy”、“away”等没有明确规定。要表示这种状态由具体实现决定,一般都是进行扩展,如teltel是在note元素中表达这种信息。另外,rpidf对pidf进行了扩展,提供丰富的各种信息。此文档中在PIDF的“status”元素下扩展“im”元素,来表示具体的状态(假设有“联机”、“忙碌”、“离开”和“显示为脱机”四种状态,对应的im元素值分别为“online”、“busy”、“away”

2.1.2.1订阅好友列表

2.1.2.1.1情景说明

A拥有且仅拥有B和C两位好友,也就是说A有权订阅B和C的状态信息。终端A启动,向Presence Server发送订阅其好友列表的请求(好友列表URI格式为“sip:[email protected]”)。假设B一开始处于不在线状态,C至始至终处于“open”状态。PresenceServer经过验证将B和C的状态信息通知A。一段时间后B登陆,其状态发生了变化,于是B向Presence Server发布其新状态。Presence Server处理之后将B的新状态通知A,A处理之后会正确显示出B的新状态。在每次订阅超时之前A会重新发送一个订阅请求刷新他的订阅。A退出,向Presence
Server发送取消订阅的请求,Presence Server接收并发送最后一次状态通知。

2.1.2.1.2 SIP消息流程图

2.1.2.1.3消息流说明

1、A 启动,向Presence Server发送订阅其好友列表状态的请求。

M1消息如下:

SUBSCRIBE[D1]  sip:[email protected]ps.cintel.net.cn[D2] SIP/2.0[D3]

Via[D4] :SIP/2.0/UDP[D5] a.cintel.net.cn[D6] ;
branch=z9hG4bKwYb6QREiCL

Max-Forwards:70[D7]

To: <sip:[email protected] >[D8]

From:<sip:[email protected]>;[D9] tag=ie4hbb8t[D10]

Call-ID:[email protected][D11]

CSeq: 1SUBSCRIBE[D12]

Contact:<sip:a.cintel.net.cn>[D13]

Event:presence[D14]

Expires:3600[D15]

Supported:eventlist[D16]

Accept:application/pidf+xml

Accept: application/rlmi+xml

Accept: multipart/relate[D17]

Content-Length:0[D18] 

2、向A发送“200 OK”,表明此次订阅已经得到 验证和授权,订阅操作成功。

M2消息如下:

SIP/2.0 200 OK

Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCL

To: < sip:[email protected] >;tag=zpNctbZq

From: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 1 SUBSCRIBE

Contact: <sip:ps.cintel.net.cn>

Expires: 3200

Require:eventlist[D19]

Content-Length: 0

 

3、根据RFC 3265的要求,Presence Server在返回一个针对SUBSCRIBE的200 OK响应之后会立即给A发送NOTIFY通知其已经知道的好友的状态。

M3 消息如下:

NOTIFY [D20] sip:a.cintel.net.cn SIP/2.0

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmm

Max-Forwards: 70

From: <sip:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 5768 NOTIFY

Contact:<sip:ps.cintel.net.cn>

Event: presence

Subscription-State[D21] : active;expires=3200

Require: eventlist

Content-Type: multipart/related;type="application/rlmi+xml";

start="<[email protected]>";

boundary="50UBfW7LSCVLtggUPe5z"

Content-Length: 1560

--50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding:binary[D22]

Content-ID: <[email protected] ps.cintel.net.cn >

Content-Type:application/rlmi+xml;charset="UTF-8"[D23]

<?xml version="1.0" encoding="UTF-8"?>

<list xmlns="urn:ietf:params:xml:ns:rlmi"

uri="sip:[email protected]"

version="1" fullState="true">

<name language="en">Buddy List of A</name>

<name language="de">Liste der Freunde of A</name>

<resource uri="sip:[email protected]">

<name>B</name>

<instance id="juwigmtboe" state="active"

cid="[email protected]"/>

</resource>

<resource uri="sip:[email protected]">

<name>C</name>

<instance id="hqzsuxtfyq" state="active"

cid="[email protected]"/>

</resource>

</list>

--50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected]>

Content-Type: application/pidf+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="sg89ae">

<status>

<basic>closed</basic>

<im>offline[D24] </im>

</status>

</tuple>

</presence>

--50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected]>

Content-Type: application/pidf+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="slie74">

<status>

<basic>open</basic>

<im>online[D25] </im>

</status>

<contactpriority="1.0">sip:[email protected]</contact>

</tuple>

</presence>

--50UBfW7LSCVLtggUPe5z—

 

4、A收到NOTIFY之后进行处理,将B和C的状态正确显示出来,并返回“200 OK”完成NOTIFY 事务。M4 消息如下:

SIP/2.0200 OK

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmm

From: <sip:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 5768 NOTIFY

Contact: <sip:a.cintel.net.cn>

Content-Length: 0

5、一段时间后B登陆,B向Presence Server发布其新的状态信息。类似于SUBSCRIBE方法, PUBLISH(PUBLISH不创建dialog)也要头字段Expires和Event。比较特殊的是PUBLISH中不包含Contact头字段。M5 消息如下:

PUBLISH [D26] sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bK652hsge

Max-Forwards: 70

To: <sip:[email protected]>

From: <sip:[email protected]>;tag=1234wxyz

Call-ID: [email protected]

CSeq:1 PUBLISH

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: 224

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="slie74">

<status>

<basic>open</basic>

<im>online</im>

</status>

</tuple>

</presence>

6、Presence Server收到PUBLISH请求之后将B的新状态保存在数据库中,并返回200响应。类似于SUBSCRIBE,也包含一个Expires头字段,用法也一 样。另外,此200响应中还应该有一个SIP-ETag 头字段,用来标识和验证B的下一次 PUBLISH。

M6消息如下:

 SIP/2.0 200 OK

Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bK652hsge

To: <sip:[email protected]>;tag=1a2b3c4d

From: <sip:[email protected]>;tag=1234wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 3200

SIP-ETag:dx200xyz[D27]

Content-Length: 0

7、Presence Server将B的新状态NOTIFY给A。此NOTIFY既可以包含全部好友的状态信息,也可以只包含状态发生变化的好友的状态信息,这里采用的 是后者。

M7消息如下:

 NOTIFY sip:a.cintel.net.cn SIP/2.0

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmn

Max-Forwards: 70

From: <sip:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 5769 NOTIFY

Contact: <sip:ps.cintel.net.cn>

Event: presence

Subscription-State:active;expires=2000

Require: eventlist

Content-Type: multipart/related;type="application/rlmi+xml";

start="<[email protected]>";

boundary="60UBfW7LSCVLtggUPe5z"

Content-Length: 1560

--60UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected] ps.cintel.net.cn >

Content-Type: application/rlmi+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<list xmlns="urn:ietf:params:xml:ns:rlmi"

uri="sip:[email protected]"

version="2" fullState="false">

<name language="en">Buddy List of A</name>

<name language="de">Liste der Freunde of A</name>

<resource uri="sip:[email protected]">

<name>B</name>

<instance id="juwigmtbof" state="active"

cid="[email protected]"/>

</resource>

</list>

--60UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected]>

Content-Type: application/pidf+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="sg89af">

<status>

<basic>open</basic>

<im>online</im>

</status>

</tuple>

</presence>

--60UBfW7LSCVLtggUPe5z

8、A收到NOTIFY之后将 B 的新状态显示出来,并返回 200 完成 NOTIFY 事 务。

M8 消息如下:

 SIP/2.0 200 OK

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmn

From: <sip:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 5769 NOTIFY

Contact: <sip:a.cintel.net.cn>

Content-Length: 0

9、一段时间之后, A 为了防止对好友列表的订阅超时而失效,再次发了一个带 Expires 头字段的 SUBSCRIBE,以刷新前一次订阅,注意这个SUBSCRIBE 仍要在前一个创建的对话(dialog)中。

M9 消息如下:

 SUBSCRIBE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCM

Max-Forwards: 70

To: < sip:[email protected] >;tag=zpNctbZq

From: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 2 SUBSCRIBE

Contact: <sip:a.cintel.net.cn>

Event: presence

Expires: 3600

Supported: eventlist

Accept: application/pidf+xml

Accept: application/rlmi+xml

Accept: multipart/related

Content-Length: 0

10、Presence Server收到SUBSCRIBE请求之后经判断得知是一个刷新订阅的请求,再次根据presence rules授权并选取适当的Expires值后返回给 A 一个 200 响应。

M10 消息如下:

 SIP/2.0 200 OK

Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCM

To: < sip:[email protected] >;tag=zpNctbZq

From: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 2 SUBSCRIBE

Contact: <sip:ps.cintel.net.cn>

Expires: 3200

Require:eventlist

Content-Length: 0

11、 Presence Server 立即返回 NOTIFY 通知 A 当前其全部好友的 presence 状态。

M11 消息如下:

NOTIFYsip:a.cintel.net.cn SIP/2.0

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmo

Max-Forwards: 70

From: <sip:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 5770 NOTIFY

Contact: <sip:ps.cintel.net.cn>

Event: presence

Subscription-State: active;expires=3200

Require: eventlist

Content-Type: multipart/related;type="application/rlmi+xml";

start="<[email protected]>";

boundary="70UBfW7LSCVLtggUPe5z"

Content-Length: 1560

--70UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected] >

Content-Type: application/rlmi+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<list xmlns="urn:ietf:params:xml:ns:rlmi"

uri="sip:[email protected]"

version="3" fullState="true">

<name language="en">Buddy List of A</name>

<name language="de">Liste der Freunde of A</name>

<resource uri="sip:[email protected]">

<name>B</name>

<instance id="juwigmtbog" state="active"

cid="[email protected]"/>

</resource>

<resource uri="sip:[email protected]">

<name>C</name>

<instance id="hqzsuxtfyh" state="active"

cid="[email protected]"/>

</resource>

</list>

--70UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding:binary

Content-ID: <[email protected]>

Content-Type: application/pidf+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="sg89ag">

<status>

<basic>open</basic>

<im>online</im>

</status>

</tuple>

</presence>

--70UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected]>

Content-Type: application/pidf+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="slie76">

<status>

<basic>open</basic>

<im>online</im>

</status>

<contactpriority="1.0">sip:[email protected]</contact>

</tuple>

</presence>

--70UBfW7LSCVLtggUPe5z—

12、A 收到 NOTIFY 消息之后刷新所有好友的 presence 状态并返回 200 响应完成 NOTIFY 事务。

M12 消息如下:

 SIP/2.0 200 OK

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmo

From: <sip:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 5770 NOTIFY

Contact: <sip:a.cintel.net.cn>

Content-Length: 0

 

13、 后来, A 终端退出,会触发一个取消订阅的请求,在 SIMPLE 中这是通过置 Expires 头字段值为 0 来完成的。此 SUBSCRIBE 仍属于第一个创建的对话 (dialog)。

M13 消息如下:

 SUBSCRIBE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCN

Max-Forwards: 70

To: < sip:[email protected] >;tag=zpNctbZq

From: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 3 SUBSCRIBE

Contact: <sip:a.cintel.net.cn>

Event: presence

Expires: 0

Supported: eventlist

Accept: application/pidf+xml

Accept: application/rlmi+xml

Accept: multipart/related

Content-Length: 0

14、Presence Server 接受取消订阅的请求,向A返回Expires值为 0 的 200 响应。

M14 消息如下:

SIP/2.0200 OK

Via: SIP/2.0/UDP a.cintel.net.cn; branch=z9hG4bKwYb6QREiCN

To: < sip:[email protected] >;tag=zpNctbZq

From: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 3 SUBSCRIBE

Contact: <sip:ps.cintel.net.cn>

Expires: 0

Require: eventlist

Content-Length: 0

15、Presence Server 会给 A 发最后一次 NOTIFY,通知其所有好友的状态,并且 Subscription-State 的 expires 参数值设为 0,表示订阅有效时间已经结束,这 是最后一次 presence 状态发布。

M15 消息如下:

NOTIFYsip:a.cintel.net.cn SIP/2.0

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmp

Max-Forwards: 70

From: <sip:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 5771 NOTIFY

Contact: sip:ps.cintel.net.cn

Event:presence

Subscription-State: active;expires=0

Require: eventlist

Content-Type: multipart/related;type="application/rlmi+xml";

start="<[email protected]>";

boundary="80UBfW7LSCVLtggUPe5z"

Content-Length: 1560

--80UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected] >

Content-Type: application/rlmi+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<list xmlns="urn:ietf:params:xml:ns:rlmi"

uri="sip:[email protected]"

version="4" fullState="true">

<name language="en">Buddy List of A</name>

<name language="de">Liste der Freunde of A</name>

<resource uri="sip:[email protected]">

<name>B</name>

<instance id="juwigmtboh" state="active"

cid="[email protected]"/>

</resource>

<resource uri="sip:[email protected]">

<name>C</name>

<instance id="hqzsuxtfyi" state="active"

cid="[email protected]"/>

</resource>

</list>

--80UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected]>

Content-Type: application/pidf+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="sg89ah">

<status>

<basic>open</basic>

<im>online</im>

</status>

</tuple>

</presence>

--80UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected]>

Content-Type: application/pidf+xml;charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="slie77">

<status>

<basic>open</basic>

<im>online</im>

</status>

<contact priority="1.0">sip:[email protected]</contact>

</tuple>

</presence>

--80UBfW7LSCVLtggUPe5z—

16、 A 收到最后一个 NOTIFY 之后返回 200 完成 NOTIFY 事务。

M16 消息如下:

SIP/2.0 200 OK

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKMgRenTETmp

From: <sip:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

CSeq: 5771 NOTIFY

Contact: <sip:a.cintel.net.cn>

Content-Length: 0

2.1.2.2订阅单个用户(添加好友)

2.1.2.2.1情景说明

A 想添加 B 为好友,向 B 发起一个订阅 presence 状态的请求。 B 在线,且接受 了 A 的请求。于是, A 成功将 B 加为好友并且能够观察 B 的 presence 状态信息。

2.1.2.2.2SIP消息流程图

2.1.2.2.3消息流说明

注:上图中M开头的是SIP消息,H开头的是HTTP消息。验证(authentication)没有包含在内。 假设之前代表 A 的好友列表的 resource-list的document已经和维护所有列表资源 的 rls-resources 的 document 已经关联好。存储在服务器端的这两个document 内容如下( XCAP root 为“ http://ps.cintel.net.cn”):

Content ofresource-list document:

 <?xml version="1.0"encoding="UTF-8"?>

<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<list name="buddies">

<entryuri="sip:[email protected]">

<display-name>C</display-name>

</entry>

</list>

</resource-lists>

Content ofrls-resources document:

<?xmlversion="1.0" encoding="UTF-8"?>

<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"

xmlns:rl="urn:ietf:params:xml:ns:resource-lists"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<service uri="sip:[email protected]">

<resource-list>http://ps.cintel.net.cn/resource-lists/users/A/buddies.xml/~~/

resource-lists/list%[email protected]=%22buddies%22%5d</resource-list>

<packages>

<package>presence</package>

</packages>

</service>

</rls-services>

注:上面的内容虽然表示的时候用的是 XML 格式,并且术语上还说存在 document 中,但是这个 document 是广义的,不仅仅指一个文本文档,事实上,一般来说 这种信息都是存储在数据库中的,这就需要一个将 XML 数据映射到数据库数据 的过程。

1、A 想添加 B 为好友,将 B 添加到其本地好友列表中,同时产生一个 SUBSCRIBE 消息发送给 Presence Server。此外, A 还会向 Presence Server 发 送一个基于 XCAP 协议的 HTTP 消息 PUT,用来添加 B 到服务器端的好友 列表中以保持两边的列表信息同步。

H1 消息如下:

 PUT

/resource-lists/users/A/buddies.xml

/~~/resource-lists/list%[email protected]=%22buddies%22%5d/entry HTTP/1.1

Content-Type:application/xcap-el+xml

Host: ps.cintel.net.cn

<entry uri="sip:[email protected]">

<display-name>B</display-name>

</entry>

2、 Presence Server 收到“H1: PUT”之后,将B添加到A的好友列表中。收到“ M1:SUBSCRIBE”后,检查B的presence rules,得知对来自 A 的订阅的本地策略未知,于是在 A 的好友列表中将B的订阅状态设置为“ pending”, 并且返回“ 202 Accepted”,表示收到订阅请求并被理解,但是还没得到授权。

3、Presence Server向 A 发送NOTIFY通知其对B的订阅请求处于“pending”状态。并且,在B的watcherinfo信息中添加一条 A 的记录,状态为“pending”,Presence Server会向B发送NOTIFY消息通知,消息体类型为“ application/watcherinfo+xml”,典型的消息体如下:

<?xmlversion="1.0" encoding="UTF-8"?>

<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"

version="1" state="partial">

<watcher-list resource="sip:[email protected]"package="presence">

<watcher id="77ajsyy76" event="subscribe"

status="pending">sip:[email protected]</watcher>

</watcher-list>

</watcherinfo>

4、B 的终端收到“ M4: NOTIFY”之后立即返回 200 完成 NOTIFY 事务。同时 向 B 用户弹出提示: A 请求加好友。在这里,终端可以给 B 用户提供两种选 择:仅仅接受 A 的请求或者接受订阅请求的同时还将 A 加为好友。如果 B 选择前者,那么 B 终端只需向 Presence Server 发送一个添加 A 到 B 的白名 单中的 HTTP 请求 PUT(这种消息体格式为“ application/auth-policy+xml”)。如果 B 用户选择后者, B 终端在本地好友列表中添加
A 用户, 并且除了向 Presence Server 发送加白名单的 PUT 请求, 还需要发送一个将 A 添加为 B 好友的 PUT 请求和一个订阅 A 的 presence 状态的 SUBSCRIBE 请 求(这次 B 加 A 好友的过程与 A 加 B 一样,只是方向相反)。这里不管 B 用户选择前者还是后者都不再描述与前面过程类似的消息,只描述 A 加 B 好 友的那部分后续消息。

H3 消息如下:

PUT

/pres-rules/users/B/presrules.xml/~~/rule-set/

rule?xmlns(cr=%22urn:ietf:params:xml:ns:common-policy%22) HTTP/1.1

Content-Type:application/xcap-el+xml

Host: ps.cintel.net.cn

<cr:rule id="1">

<cr:conditions>

<cr:identity>

<cr:id entity="[email protected]"/>

</cr:identity>

</cr:conditions>

<cr:actions>

<sub-handling>allow</sub-handling>

</cr:actions>

<cr:transformations>

<provide-services>

<all-services/>

</provide-services>

<provide-unknown-attributename="new:foo">true</provide-unknown-attribute>

</cr:transformations>

</cr:rule>

5、Presence Server 收到“ H3: PUT”之后,返回一个 200 响应,并且将 A 添加到 B 的白名单中,将 A 的好友列表中 B 的订阅状态改为“active”。然后查询 B 的当前 presence 状态,构造 NOTIFY 消息通知 A。 6. A 收到响应之后返回 200 完成 NOTIFY 事务,并将 B 的 presence 状态显示出 来。 说明:如果 A 加 B 好友的时候 B 不在线,消息流程图中 M3 之前(含 M3)的消息 不变,只是Presence Server 在
B 的 watcherinfo 中添加 A 的记录之后不会立即 给 B 发送 NOTIFY,而是等到B登陆之后发送。如果 B 收到“ M4: NOTIFY”之后不接受 A 的订阅请求,随即返回的SIP消 息还是 200 (事实上这个 200 响应是在 B 用户做出决定之前终端就自动发的,它仅表明NOTIFY 消息被接受,立即返回 200 是为了维持 NOTIFY 事务,因 为这种事务不能时间过长)。但是在“ H3:PUT”中不是添加到白名单的信息, 而是添加到灰名单。PresenceServer 收到这个请求后如何处理由实现决定,可以构造一个带“
Subscription-State: terminated; reason=rejected”头字段的 NOTIFY 消息给 A, A 终端收到这个消息后将 B 在本地好友列表置于临时删 除状态,并且向 A 发送一个 HTTP 的 DELETE 请求,用以删除 PresenceServer 端 A 好友列表中的 B 记录。 Presence Server 收到请求确实删除 B 并返回 200 之后 A 的终端再正式在本地好友列表中删除 B。

2.1.2.3订阅 watcherinfo

2.1.2.3.1情景说明

假设 C 用户已被授权订阅了 B 的 presence 状态, A 在 B 不在线的时候请求订阅 B 的状态。后来 B 登陆,向 Presence Server 发出订阅其 watcherinfo 的请求,Presence Server 接受请求,通知其最新的 watcherinfo 状态,由于 A 的订阅尚未授权,因此会提示 B 用户鉴权。

2.1.2.3.2SIP消息流程图

2.1.2.3.3消息流说明

Presence 系统对 watcherinfo 的处理和 presence 类似,只是事件包(event package) 变为*.winfo。

1、  B 终端启动,向 Presence Server发送 SUBSCRIBE 请求,订阅自身的 watcherinfo 信息。注意其 Event 头字段的值为 presence.winfo。

M1 消息如下:

 SUBSCRIBE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bKnashds7

From: <sip:[email protected]>;tag=123aa9

To: <sip:[email protected]>

Call-ID: [email protected]

CSeq: 1 SUBSCRIBE

Contact: <sip:b.cintel.net.cn>

Event: presence.winfo

Expires: 3600

Accept: application/watcherinfo+xml

Max-Forwards: 70

Content-Length: 0

2、Presence Server 收到请求之后进行鉴权和授权,接受之后返回 200 响应。

M2 消息如下:

 SIP/2.0 200 OK

Via: SIP/2.0/UDP b.cintel.net.cn;branch=z9hG4bKnashds7

From: <sip:[email protected]>;tag=123aa9

To: <sip:[email protected]>;tag=xyzygg

Call-ID: [email protected]

CSeq: 1 SUBSCRIBE

Contact: <sip:ps.cintel.net.cn>

Expires: 3200

Content-Length: 0

3、  Presence Server 查询出 B 的 watcherinfo 信息( A 处于“ pending”状态, C 处 于“ active”状态),构造成 NOTIFY 消息通知 B。此 NOTIFY 消息体的格式 是“application/watcherinfo+xml”。注意消息体中 watcherinfo 元素的属性 version 随着每次发布递增,一般第一次是 0。第一次发布的时候应该包含所 有记录,因此 state 属性的值为“ full”,后续的发布既可以只包含部分改变的 记录也可以包含全部,由实现来决定。

M3 消息如下:

NOTIFYsip:[email protected] SIP/2.0

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKnasaii

From: <sip:[email protected]>;tag=xyzygg

To: <sip:[email protected]>;tag=123aa9

Call-ID: [email protected]

CSeq: 1288 NOTIFY

Contact: <sip:ps.cintel.net.cn>

Event: presence.winfo

Subscription-State: active;expires=3200

Max-Forwards: 70

Content-Type: application/watcherinfo+xml

Content-Length: 446

<?xml version="1.0" encoding="UTF-8"?>

<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"

version="0" state="full">

<watcher-list resource="sip:[email protected]"package="presence">

<watcher id="77ajsyy76" event="subscribe"

status="pending">sip:[email protected]</watcher>

<watcher id="77ajsyy77" event="approved"

status="active">sip:[email protected]</watcher>

</watcher-list>

</watcherinfo>

4、B 收到 NOTIFY 之后返回 200。因为 NOTIFY 消息体中 A 的订阅状态为 “ pending”,因此 B 终端会弹出提示请求 B 用户鉴权。

M4 消息如下:

Presence Overview

SIP/2.0 200 OK

Via: SIP/2.0/UDP ps.cintel.net.cn;branch=z9hG4bKnasaii

From: <sip:[email protected]>;tag=xyzygg

To: <sip:[email protected]>;tag=123aa9

Call-ID: [email protected]

CSeq: 1288 NOTIFY

Contact: <sip:b.cintel.net.cn>

Content-Length: 0

2.1.2.4发布状态信息

2.1.2.4.1情景说明

假设 A 有两位好友: B 和 C, B 一直在线, C 不在线。 A 登陆,向 Presence Server 发布其 presence 状态,由于 C 不在线, Presence Server 只通知 B A 的 presence 状 态发生变化。 A 经一次状态改变和刷新最后发一个取消发布的 PUBLISH 退出系统。

2.1.2.4.2SIP消息流程图

2.1.2.4.3消息流说明

SIMPLE 规范中把发布(publication)分为四种:Initial、Modify、Refresh 和 Remove, 分别代表初始化、修改、刷新和删除发布(publication)。

发布( publication)机制引入了 SIP-ETag 和 SIP-If-Match 头字段。对于每一个成功接受的 PUBLISH 消息, Presence Server 都会分配一个 entity-tag 并包含在 2xx 响应的 SIP-ETag 头字段中。而在下一次的 PUBLISH 消息中必须带上 SIP-If-Match 头字段,其值就是上次 PUBLISH 返回的 2xx 响应中 SIP-ETag 的 entity-tag。服务器收到这个 PUBLISH 请求之后会比较 SIP-If-Match
头字段的值和自己保存的 entity-tag。如果匹配,那么接受这个请求,否则拒绝该请求。

1、A 终端登陆此系统,向 PresenceServer 发送 PUBLISH(登陆后首次发送的 PUBLISH 是 Initial 类型的),发布自己的新状态。

M1 消息如下:

PUBLISHsip:[email protected] SIP/2.0

Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsge

Max-Forwards: 70

To: <sip:[email protected]>

From: <sip:[email protected]>;tag=1234wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: 246

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="slie74">

<status>

<basic>open</basic>

<im>online</im>

</status>

</tuple>

</presence>

2、Presence Server 收到PUBLISH 请求之后进行鉴权(authentication)和授权(authorization)。接受之后保存A的新状态并为此次发布(publication)分配一个entity-tag,包含在 SIP-ETag 中返回 200。

M2 消息如下:

SIP/2.0 200 OK

Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsge

To: <sip:[email protected]>;tag=1a2b3c4d

From: <sip:[email protected]>;tag=1234wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 3200

SIP-ETag: dx200xyz

Content-Length: 0

3、查询 A 的 watcherinfo 得知已订阅 A 的 presence 状态的有 B 和 C,又查知 B 当前在线, C 不在线。于是 Presence Server 向 B 发 NOTIFY 通知 A 的新状态, B 收到之后返回 200。

4、 假设一段时间后 A 由于工作原因,将状态改为“忙”,于是终端 A 向 Presence Server 发送一个 Modify 类型的 PUBLISH,更新其状态。这个 PUBLISH 中包含一个 SIP-If-Match 头字段,其值为上一个 200 响应中 SIP-ETag 的值。

M5 消息如下:

PUBLISHsip:[email protected] SIP/2.0

Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgf

Max-Forwards: 70

To: <sip:[email protected]>

From: <sip:[email protected]>;tag=1235wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 3600

Event: presence

SIP-If-Match:[D1]  dx200xyz

Content-Type: application/pidf+xml

Content-Length: 241

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="slie74">

<status>

<basic>open</basic>

<im>busy[D2] </im>

</status>

</tuple>

</presence>

5.、Presence Server 收到请求之后比较 SIP-If-Match 与自己保存的 entity-tag 值, 结果一致,于是接受该请求,并调整 Expires 有效时间长度。保存 A 的新状 态并再次分配一个新的 entity-tag 包含在 SIP-ETag 中返回 200。

M6 消息如下:

 SIP/2.0 200 OK

Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgf

To: <sip:[email protected]>;tag=1a2b3c4e

From: <sip:[email protected]>;tag=1235wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 3200

SIP-ETag: dx300xyz

Content-Length: 0

6、发 NOTIFY 消息给 B 通知其 A 的新状态,B 收到之后返回 200。

7、在上一次的发布(publication)超时前 A 重新发了 PUBLISH 消息,这是个 Refresh 类型的消息,关键的头字段是 Expires,且不含消息体。

M9 消息如下:

PUBLISHsip:[email protected] SIP/2.0

Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg

Max-Forwards: 70

To: <sip:[email protected]>

From: <sip:[email protected]>;tag=1236wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 3600

Event: presence

SIP-If-Match: dx300xyz

Content-Length: 0

8、由于Refresh 类型的消息只是刷新发布(publication)的有效时间,并不改变 presence 状态。因此不需要向订阅 A 状态的用户发 NOTIFY 消息。 Presence Server 选取适当的 Expires 值并分配新的 entity-tag 之后返回 200。

M10 消息如下:

SIP/2.0 200 OK

Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgg

To: <sip:[email protected]>;tag=1a2b3c4f

From: <sip:[email protected]>;tag=1236wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 3200

SIP-ETag: dx400xyz

Content-Length: 0

9、最后, A 退出系统,向 Presence Server 发送一个取消发布(publication)的 PUBLISH 请求。该请求没有消息体, Expires 值为 0。

M11 消息如下:

PUBLISHsip:[email protected] SIP/2.0

Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh

Max-Forwards: 70

To: <sip:[email protected]>

From: <sip:[email protected]>;tag=1237wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 0

Event: presence

SIP-If-Match: dx400xyz

Content-Length: 0

10、Presence Server 收到该请求之后删除 A 用户对应的一些发布( publication)数 据,如 expires 和 entity-tag。返回 200 完成 PUBLISH 事务。

M12 消息如下:

 SIP/2.0 200 OK

Via: SIP/2.0/UDP a.cintel.net.cn;branch=z9hG4bK652hsgh

To: <sip:[email protected]>;tag=1a2b3c4g

From: <sip:[email protected]>;tag=1237wxyz

Call-ID: [email protected]

CSeq: 1 PUBLISH

Expires: 0

Content-Length: 0

11、虽然 A 退出时取消订阅的 PUBLISH 请求不带消息体,但是 A 的 presence 状 态发生了变化,变为“ Offline”。 Presence Server 会把新的离线状态保存下来 然后发 NOTIFY 消息通知 B, B 收到之后返回 200。承接上面的情景,这个 NOTIFY 的消息体典型如下:

<?xmlversion="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="sip:[email protected]">

<tuple id="slie74">

<status>

<basic>closed</basic>

<im>offline</im>

</status>

</tuple>

</presence>

2.1.2.5删除好友

2.1.2.5.1情景说明

B 是 A 的好友, A 将 B 删除, B 在线。

2.1.2.5.2SIP消息流程图

2.1.2.5.3消息流说明

1、 A 将 B 删除。 A 的终端会将 B 置上删除标记,并发送 XCAP 消息 DELETE 给 Presence Server,用以删除服务器端好友列表中的 B。

H1 消息如下:

DELETE[D1]

/services/resource-lists/users/A/buddylist.xml/

~~/resource-lists/list/list/

entry%[email protected]=%22sip:[email protected]%22%5d HTTP/1.1

Host: ps.cintel.net.cn

2、经鉴权后将 B 从 A 的好友列表中删除,然后返回一个 200 响 应。

3、删除 B 还会影响 B 的 watcherinfo。Presence Server 会将 B 的 watcherinfo 中 A 的订阅状态改为“ terminated”,对应的事件(event)是“ deactivated”。然后 发 NOTIFY 通知 B, B 返回一个 200 消息。(当然,如果 B 当时不在线,那 么 Presence Server 会在 B 下次登陆的时候通知)。

2.1.2.6添加和删除黑名单

2.1.2.6.1情景说明

用户可以自己添加或删除黑名单,用以阻止特定人员订阅自己的 presence 状态。

2.1.2.6.2SIP消息流程图

2.1.2.6.3消息流说明

1、 添加黑名单的方法相当简单,终端只需要向服务器发送一个 PUT 的 XCAP 消息,将消息体中的名单添加到 URI 指定的服务器端黑名单中。服务器端添 加成功之后返回 200。

2、 删除黑名单与添加黑名单类似,只是方法变为DELETE。

2.2.SIP协议的即时通讯介绍

本部分介绍SIP的一个扩展的方法叫MESSAGE方法。MESSAGE需求body中一般带有即时通讯消息的内容。RFC2779中有即时通讯的MESSAGE方法的具体介绍。

使用范围:

在SIP环境中,一个IM会话是一个媒体会话,从INVITE开始到BYE结束。

 

操作情景:

当一个用户向另一个用户发送一个即时消息,发送者规定并发布一个MESSAGE方法的SIP请求。这个需求的Request-URI一般记录了接受者即时消息的地址,但是有可能是接受者在服务器中的注册的位置即设备地址。

这个请求可能会通过很多SIP代理服务器进行传输直至到达目的地址,目的地址的位置在CPIM及SIP特例中详细的进行了解释。在传输的过程中,每个代理服务器在基于有效的路由信息上有可能重写需求的URI。

临时和最终的反馈都会发送到发送者处。

2.2.1Message实例
2.2.1.1情景说明

用户1向用户2发送初始的IM消息,两个用户拥有相同的域,两个用户之间有一个代理。

2.2.1.2消息流程图

2.2.1.3消息流说明

用户1发送信息到服务器domain.com,代理接收到这个请求并识别出domain.com服务器。它从数据库中查用户2并且找到从sip:[email protected]到sip:[email protected]的绑定。它向user2转发需求。

消息F1:

MESSAGE[D1]  sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse

Max-Forwards: 70

From: sip:[email protected];tag=49583

To: sip:[email protected]

Call-ID: [email protected]

CSeq: 1 MESSAGE

Content-Type: text/plain

Content-Length: 18

消息F2:

MESSAGEsip:[email protected] SIP/2.0

Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds

Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;

received=1.2.3.4

Max-Forwards: 69

From: sip:[email protected];tag=49394

To: sip:[email protected]

Call-ID: [email protected]

CSeq: 1 MESSAGE

Content-Type: text/plain

Content-Length: 18

用户2接收到此消息,显示并产生回应,消息F3,并发送到代理:

SIP/2.0200 OK

Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;

received=192.0.2.1

Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;

received=1.2.3.4

From: sip:[email protected];tag=49394

To: sip:[email protected];tag=ab8asdasd9

Call-ID: [email protected]

CSeq: 1 MESSAGE

Content-Length: 0

代理接收该响应,并转发到下一个地址,user1pc.domain.com,产生消息F4:

SIP/2.0200 OK

Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;

received=1.2.3.4

From: sip:[email protected];;tag=49394

To: sip:[email protected];tag=ab8asdasd9

Call-ID: [email protected]

CSeq: 1 MESSAGE

Content-Length: 0

使用message/cpimBodies

Message/cpim格式除了消息负载之外,元数据允许受到S/MIME的保护。在很多例子中,元数据在SIP的头域中是冗余的。所以,nessage/cpim添加值,通过扩展协议边界来对元数据进行保护。


[D1]请求方法,MESSAGE表示请求通讯

时间: 2024-10-08 08:58:31

IM通讯协议总结之三SIMPLE协议的相关文章

即时通讯技术- 推送技术协议方案

C2DM云端推送方案 在Android手机平台上,Google 提供了 C2DM(Cloudto Device Messaging)服务.Android Cloud to Device Messaging (C2DM)是一个 用来帮助开发者从服务器向Android应用程序发送数据的服务.该服务提供了一个简单的.轻量级的机制,允许服务器可以通知移动应 用程序直接与服务器进行通信,以便于从服务器获取应用程序更新和用户数据. 该方案存在的主要问题是C2DM需要依赖于Google官方提供的C2DM服务器

OSI七层模型,讲解tcp/ip五层涉及的网络协议,网络通信实现,结合协议来看网络通信流程

当我们通过自己电脑的浏览器访问京东的时候, 览器上输入了一个网址,但是我们都知道,互联网连接的电脑互相通信的是电信号,我们的电脑是怎么将我们输入的网址变成了电信号然后发送出去了呢,并且我们发送出去的消息是不是应该让京东的服务器能够知道,我们是在请求它的网站呢,也就是说京东是不是应该知道我发送的消息是什么意思呢.是不是发送的消息应该有一些固定的格式呢?让所有电脑都能识别的消息格式,他就像英语成为世界上所有人通信的统一标准一样,如果把计算机看成分布于世界各地的人,那么连接两台计算机之间的intern

一个有趣的问题——HTTP是“超文本传输协议”还是“超文本转移协议”

最近在看<HTTP图解>这本书,书中提到了对国内对HTTP协议名称的翻译问题,并且给出了一些网友讨论的原稿链接,我看了一下觉得挺有意思的,另外我本人也觉得翻译对于理解协议本身非常重要,就整理了一些观点. HTTP的全称是HyperText Transfer Protocol,大家主要的关注点在于Transfer应该如何翻译. 以下是整理的内容: 李锟: 1.纸面释义 在IETF的RFC中,"transport"(传输)的含义是指:从端到端(例如从ip1:port1到ip2:

Telnet协议,SSH协议(安全外壳协议),SSL协议(安全套接层协议),HTTPS(Hypertext Transfer Protocol Secure)安全超文本传输协议

2.Telnet协议 Telnet协议是TCP/IP协议族中的一员,是Internet远程登陆服务的标准协议和主要方式.它为用户提供了在本地计算机上完成远程主机工作的能力.在终端使用者的电脑上使用telnet程序(如putty),用它连接到服务器.终端使用者可以在telnet程序中输入命令,这些命令会在服务器上运行,就像直接在服务器的控制台上输入一样.可以在本地就能控制服务器.要开始一个telnet会话,必须输入用户名和密码来登录服务器.Telnet是常用的远程控制Web服务器的方法. 3.SS

C# 串口操作系列(3) -- 协议篇,二进制协议数据解析

C# 串口操作系列(3) -- 协议篇,二进制协议数据解析 标签: c#bufferobject通讯byte硬件驱动 2010-05-27 09:54 51565人阅读 评论(215) 收藏 举报  分类: 通讯类库设计(4)  版权声明:本文为博主原创文章,未经博主允许不得转载. 我们的串口程序,除了通用的,进行串口监听收发的简单工具,大多都和下位机有关,这就需要关心我们的通讯协议如何缓存,分析,以及通知界面. 我们先说一下通讯协议.通讯协议就是通讯双方共同遵循的一套规则,定义协议的原则是尽可

C# 串口操作系列(4) -- 协议篇,文本协议数据解析

C# 串口操作系列(4) -- 协议篇,文本协议数据解析 标签: c#uiobjectstringbyte 2010-06-09 01:50 19739人阅读 评论(26) 收藏 举报  分类: 通讯类库设计(4)  版权声明:本文为博主原创文章,未经博主允许不得转载. 上一篇已经介绍了协议的组成,一个协议,一般具有 :协议头+长度+数据+校验 , 文本格式可以直观的定义回车换行是协议的结尾,所以我们可以省略数据长度,增加协议尾.即: 协议头 + 数据 + 校验 + 数据尾 . 文本方式的数据比

HTTP协议,超文本传输协议

HTTP协议,超文本传输协议a.Http协议现在使用的是1.1的版本b.Http协议是应用层协议,底层要求使用可靠传输协议传输数据.通常传输层协议使用Tcp协议c.Tcp协议规定两台计算机之间如何传输数据.d.HTTP协议规定传输数据的格式,以便两台计算机之间理解对方发送的内容e.HTTP协议规定了客户端与服务端之间的通讯模式必须遵循1次请求一次响应的通讯过程f.首先由客户端(谁发送请求谁就是客户端)发起请求(Request),客户端通常是浏览器.然后服务端接收并输出该请求,然后给予响应(Res

流媒体传输协议系列之--RTSP协议详解

流媒体传输协议介绍 一.RTSP协议介绍 什么是rtsp? RTSP协议以客户服务器方式工作,,如:暂停/继续.后退.前进等.它是一个多媒体播放控制协议,用来使用户在播放从因特网下载的实时数据时能够进行控制, 因此 RTSP 又称为"因特网录像机遥控协议". RTSP(Real-Time Stream Protocol)是一种基于文本的应用层协议,在语法及一些消息参数等方面,RTSP协议与HTTP协议类似. 是TCP/IP协议体系中的一个应用层协议, 由哥伦比亚大学, 网景和RealN

协议分析 - DHCP协议解码详解

协议分析 - DHCP协议解码详解 [DHCP协议简介] DHCP,全称是 Dynamic Host Configuration Protocol﹐中文名为动态主机配置协议,它的前身是 BOOTP,它工作在OSI的应用层,是一种帮助计算机从指定的DHCP服务器获取它们的配置信息的自举协议. DHCP使用客户端/服务器模式,请求配置信息的计算机叫做DHCP客户端,而提供信息的叫做DHCP的服务器.DHCP为客户端分配地址的方法有三种:手工配置.自动配置.动态配置. DHCP最重要的功能就是动态分配