即时通信现状篇（1）

1 引言

随着移动互联网技术的发展，即时通讯（IM）已经成为最常用的通信工具之一[1]。然而，随着即时通讯各类功能的不断丰富，移动终端不断增长的能耗、流量需求与有限的电量、高昂的资费间的矛盾日益加剧[2]，这在一定程度上降低了用户体验。

目前市场上，移动IM系统的实现除了少数采用私有协议外，主要采用XMPP协议和SIMPLE协议。XMPP协议是以XML为基础的开放式即时通讯协议，具有成熟、安全、可扩展性强等优点，但存在协议复杂、消息重复转发、费电、费流量的缺点[3-4]，这是一个高耗能的协议。SIMPLE协议是在SIP协议[5]的基础上扩展而来，是主流的即时通讯协议之一，它具有较成熟的音视频标准，支持各类即时消息通信，但它也存在流量消耗较大、扩展复杂等问题。上述两种协议在设计时并未考虑到移动终端的特性，因此在实际应用中表现并不出色。

本文设计了一个基于MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）的移动即时通讯协议MQTT-IM，并实现了基于Android平台的移动即时通讯系统，为实现低功耗和流量消耗的移动IM系统提供了一种新的解决方案。

2 MQTT协议

2.1 MQTT协议简介

MQTT协议是一个C/S架构，是基于/订阅模式的消息传输协议[6]。该协议针对工作在低带宽、网络不可靠的受限设备而设计，运行在TCP/IP网络连接之上，具备以下特点：

使用/订阅模式，提供一对多的消息分发和应用之间的解耦；

消息传输不需要知道负载内容，易于扩展；

提供了三种等级的QoS（Quality of Service，服务质量），分别为“最多一次”（QoS=0）、“至少一次”（QoS=1）、“仅一次”（QoS=2）；

很小的传输消耗和协议数据交换，最大限度地减少网络流量。

2.2 MQTT控制报文的结构

MQTT协议通过交换预定义的MQTT控制报文来进行通信，MQTT控制报文由3部分构成：固定报头、可变报头、有效载荷，其中所有控制报文都包含两个字节的固定报头，部分控制报文包含可变报头和有效载荷，其中固定报头的格式如表1所示：

固定报头第一个字节的高四位表示MQTT控制报文的类型，共14种，低四位表示每个MQTT控制报文特定的标志，第二个字节表示剩余长度，即当前报文剩余的字节数，包括可变报头和负载的数据。

固定报头第一个字节的高四位为0011表示PUBLISH类型的控制报文。PUBLISH控制报文的作用是从客户端向服务端或者服务端向客户端传输应用消息，控制报文的有效载荷包含将被的应用消息。MQTT协议解析时不需要知道有效载荷内容，这也是MQTT极易扩展的原因。通过对PUBLISH控制报文有效载荷结构的设计，来增加对特定功能的支持。

3 系统设计

3.1 设计思路

移动IM系统由服务端和客户端构成。服务端侧重即时通信服务的提供，包括通讯协议编解码、登录注册、通讯录、群组、即时消息通信、状态呈现等服务，并暴露接口供客户端调用。客户端侧重提供友好的UI及丰富的即时通信方式，较低的功耗和流量消耗可大大提升用户体验。本文基于MQTT设计即时通讯协议MQTT-IM，通过交换MQTT-IM控制报文来完成不同终端间的即时消息通信。

3.2 MQTT-IM协议的设计

MQTT控制报文的最小长度仅有两个字节，通信时流量消耗非常小。再加上协议本身非常简单，解析代价低，因此功耗也低。基于MQTT设计的MQTT-IM协议不仅继承了MQTT低功耗、低流量消耗的优点，而且通过对PUBLISH控制报文有效载荷的结构设计，解决了不同类型即时消息的传输，从而增加对即时通信功能的支持。

由MQTT控制报文结构的介绍可知，设计以MQTT协议为基础的即时通讯协议MQTT-IM的实质即对PUBLISH控制报文的有效载荷的结构进行设计，通过对有效载荷结构的设计，来满足各种类型的即时消息的传输。图1中虚线框中的内容为MQTT-IM控制报文的结构。

图1虚线框中的MQTT-IM控制报文中包含5个字段，这5个字段的具体含义如下。

type：即时消息类型字段，占1个字节，不可为空，从0x00-0xff共可表示256种类型的即时消息。本文共设计了22种即时消息类型，占用了0x00-0x15，剩余部分0x16-0xff可用于扩展新的即时消息类型。这22种即时消息类型可分为7大类，分别为注册类型、登录类型、通讯录类型、群组类型、即时信息类型、状态呈现类型、系统通知类型，每大类包含一种或多种类型，比如状态呈现类型包括user_online、user_offline两种类型。

from：发送方字段，变长，可为空，表示发送方ID，用于唯一标识发送方身份。

to：接收方字段，变长，可为空，标识接收方ID，用于唯一标识接收方身份。

timestamp：时间戳字段，占4个字节，不可为空，针对特定的from/to字段唯一标识某条即时消息，可用于消息排序。

content：消息正文字段，变长，可为空，针对不同的type值，content结构不同。content的结构分为7种，分别对应上述type字段的7大类型，比如当type字段属于状态呈现类型时，content结构由status基本字段构成。

MQTT-IM控制报文中5个字段的整体结构使用Protocol Buffers设计，通过这种设计方式可以获得比xml/json更快的编解码速度和更低的存储空间占用[7]。

3.3 总体架构设计

如图2所示，移动IM系统服务端由4部分组成，分别为后台管理系统、核心功能及接口层、基础服务层、数据库。Android客户端由登录注册、通讯录、群组、状态呈现、即时通信、sqlite存储等6个功能模块组成。

服务端后台管理系统提供了用户管理、数据统计、日志查询、参数设置等服务，可通过后台管理系统观测系统运行情况。

服务端的核心功能与接口层实现了跟IM密切相关的六种核心功能及对应的接口，分别是：登录注册管理负责用户的登录注册请求；通讯录管理负责处理添加/删除联系人，获取联系人列表等用户请求；群组管理负责处理创建/解散群组、添加群组、管理群成员、获取群组/群成员信息等用户请求；状态呈现管理负责响应用户状态变化事件；存储管理负责处理即时信息的数据库存储以及查询即时信息历史记录的用户请求。服务端对外提供了各个核心功能的接口，供客户端调用。

服务端基础服务层提供了3种服务：主题订阅服务供登录注册管理、通讯录管理、群组管理等功能调用，客户端订阅相关主题，服务端将即时消息转发给匹配主题的客户端；消息服务供除存储管理外的其他核心功能调用，提供即时消息的服务；MQTT-IM编解码服务在对MQTT-IM控制报文编码解码时会被调用。

数据库部分主要作用是提供即时消息记录的增删改查操作，同时提供存储用户相关信息的功能。

Android客户端划分为6个功能模块，通过调用服务端提供的相应接口可实现不同移动终端之间的即时通信。

4 系统实现

Moquette是一个Java版本的MQTT服务端开源实现，基于事件驱动，底层使用Netty网络框架完成协议的编解码工作。Moquette是轻量级、易于集成的，本文使用它作为MQTT协议服务端编解码工作，通过对Moquette二次开发，增加Moquette-IM模块，实现了状态呈现等功能。服务端采用Struts2+Spring+Hibernate集成框架进行开发，使用Mysql数据库存储用户相关信息及即时消息记录。下面以主题订阅、即时通信、状态呈现3个功能为例，详细介绍其实现过程。

4.1 主题订阅的实现

客户端订阅感兴趣的主题，服务端选择匹配的主题将收到的即时消息推送到对应的客户端，通过这种方式实现不同移动终端间的通信。本文设计了3种类型的主题，客户端通过订阅这3种类型的主题，可以实现通讯录好友间的单聊、群组聊天、状态呈现功能。这3种类型的主题分别为：

f/：通讯录类主题，这类主题由前缀“f/”加用户名构成，通过订阅这类主题可以接收到通讯录内好友的即时消息。

g/：群组类主题，这类主题由前缀“g/”加群组名称构成，通过订阅这类主题可以接收到群组内即时消息。

s/：状态类主题，这类主题由前缀“s/”加用户名构成，通过订阅这类主题可以接收到状态改变类型的即时消息。

4.2 即时通信的实现

客户端订阅f/和g/类型的主题时所使用的QoS与在该类主题上即时消息时的QoS取值相同，均为2，保证客户端有且只收到一次即时消息。通讯录内好友间单聊的具体实现为：每个用户在注册成功之后，客户端会自动订阅f/主题，其中uid为该用户的用户名。用户A与通讯录内的好友B进行单聊操作时，用户A在主题f/B上单聊消息，服务端对该MQTT-IM控制报文解码，得到单聊消息存储在数据库，并向订阅了主题f/B的客户端（即好友B）转发该报文，好友B收到该报文进行解码得到单聊消息，完成一次单聊操作。群聊的实现类似单聊，不同之处在于订阅主题的时机不同，群聊是在每个用户成功加入一个新的群组之后，客户端自动订阅g/主题，其中gid为该群组的群组名称，之后的实现过程类似于单聊，这里不再赘述。

4.3 状态呈现的实现

用户在成功注册后，客户端自动订阅主题s/，其中为该用户的用户名，用户通讯录中好友状态发生变化时，服务端会往与该好友有关的s/主题上状态改变类型的即时消息，之后用户在客户端会收到相应的提示信息。

QoS取值越低，服务端压力越小且客户端消耗的流量也越少，但通信质量会有所降低。客户端订阅s/类型的主题时QoS取值为0，服务端在s/类型的主题上状态改变类型的即时消息时QoS取值也为0，这种情况下状态改变消息无论成功与否只发送一次，无法保证该类消息每次都被客户端所接收到，因此在Android客户端提供了下拉刷新状态机制，这样在降低服务端压力以及客户端流量的同时，保证了用户体验。

状态呈现的实现是在Moquette的基础上，进行二次开发，增加了Moquette-IM模块，该模块使用模式对Moquette中的MQTT协议逻辑处理类ProtocolProcessor进行，在调用建立连接处理方法processConnect（）和断开连接处理方法processDisconnect（）之前进行增强处理，增强处理的时机如图3所示，具体增强处理操作为将状态改变信息封装成MQTT-IM控制报文，由服务端到对应的s/主题上，处理完成之后继续执行processConnect/processDisconnect原有的操作，当客户端接收到该MQTT-IM报文后，通讯录中好友头像颜色作出变化。使用模式降低了Moquette后期维护的成本，同时也符合开闭原则，在不对Moquette原有代码修改的前提下，扩展了状态呈现功能。

4.4 客户端实现

Android客户端实现了6大功能模块，分别为登录注册、通讯录、群组、状态呈现、即时通信、sqlite存储。另外，fusesource-mqtt-client是一个Java版本的MQTT客户端开源实现，本文使用它作为Android客户端MQTT协议编解码工具。注册登录成功之后，使用SharedPreferences类存储用户登录信息，之后可自动登录。通讯录中显示好友列表，可对任意好友发起聊天。群组功能实现了添加群组、搜索群组、管理群组等操作。状态呈现可显示好友在线和离线两种状态。即时通信功能中，单聊和群聊可以使用文字、表情、图片、语音等多种方式进行。sqlite存储即时消息历史记录和会话列表等。Android客户端中群聊的显示效果如图4所示。

5 测试

为了验证MQTT-IM协议有更低的功耗和流量消耗，更加适合移动设备，将MQTT-IM协议的实现和XMPP协议的实现进行了对比，其中MQTT-IM协议的实现使用本文中的Android客户端，XMPP协议的实现利用asmack+openfire搭建，流量和功耗的测试使用高通Trepn分析器Qualcomm Trepn Profiler[11]作为测试工具。

MQTT-IM和XMPP两种实现在耗电量和IM流量消耗方面的对比结果如图5和图6所示。

图5中横轴表示时间，纵轴表示耗电量，可看出MQTT-IM比XMPP耗电量低。IM流量测试中选择3种大小的文本分别进行测试，图6中横轴表示不同大小文本中汉字的个数，纵轴表示所消耗的IM流量，可以看出MQTT-IM比XMPP在IM流量消耗上降低约2～4倍。

6 结束语

本文针对目前移动IM解决方案中存在高功耗、费流量等问题，基于MQTT设计了MQTT-IM协议，并采用MQTT-IM设计并实现了一个移动IM系统，测试结果表明该系统可有效降低功耗和流量消耗，具有很高的实用价值。本系统在通信安全方面还存在不足，这也是下一步工作的重点。

参考文献：

[1] 陈为人. 一种即时通讯移动终端的研究[J]. 移动通信， 2016，40（6）： 80-82.

[2] 罗军舟，吴文甲，杨明. 移动互联网：终端、网络与服务[J]. 计算机学报， 2011，34（11）： 2029-2051.

[3] Cridland D. XEP-0286： XMPP on Mobile Devices[J]. Xmpp Standards Foundation， 2010.

[4] 彭亮. 面向移动设备的XMPP协议的研究与应用[D]. 长沙： 中南大学， 2014.

[5] Niemi A. Session Initiation Protocol （SIP） Extension for Event State Publication[J]. Networking&Communication Engineering， 2004（2）.

[6] MQTT org. MessageQueuingTelemetry Transport[EB/OL]. [2016-06-17]. http：///.

[7] eishay. jvm-serializers[EB/OL]. [2016-06-17]. https：///eishay/jvm-serializers/wiki.

[8] 吴吉义，李文娟，黄剑平，等. 移动互联网研究综述[J]. 中国科学：信息科学， 2015，45（1）： 30-36.

即时通信现状篇（2）

1 引言

即时通信业务可以实现用户状态的订阅、获取、更改和即时消息的发送、转寄/拒绝等。自1998年面世以来,特别是近年来的迅速发展,截至2009年底,国内即时通讯用户规模已突破2.77亿,其中手机即时通讯用户约占总体用户的1/3,规模达9141万。即时通讯用户中,20~29岁的青年人群所占比例高达40.2%,人数达1.11亿。这一人群同样也是移动即时通讯的最大用户群体,占到了整体比例的53.7%。

在目前国内的即时通信市场上,主要有腾讯QQ、微软MSN、阿里旺旺等产品;但除了腾讯和微软外,其他公司推出产品的时间都很短,手机用户也极少,市场有待开发。由于运营商拥有其他产品开发商所无法比拟的网络优势和用户规模,能够同时连通众多手机、PC、掌上电脑,已具备改变市场格局和即时通信使用习惯的条件,目前各个运营商都在积极发展典型的移动互联网业务――即时通信(IMPS),中国移动推出飞信,中国联通推出超信,而中国电信通过和微软的合作推出了天翼LIVE,当然现在无论在功能上还是在客户群体的大小上,它们都还无法与QQ相提并论。

值得注意的是,现在即时通信不只是一个单纯的聊天工具,其功能日益丰富,逐渐集成了电子邮件、博客、音乐、电视、游戏和搜索等多种功能。它已经发展成集交流、资讯、娱乐、搜索、电子商务、办公协作和企业客户服务等为一体的综合化信息平台。但还仅限于人和人之间的通信。

另外,无所不在的“物联网”通信时代即将来临,世界上所有的物体,如轮胎、房屋都可以通过因特网主动进行交换。射频识别技术(RFID)、传感器技术、智能嵌入技术将得到更加广泛的应用。“物联网”概念的问世,打破了之前的传统思维。过去的思路一直是将物理基础设施和IT基础设施分开:一方面是机场、公路、建筑物,而另一方面是数据中心、个人电脑、宽带等。而在“物联网”时代,钢筋混凝土、电缆将与芯片、宽带整合为统一的基础设施,物体或者机器通过传感器把温度、湿度、健康数据等准确地获取,转换成电子信息传递到信息中心进行处理,从而实现人与机器、机器与机器之间的信息交流。

现在的物联网基于Web 3.0,这需要一些新的技术,比如说传感技术使得互联网更多地融入物理世界;网络传输技术比如3G、4G实现了移动互联、无线传感器网络(WSN)技术等。我们认为物联网的本质还是扩大互联网应用,尤其是行业应用。按照这一思路,我们需要寻找传感器技术与移动互联网技术的结合,本文考虑将移动互联网的重要手段――即时通信应用于带有传感器的机器,从而将即时通信的用户从人群扩大到机器,通信从人与人之间扩大到人与机器、机器和机器之间。

2 实现方案

IMPS业务是由Instant Message(IM)业务和Presence Service(PS)业务组成的。IM业务,可在一系列的参与者间实时地交换各种媒体内容信息,并且可以实时知道参与者的信息,从而选择适当的方式进行交流,它具有便利、快捷、直接的特点,非常适合朋友之间、组织内部以及企业和客户之间的交流。 PS业务,就是使得参与实体(人或者应用)通过网络实时和修改自己的个性化信息,比如:位置、心情、连通性(外出就餐、开会)等,同时参与实体可以通过订阅、授权等方式控制存在信息的范围。PS业务可以通过E-mail、SMS、IM等方式通知用户状态信息。

按照IM和PS的不同实现机制,我们考虑两个实现方案:

(1)IM方案

该方案类似于点到平台的短信方案,如图1所示,服务器是控制机器的,包括对它的新建、删除,以及知识管理等;所有传感器从现场获取的数据会传给信息处理中心节点,然后再发送给机器引擎;用户信息数据库用来存储拥有该业务功能的用户信息,因为所有即时通讯的用户都可以添加该物联网机器为好友(如图2所示),但并不是所有人都能从它那里获取到物联网的信息,必须是购买该业务功能的企业或行业用户才行。

首先,服务器端(机器引擎)需要新建一个机器,机器的本质就是一个联系人,只不过它是和机器的信息相关联,它是由机器引擎来控制,而不是由用户控制;用户添加该机器后,向其发送问题请求;机器引擎通过知识分析,将问题号及用户的相关信息通过调用http/webservice接口发送到物联网的网关控制节点。网关控制节点通过查询用户数据库,判断用户是否合法;若合法,便会从传感器网络中获取用户需求的数据,并通过http/webservice接口返回给机器引擎。机器引擎获取到数据后,会把数据呈现在用户添加的机器聊天界面。

(2)PS方案

呈现功能指当用户状态发生变化时,其状态信息(脱机、联机、离开、马上回来等)也随之进行相应的变化,便于他人随时查看所要联系的用户的在线状态。需要带有传感器的手机能获取手机周围的状态信息,然后在手机主人的后面进行呈现,如图3所示,如果Steven的手机上自带有温度传感器或者可通过Zigbee/Bluetooth等近距离技术从外部温度传感器上获取温度信息,那么Steven周围的温度即可呈现在状态信息中。

3 前景分析

目前移动互联网和物联网正处于发展上升期,寻找其结合点对于中国电信运营企业意义重大,为了和QQ等互联网企业差异化竞争,需要挖掘自己的特色,比如结合现有的家庭客户和行业客户开展人与人、人与机器、机器与机器之间的通信。

IMPS已经成为电话、短信之外不可缺少的通信工具,目前其用户只包含人群,如果让IMPS将机器用户也包含在内,将会使得用户数大增,并给人们工作和生活带来极大便利。因此,IMPS的目标客户将包括关心各种手机传感信息的公众客户和通过手机传感收集器获取有关信息的行业客户。

4 结束语

本文提出了两种实现人机用户即时通信的技术方案,IM方案通过业务平台侧修改就可以实现,PS方案则需要带有传感器的终端配合。我们相信如果能让物联网的触角――传感器与手机结合,将使得人群的状态更加丰富,成为人们交往的另一通道。值得特别注意的是物联网是跟物理世界打交道的,在互联网上呈现时,隐私和安全更为重要,因此对用户的认证环节需要特别关注。

参考文献

即时通信现状篇（3）

1.引言

信道分配，是指通过线路对接，使信号通道能够进行数据传输，并通过了解当前信道的实际状况，对其进行合理分配。而人手分配则不可避免的存在着一定的限制，人手有限无法同时分配多个信道，分配速度不高等，甚至在长时间的工作下，还可能出现分配出错的情况。

岸台目前对信道分配依然处于人手分配的阶段，本文提出一种人手配合计算机的半自动信道分配系统设计。该设计主要根据现有的人手分配情况，在电脑上设计出相应的分配界面，由分配员对其进行操作，最后由电脑输出当前分配列表，并对信道进行分配。这样的设计通过了人手的配合，实现了半自动化的效果，让分配人员无需手动连接线路，只需要在电脑前对信道进行分配即可，有效地提高了分配的速度，降低了分配的出错率。

2.系统的分析与设计

2.1系统分析

本系统专门为信道分配人员设计，针对当前的信道分配现状，提出的一种半自动化信道分配系统。本系统需要从底层获取当前信道的使用情况，并在界面上提示分配员，让分配员随时了解输入信道与输出信道的实时状况，及时处理突发状况。因此，本系统在底层上，需要对信道有即时性的交互，从信道机器上获取使用状况，发送分配列表到信道分配器上，让其进行自动分配。当系统获取了信道使用情况，或者使用情况发生改变时，在使用界面上对相应的设备状况进行设置，并提示分配员进行相应处理。

2.2系统结构设计

本系统结构比较简单，通过流程图进行阐述其结构设计，见图1。

由于本系统是由分配人员专用，因此需要通过一定的验证进行登录，登录后进入使用界面，界面有三种形式，设备状态、分配情况以及综合界面。

设备状态界面主要是让分配人员实时了解到信道当前状况，包括是否开机、是否故障以及是否占用，通过灰色，红色以及绿色进行区分。界面视图如图2。

分配情况是分配人员进行分配的主要界面，界面左边为需要分配的入口信道，右边为所分配的设备信道。分配员只需要点击右边的设备分配框，即可按照提示选择可以使用的设备信道。当设备状况发生改变时，将提醒分配员进行重新分配。见图3。

综合界面是以上两个界面的结合，使得分配员可以即时看到设备的状况以及实际的分配情况，进行更好的选择。见图4。

根据以上几个界面，可以知道，系统的主要任务是作为分配员与信道设备之间的媒介。因此，系统实际只需要使用到几个查询和设置函数的函数。

2.3系统设计类图

设计类图主要根据以上所设计出的界面并进行分析，得出相应的，需要架设的类。

设备类：基础类，系统中，以该类为基础，实现各种功能。系统在运行过程中需要存储这个类的列表，记录当前可用的信道设备ID，以及所有信道设备的当前状况。设备ID是用以区分每个设备的；设备属性主要设置设备的等级；当前状态分为：空闲、故障以及使用；状态持续时间分别对应以上三种情况的具体持续时间；连接用户是指分配员为其分配的连接用户。参见图5。

接入类：与设备类相似，即分配情况表需要用到进行分配的接入类。每个接入信道，都会分配一个接入ID，进行查找、分配；用户级别通过接入属性区分；当前状态分为待分配和已分配；持续时间为等待时间或通话时间；连接设备是为其分配的信道设备的ID。见图6。

全局类：通过保留系统需要一直使用的数据，主要有空闲设备列表、所有设备列表、待接入列表以及已接入列表，此类在多个地方使用，因此定义为全局，方便调用，但也需要考虑锁的问题。见图7。

函数类：系统所使用的所有函数，通过调用此类进行运算，得出结果。主要用于储存函数，方便调用。检测信道和监听接入均为一直运行的线程，实时更新，信息提醒是当信道发生改变时进行的处理，分配检查和分配实施是当分配员进行了相应分配以后的操作。见图8。

即时通信现状篇（4）

根据CAN通信的连接方式，通信盘A和通信盘B均应向CANA、CANB发送数据，CANA或CANB仅一路通信中断不影响系统的正常使用。而且，根据《客专列控中心与轨道电路接口规范（报批稿）》4.6.1中规定“若不能从某一通道接收到有效数据时，应自动采用冗余通道接收的数据”。通信板A的CAND和通信板B的CANE连接主发送器和单数接收器，且两路CAN通道互为备用；通信板A的CANE和通信板B的CAND连接备发送器和双数接收器，且两路CAN通道互为备用。通信接口板与移频接口柜的通信连接情况，由于发送器“1+1”备用，接收器互为并机，因此两路CAND和两路CANE有一路可用即可正常CAN通信。综上所述，列控中心与轨道接口盘主用CANA通道，若CANA通信故障，则可通过CANB发送、接收数据。同时，轨道接口盘与轨道电路移频柜间四条CAN通道（两条CAND，两条CANE），只要有一条通道通信正常，则数据可正常传输，不会导致轨道红光带。

2CAN通信“假冗余”问题分析

京广高铁联调联试期间，通过列控功能试验和联锁试验发现：通信盘A与轨道移频柜通道中断，即主通道中断时，列控显示该移频柜轨道电路全部“红光带”。但是，若通信盘B与轨道移频柜通道中断，则设备通信正常不会发生轨道电路“红光带”的故障。于是，立即组织对现场CAN通信连接方式及相关配线、板卡进行检查和分析，发现CAN通信连接方式正确，检查各部板卡也未发现问题。由此得出结论，京广高铁CAN通信系统硬件配置及连接方式符合可靠性设计要求，但是其内部软件的逻辑处理方式却未考虑冗余设置，导致主通道中断就会发生轨道区段“红光带”故障。换而言之，即CAN通信冗余设置“表里不一”，可称之为“假冗余”。通过软件逻辑分析，当轨道电路通信盘与移频柜主通道中断时，即轨道电路通信盘A与轨道电路移频柜通信故障，按照目前轨道电路的处理方式，通信盘通过CANA、CANB发送至列控中心的信息包仍都为有效信息包，只是CANA中区段状态为通信故障。根据《客运专线列控中心列控与轨道电路接口规范（报批稿）》第4.5.2节，列控中心需将区段故障处理成占用状态。但该接口规范中并未规定在轨道电路上传的CANA、CANB数据不一致的情况下，列控中心该如何处理。京广高铁列控中心与通信盘A、B均为通信正常且数据校验正确的情况下，列控中心使用CANA数据进行逻辑判断，在综合GJ状态后，判断区段是“空闲”还是“占用”状态。同时，发现目前的通信盘配置为“通信盘A仅向CANA发送数据，通信盘B仅向CANB发送数据。因此，当断开通信盘A盘与移频柜的连接时，由于通信盘A收不到轨道电路状态数据，会向CANA发送轨道电路通信故障状态。列控中心收到CANA中的通信故障数据后处理为“占用”状态，确认为有效数据，并不使用CANB的正常数据，且此时采集GJ状态为“空闲”状态，则造成列控中心认为“驱动采集不一致”故障，导致轨道“红光带”发生。

二改造方案及建议解决

京广高铁“假冗余”问题，仅需要修改“状态数据帧输出逻辑关系”即可，而不用修改任何硬件配置，即正常情况下CANA为主用通道，列控中心以CANA通信数据为准，当CANA通信故障时，则以CANB通信数据为准。由于《客运专线列控中心列控与轨道电路接口规范》中没有明确：“轨道电路上传的CANA、CANB数据不一致的情况下，列控中心该如何处理。”造成列控中心生产厂家处理方式不一，从而片面的提高其系统的安全性，只要主通道故障就判断为系统故障，大大降低了系统的可靠性。因此，为了杜绝类似问题重复发生，建议明确CANA/B总线冗余处理逻辑，修订《客运专线列控中心列控与轨道电路接口规范》，修改列控中心通信数据处理方式，并增加关于对CANA、B数据进行冗余处理的原则说明。

即时通信现状篇（5）

在通信方式泛滥的时代,如何更好地提高企业的交流效率?早在2000年,业界就提出了一个解决方式――统一通信。这一方式旨在将各种通信工具融合到一个系统中,实现无缝、智能化的通信。

从2007年左右开始,美国的各大厂商就相继推出将网络会议、即时信息、在线状态通知、群件等办公室通信工具和IP电话相结合的统一通信解决方案。但在目前的多数企业中,这些通信工具依然被作为单一的产品来提供。可以说,统一通信――这一年轻的方案目前才刚刚踏入实用阶段。

在统一通信方案中,在线状态通知技术是一项关键的技术。它可以帮助使用者获知信息接收者当前的哪几种工具处于可接收信息状态。例如,在接到顾客电话并需要立即做出正确解答的情况下,接电话的员工可以查询具有在线状态通知功能的地址簿,获知最适合的营业负责人或专家的在线状态。如果他在座位上,则转接到固定电话;如果显示结果为外出,则转接到他的手机上。这样可以很明显地提高服务效率和服务质量。

除了在线状态通知技术,智能路由技术是统一通信方案中另一项重要的技术。在运用此技术之前的通信中,发送者需要自己决定通信对象和通信工具。但是,通过使用智能路由技术,系统可以即时分析各种数据库信息,然后选择最适合的人在最适合的时间连接到最适合的通信工具。

伴随着竞争激烈化、经营高速化、业务复杂化的商业环境变革,统一通信将在企业的应用中起到越来越重要的作用。而在统一通信所带来的通信方式改变的大背景下,企业内部架构也会由原来根深蒂固的金字塔式组织结构变为可以对外部环境做出快速反应的小规模项目组结构。

2009年以前:统一通信开始被业界认可。但由于通信工具融合不彻底,只有小部分企业尝试这一应用,而大部分企业还是通过单一、分散的通信工具进行沟通。

新商机

统一通信解决方案既然涉及到硬件终端、网络,以及软件系统,那么必然带动相关产业的发展。除了提供整体的统一通信解决方案外,作为方案重要组成部分的在线状态通知技术、智能路由技术的开发,以及相关软件的完善等方面都是充满机遇的新市场。例如,在线状态通知技术最初只能提供信息接收者的在线状态,但如今,如何让该技术实现“自动选择通信工具进行连接”这一功能已在研究中。

不过,统一通信的最初阶段仍然是围绕计算机展开的。这不仅需要员工在有计算机的地点进行通信,而且需要配备耳机等周边设备,便利性有限,同时,这种通信缺乏有现场感觉的对话。

即时通信现状篇（6）

ASON技术的全称为“自动交换光网络”，作为一项全新的通信技术，它利用路由、信令、自动发现等标准协议，实现了连接自动建立、路由自动计算、自动发现网络资源等功能，进而提高了光传送网的自动控制功能，让光传送网能够与IP网络一样能够实现智能化。通过ASON技术，不仅能够极大的提高电力通信网的服务速度、丰富业务种类，同时能够实现与网络无缝融合，使得光网络更加智能化。

一、ASON技术的特点与优势

ASON技术能够通过用户动态传达业务需求，网元在路径发挥中起着决定性作用，进而通过信令控制平台进行操作、连接、删除电路等字形交换光网络。现如今，ASON技术已然成为光传输技术的一大趋势，ASON技术能够灵活、快速的布置任务；保护与自动配置主要业务，表现出非常强的操作分布网络能力。ASON技g的具体优势在于以下几点：1、ASON技术可以在光传输层对业务进行动态分配，对各个线路的SLA都能够有效支持，从而进一步加强网络资源利用率，根据业务需求对宽带进行调整。2、ASON技术具有双向性特点，实现了终端与终端间的保护、监控以及网络恢复能力，同时也具有分布式处理优点。3、ASON技术能够拓展网络功能，通过更加灵活的接入业务，能够自行发现、添加网络节点，同时能够有效降低工作量。4、一般情况下，ASON网络结构都会采取网孔网的形式，即使光纤中断、节点失效对其影响都非常小。除此之外，ASON技术还能够生成大量的恢复制度和保护制度，将不同级别的业务进行结合，从而找出保护与恢复方法，进而加强网络的完全性与稳定性。

二、网状网技术

想要引入ASON技术，必须要建立网状网系统，网状网能够有效融合恢复与保护的功能，即使网络出现故障也能够保证继续展开业务，并且能够保障良好的网络状况。在相同的网络资源情况下，网状网能够加大对宽带的利用率，从而最大程度上发挥有限网络的经济效益，同时能够有效节约成本。在对网络积极拓展的情况下，网状网能够充分发挥自身的作用，进一步扩大自身网络利用率的优势。建立网状网系统能够实现保护、共享带宽的目标，改变了传统环网固定分配保护宽带的模式。但网状网也有一定的不足，例如验证网络资源可靠性、资源备份等问题。

网状网技术与传统的SDH技术不同，在网状网技术中，其节点拥有的光方向一般都不少于2个，即自检路由要到达2个以上，由此加大了网络规划的难度。除此之外，网状网在恢复计算路径时，无法实现最优化的智能分布，所以其中的网络规划成为了ASON技术的主要内容。

三、ASON技术组网设计

3.1利用ASON组建电力通信网

在本地传输网或城域网中，由于多环间互联的现象极其普遍，当业务需要跨接多个环网结构时，其业务的安全性需要多个环网共同保护，如果出现两处以上断纤状况时，会导致大量业务数据丢失。针对此类问题，可以将ASON技术引入到骨干层面和汇聚层面，充分利用其恢复与保护功能，从而提高整体网络的抗故障性。

3.2 ASON技术的演进策略

在引用ASON技术时，运营商可以通过网络建设和业务发展需求，逐渐开发ASON的新功能。在ASON技术引入之初，人们通常认为智能网络需扩大分布才的以实现，但随着网络技术不断发展，ASON技术也逐渐演变为“先集中、后分布”的发展策略，也称为“集中智能系统”，待智能分布技术与相关设备进一步成熟后，在逐渐引入到网络中。由于现如今市面上依旧存在大部分SDH非智能网络，在引入ASON技术时，可以采取平滑演进的方式进行智能化过渡，即在网络中引入ASON技术，对外采取UNI技术，让贷款按需与流量工程能够自动匹配，从而将现有光传输网的层面基础上，通过几个核心大节点配置大型交叉连接系统。通过该种形式能够构建一个以网状网为基础，更加强大、灵活的智能核心层。或者将现有的传输网不进行更改，通过集中管理控制系统，凭借标准的UNI，从而实现与数据层之间的信息互联，构建多层结构的ASON系统。在ASON技术中，待到NNI心灵协议能够实现标准化后，即可建立信令机制，让信令完成带宽的配置工作，这样能够保证现存的网络带宽配置依旧能够通过控制系统实现。随着网络技术不断增强，如今这两种技术可以实现并存，真正的实现了全网端对端配置。

结束语：将ASON技术引入到电力通信光网络，能够有效提高网络带宽利用效率、减少重复投资、改善网络环境、降低投资成本等。ASON技术相对于MSTP、SDH有着绝对的优势，ASON技术已然成为光传输技术的一大趋势，未来ASON技术的应用范围也会越来广。

即时通信现状篇（7）

国际上主流的家庭网络标准有：美国的X10、消费总线（CEBus）、日本的家庭总线（HomeBus）、欧洲的安装总线（EIB）。技术上并不先进的X10，只支持开关量，用于面板开关和继电器类的简单电器，但凭借价格低廉、性能可靠，尤其是它的易用性，一般用户均能自行安装，商业上取得了巨大的成功：450万户美国家庭采用X10，累计销售了1．2亿个模块。1984年，美国电子工业协会（Electronics Industry Association EIA）认为X10协议已经不能满足现代生活的需要，并在1992年了CEBus（Consumer Electronic Bus）协议，其目标是建立一个针对消费类电子产品的开放性协议。1994年，CEBus工业委员会（CIC）成立，其成员为国际知名厂商。2002年6月，微软和CIC共同宣布支持基于CEBus的简单控制协议SCP，SCP是微软UPnP协议的子集。如果说X10是在低技术层次上，通过简单的操作来达到产品易用性，则CEBus是在高技术层次上，通过家电的互联、互操和即插即用来实现产品的易用性。HomePnP（HPnP）是CIC制定的基于公共应用语言（Common Application Language，简称CAL）的家电系统相互协同进行互操的规范。HPnP不是一种语言，它为支持CAL的家电提供统一的应用规则来实现家电的即插即用功能。

1 HPnP中传输协议的独立性

传输协议的独立性是HomePnP规范的最主要目标之一。 HomePnP规范使生产厂家可以使用一个应用协议，并选择合适的独立的传输网络（RF，PL，IR）。由于HomePnP计划运行于已有的消费电子产品协议如CEBus和IEEE 1394（Fire Wire）之上，所以它对下面的传输层只提出最少的要求，保持其独立性。

家庭产品即插即用（HomePnP）采用分层结构，通过三个主要的功能模块来处理应用层和更高层的问题。如图1所示。

最下层代表应用层及其相关的公共应用语言（CAL），它包含在EIA－600（CEBus）、EIA－721和EIA－766标准中，从而免去在不同产品之间设置昂贵的语言翻译网关。

上下文数据结构层代表各种各样用CAL句法开发而成的产品模型。通过定义安防、照明、环境、能源管理、家电设备、计算机和娱乐等的上下文，构成业界认同的家电产品模型。

最上层是系统指南，它指出即插即用安装的产品必须具有哪些行为特征。这些指导性的原则涉及到EIA－600中尚未解决的一些难题。

2 HPnP的结构

HomePnp通过5个不同层次的架构来实现家电的互操性。如表1所示。

HomePnP的架构组成要素

CAL提供的构造模块设备，上下文，上下文号，对象，实例变量，CAL报告，HomPnP广播和直接消息传输HomePnP采用的构造模块子系统，状态对象，侦听对象，请求对象，传感器信息共享，报警和故障诊断报告，家居模式子系统间的互操性模块松耦合，动态上下文序号，状态信息广播，状态向量，自动绑定和手动绑定子系统内的互操作模块紧耦合，安装工具其他的互操需求设备启用，设置，资源管理，消息处理，认证和加密的传输需求下面，仅对HomePnP构造模块和子系统互操模块进行介绍。

2．1 子系统subsystem

子系统是家庭控制网络中功能相似和相关的设备和设备集。例如：安防系统、照明系统、环境控制系统、家庭娱乐系统。一个子系统包含了一系列的CAL上下文，这些CAL上下文分别负责一部分的控制功能。HomePnP的子系统可以只存在一个设备当中，也可以分布在多个设备当中。

2．2 状态对象，侦听对象和请求对象

在CAL中按照设备的功能预定义了多种对象，在HomPnP中按照对信息的收发方式将这些对象分为3类，分别采用一种特定的符号来表示。

状态对象（status object）：也称为“信息提供者”，它具有报告功能，对象的报告头report＿header报告地址report＿address绑定到CAL的报告功能向后面的“侦听对象”发送状态或数据；其中状态对象又细分为接收和不接收“请求对象”命令两类。

侦听对象listener object：它接收“状态对象”的报告，并能够根据接收的内容调整自己的工作。侦听对象没有报告功能。

请求对象reqeust object：能够发送“请求”改变状态对象的状态，它也是采用报告的机制实现的，请求对象的目的上下文就是状态对象所属的上下文。

在一个家庭自动化网络中，请求对象引起设备改变状态，接着状态对象公布设备状态的变化，所有的工作着的侦听对象都能收听到这个状态信息。这三种对象构成各子系统并通过松耦合实现互操作的基础。

2．3 家居模式上下文（Home Mode Context）

家居模式上下文是用来表示当前家庭状况的一个上下文，这是HomePnP一个重要的特性。这个上下文为所有的HomePnP子系统提供了表示当前家庭状况（如在家，离开，休息）的通用方法。通过接收关于这个上下文的HomePnP广播，所有子系统可以根据它们自己的设计来调整相应的行为。这种方法为家庭控制系统提供了一个完整和协调的解决方案。

3 互操性及其相关概念

互操性是指子系统可以和其系统内部的设备或者和其它的子系统进行协同工作，也就是说CAL的上下文模型支持子系统内或者子系统间的上下文协同工作。图2是互操性的模型示意。

3．1 绑定（bind）

对象之间的连接称为“绑定”(bind)。图3是一个带状态反馈的控制面板、指示面板与电风扇绑定，用户操作控制面板发出控制信号到电风扇

的侦听对象，电风扇的工作状态改变之后，又发出一个报告，这个报告反馈到控制面板，指示用户命令执行状态，同时另一个指示面板也收到电扇的状态报告，从而可以在远端更新指示。每个符号的箭头表示信息的流向。在HomePnP中定义了缺省报告地址、目的对象以及用CAL描述的报告内容的数据格式。当报告地址采用广播地址的时候，所有的设备都可以听到这个消息，但是不是所有的设备都会处理这个消息，因为有些设备没有报告中指定的目的对象。因此，一个传感器设备可以按照规定将测量得到的信号根据HomePnP的要求以CAL报告的形式发送到网络上；在其它设备中构造一个目的对象，也就是侦听对象，就可以获取这个信息。

3．2 子系统间的互操性

子系统间的互操性主要表现为松耦合(loose coupling)和缺省绑定（default binding）。

在HomePnP的规格说明书中，对每一种状态对象都规定了相应的侦听对象，它们有特定的对象序号，存在于特定的上下文中。状态对象在缺省情况下向一个正确的侦听对象发送消息。当然，侦听对象可以选择接收哪一个设备发出的状态消息，这就是“缺省绑定”。

某个状态设备正常工作时，用缺省绑定的方法把信息广播到网络上，它并不关心那些设备收到了消息。其它设备中只要有一个对应的侦听对象就可以获得这个信息，这样就可以省略数据链路层的绑定过程。由于收发设备之间没有明确的地址联系，因而称为“松耦合”（loose coupling）。松耦合采用HomePnP广播地址作为其报告地址。

松耦合是HomePnP的一个特点。HomePnP结构采用子系统松耦合等新思想，使设备的复杂性可按自然形态分层。在松耦合方式中，子系统可以向所有其它的HomePnP子系统报告状态信息，使得厂家在设计产品时不必详细了解其它厂家的产品。例如，我们可以设计一安全系统：如果窗户打开时空调器被启动，安全系统便发出告警。采用松耦合方式，安全系统只需配备一个合适的收听对象，用于收听来自环境监视的信息，按照约定接收来自空调器的报告。安全系统可以根据自己的设计决定使用或者不使用这个信息。请求对象也可通过网络引起状态变化。

3．3 系统内的互操性

HomePnP中也支持以确定的目的地址作为状态对象的报告地址的报告机制，这种报告叫做“紧耦合”（tight coupling）。由于紧耦合有明确的目标地址，因此可以减少网络冲突，并可以采用立即响应的方式。

子系统内的互操一般采用紧耦合的方式，如温控器和空调的关系，开关和灯的关系等等。紧耦合和松耦合的方法不同，松耦合的对象之间用虚线相连，表示为HomePnP广播消息，而紧耦合的对象之间用实线相连。

4 具有互操作性的即插即用家电系统

通过家庭即插即用，我们可以建立一个完整的具有互操作性的家电系统。其结构如图4所示。状态对象和侦听对象主要用于子系统内互操，而请求对象一般用于系统间互操作。在子系统A的控制器中实现一个状态对象，执行机构中实现对应的侦听对象。当用户操作控制器、或者控制器得到的传感器值变化时，就改变当前的状态并将更新的状态发送出去，然后执行机构根据这个状态调整自己的工作。请求对象存在于另外一个子系统B中，当它要改变A中执行机构的运行时，就向这个子系统的状态对象发送命令，从而实现子系统间互操。

典型的应用是这样的：家庭的每一个子系统都有一个控制器，这个控制器通过绑定关系与一些的传感器关联，可自动控制执行机构。各种传感器、控制器、以及用户输入按钮显示器等分散在家庭的多个设备中，通过绑定关系建立关联，它们之间的信息交换属于子系统内互操；在电视机中有各系统的请求对象，用户通过遥控器与电视机“对话”，从而控制其它任意一个子系统。电视机（或者是计算机）起到了集中监视和控制的作用，可以让用户浏览并控制所有设备，属于系统间互操。如图4所示。

即时通信现状篇（8）

国际上主流的家庭网络标准有：美国的X10、消费总线（CEBus）、日本的家庭总线（HomeBus）、欧洲的安装总线（EIB）。技术上并不先进的X10，只支持开关量，用于面板开关和继电器类的简单电器，但凭借价格低廉、性能可靠，尤其是它的易用性，一般用户均能自行安装，商业上取得了巨大的成功：450万户美国家庭采用X10，累计销售了1．2亿个模块。1984年，美国电子工业协会（Electronics Industry Association? EIA）认为X10协议已经不能满足现代生活的需要，并在1992年了CEBus（Consumer Electronic Bus）协议，其目标是建立一个针对消费类电子产品的开放性协议。1994年，CEBus工业委员会（CIC）成立，其成员为国际知名厂商。2002年6月，微软和CIC共同宣布支持基于CEBus的简单控制协议SCP，SCP是微软UPnP协议的子集。如果说X10是在低技术层次上，通过简单的操作来达到产品易用性，则CEBus是在高技术层次上，通过家电的互联、互操和即插即用来实现产品的易用性。HomePnP（HPnP）是CIC制定的基于公共应用语言（Common Application Language，简称CAL）的家电系统相互协同进行互操的规范。HPnP不是一种语言，它为支持CAL的家电提供统一的应用规则来实现家电的即插即用功能。

1 HPnP中传输协议的独立性

传输协议的独立性是HomePnP规范的最主要目标之一。 HomePnP规范使生产厂家可以使用一个应用协议，并选择合适的独立的传输网络（RF，PL，IR）。由于HomePnP计划运行于已有的消费电子产品协议如CEBus和IEEE 1394（Fire Wire）之上，所以它对下面的传输层只提出最少的要求，保持其独立性。

家庭产品即插即用（HomePnP）采用分层结构，通过三个主要的功能模块来处理应用层和更高层的问题。如图1所示。

最下层代表应用层及其相关的公共应用语言（CAL），它包含在EIA－600（CEBus）、EIA－721和EIA－766标准中，从而免去在不同产品之间设置昂贵的语言翻译网关。

上下文数据结构层代表各种各样用CAL句法开发而成的产品模型。通过定义安防、照明、环境、能源管理、家电设备、计算机和娱乐等的上下文，构成业界认同的家电产品模型。

最上层是系统指南，它指出即插即用安装的产品必须具有哪些行为特征。这些指导性的原则涉及到EIA－600中尚未解决的一些难题。

2 HPnP的结构

HomePnp通过5个不同层次的架构来实现家电的互操性。如表1所示。

HomePnP的架构组成要素

CAL提供的构造模块设备，上下文，上下文号，对象，实例变量，CAL报告，HomPnP广播和直接消息传输HomePnP采用的构造模块子系统，状态对象，侦听对象，请求对象，传感器信息共享，报警和故障诊断报告，家居模式子系统间的互操性模块松耦合，动态上下文序号，状态信息广播，状态向量，自动绑定和手动绑定子系统内的互操作模块紧耦合，安装工具其他的互操需求设备启用，设置，资源管理，消息处理，认证和加密的传输需求下面，仅对HomePnP构造模块和子系统互操模块进行介绍。

2．1 子系统?subsystem?

子系统是家庭控制网络中功能相似和相关的设备和设备集。例如：安防系统、照明系统、环境控制系统、家庭娱乐系统。一个子系统包含了一系列的CAL上下文，这些CAL上下文分别负责一部分的控制功能。HomePnP的子系统可以只存在一个设备当中，也可以分布在多个设备当中。

2．2 状态对象，侦听对象和请求对象

在CAL中按照设备的功能预定义了多种对象，在HomPnP中按照对信息的收发方式将这些对象分为3类，分别采用一种特定的符号来表示。

状态对象（status object）：也称为“信息提供者”，它具有报告功能，对象的报告头?report＿header?报告地址?report＿address?绑定到CAL的报告功能向后面的“侦听对象”发送状态或数据；其中状态对象又细分为接收和不接收“请求对象”命令两类。

侦听对象?listener object?：它接收“状态对象”的报告，并能够根据接收的内容调整自己的工作。侦听对象没有报告功能。

请求对象?reqeust object?：能够发送“请求”改变状态对象的状态，它也是采用报告的机制实现的，请求对象的目的上下文就是状态对象所属的上下文。

在一个家庭自动化网络中，请求对象引起设备改变状态，接着状态对象公布设备状态的变化，所有的工作着的侦听对象都能收听到这个状态信息。这三种对象构成各子系统并通过松耦合实现互操作的基础。

2．3 家居模式上下文（Home Mode Context）

家居模式上下文是用来表示当前家庭状况的一个上下文，这是HomePnP一个重要的特性。这个上下文为所有的HomePnP子系统提供了表示当前家庭状况（如在家，离开，休息）的通用方法。通过接收关于这个上下文的HomePnP广播，所有子系统可以根据它们自己的设计来调整相应的行为。这种方法为家庭控制系统提供了一个完整和协调的解决方案。

3 互操性及其相关概念

互操性是指子系统可以和其系统内部的设备或者和其它的子系统进行协同工作，也就是说CAL的上下文模型支持子系统内或者子系统间的上下文协同工作。图2是互操性的模型示意。

3．1 绑定（bind）

对象之间的连接称为“绑定”(bind)。图3是一个带状态反馈的控制面板、指示面板与电风扇绑定，用户操作控制面板发出控制信号到电风扇的侦听对象，电风扇的工作状态改变之后，又发出一个报告，这个报告反馈到控制面板，指示用户命令执行状态，同时另一个指示面板也收到电扇的状态报告，从而可以在远端更新指示。每个符号的箭头表示信息的流向。

在HomePnP中定义了缺省报告地址、目的对象以及用CAL描述的报告内容的数据格式。当报告地址采用广播地址的时候，所有的设备都可以听到这个消息，但是不是所有的设备都会处理这个消息，因为有些设备没有报告中指定的目的对象。因此，一个传感器设备可以按照规定将测量得到的信号根据HomePnP的要求以CAL报告的形式发送到网络上；在其它设备中构造一个目的对象，也就是侦听对象，就可以获取这个信息。

3．2 子系统间的互操性

子系统间的互操性主要表现为松耦合(loose coupling)和缺省绑定（default binding）。

在HomePnP的规格说明书中，对每一种状态对象都规定了相应的侦听对象，它们有特定的对象序号，存在于特定的上下文中。状态对象在缺省情况下向一个正确的侦听对象发送消息。当然，侦听对象可以选择接收哪一个设备发出的状态消息，这就是“缺省绑定”。

某个状态设备正常工作时，用缺省绑定的方法把信息广播到网络上，它并不关心那些设备收到了消息。其它设备中只要有一个对应的侦听对象就可以获得这个信息，这样就可以省略数据链路层的绑定过程。由于收发设备之间没有明确的地址联系，因而称为“松耦合”（loose coupling）。松耦合采用HomePnP广播地址作为其报告地址。

松耦合是HomePnP的一个特点。HomePnP结构采用子系统松耦合等新思想，使设备的复杂性可按自然形态分层。在松耦合方式中，子系统可以向所有其它的HomePnP子系统报告状态信息，使得厂家在设计产品时不必详细了解其它厂家的产品。例如，我们可以设计一安全系统：如果窗户打开时空调器被启动，安全系统便发出告警。采用松耦合方式，安全系统只需配备一个合适的收听对象，用于收听来自环境监视的信息，按照约定接收来自空调器的报告。安全系统可以根据自己的设计决定使用或者不使用这个信息。请求对象也可通过网络引起状态变化。

3．3 系统内的互操性

HomePnP中也支持以确定的目的地址作为状态对象的报告地址的报告机制，这种报告叫做“紧耦合”（tight coupling）。由于紧耦合有明确的目标地址，因此可以减少网络冲突，并可以采用立即响应的方式。

子系统内的互操一般采用紧耦合的方式，如温控器和空调的关系，开关和灯的关系等等。紧耦合和松耦合的方法不同，松耦合的对象之间用虚线相连，表示为HomePnP广播消息，而紧耦合的对象之间用实线相连。

4 具有互操作性的即插即用家电系统

通过家庭即插即用，我们可以建立一个完整的具有互操作性的家电系统。其结构如图4所示。状态对象和侦听对象主要用于子系统内互操，而请求对象一般用于系统间互操作。在子系统A的控制器中实现一个状态对象，执行机构中实现对应的侦听对象。当用户操作控制器、或者控制器得到的传感器值变化时，就改变当前的状态并将更新的状态发送出去，然后执行机构根据这个状态调整自己的工作。请求对象存在于另外一个子系统B中，当它要改变A中执行机构的运行时，就向这个子系统的状态对象发送命令，从而实现子系统间互操。

典型的应用是这样的：家庭的每一个子系统都有一个控制器，这个控制器通过绑定关系与一些的传感器关联，可自动控制执行机构。各种传感器、控制器、以及用户输入按钮显示器等分散在家庭的多个设备中，通过绑定关系建立关联，它们之间的信息交换属于子系统内互操；在电视机中有各系统的请求对象，用户通过遥控器与电视机“对话”，从而控制其它任意一个子系统。电视机（或者是计算机）起到了集中监视和控制的作用，可以让用户浏览并控制所有设备，属于系统间互操。如图4所示。

即时通信现状篇（9）

Keywords： instant messaging； high?performance long link； file transfer； communication recovery mechanism

随着移动网络的发展，网络聊天、视频和语音在网络通信中越来越受重视，从网络通信应用软件的用户量可以看出，网络即时聊天功能具有良好的用户体验[1]。在新开发的各类软件尤其是手机应用软件中，基本都会附带即时通信功能。这是一种发展趋势，网络通信已经成为了用户沟通的重要手段，渐渐地取代了传统的书信、短信等通信方式，使用的用户越来越多，同时用户对即时通信技术的稳定性要求也越来越高。但由于成熟的即时通信技术不开源，而开源的即时通信技术只实现了基本的建立链接，数据传输并没有做任何优化，使得在使用过程中经常出现消息延迟、消息丢失等情况[2]。

1 消息的即时传输

良好的用户体验对即时通信系统的消息传输具有较高的要求，尤其是消息的即时性。但在某些情况下，服务器并不能即时地将信息推送给接收者，存在着两种主要情况[3]。

（1） 客户端与服务器之间的通信长链接不稳定。服务器资源限制和网络问题的影响是客观存在的，从理论的角度没有办法避免。但可以从其他方面解决通信链接的稳定性对消息即时传输产生的影响。提出的高性能长链接、通信链接的检测和通信链接的恢复方法，有效地利用了服务器的资源，并保证链接断开后能够快速的恢复，从而保证消息的即时传输。

（2） 同一时间服务器需要推送的消息量较多。服务器转发消息也需要消耗时间，当同一时间进行即时通信的用户较多时，服务器来不及转发新接收的消息，导致了消息的阻塞，从而影响了消息的即时性。因此采用消息的并发推送方法解决消息阻塞的问题[4]。

1.1 高性能通信长链接

用户量的不断增加，服务器需要存储的通信链接越来越多，但一些通信链接在某些时候并不会被使用。通过分析得出客户端与服务器之间建立的通信长链接并不会随时都被利用，某些时间会处于空闲状态，为此提出了高性能通信长链接，尽量地减少客户端空闲状态下的链接时间，提高服务器的资源利用率，保证用户量剧增时通信链接不会因为服务器的资源限制而断开，从而保证消息的即时传输[5]。为了建立高性能通信链接，使用时间片轮转的算法。把用户开始登陆客户端的时间或者用户发送消息的时间记为开始时间，从开始时间起，把时间分为等长的时间片段假设得到的时间片段如图1所示。其中黑色区间表示在这个时间片段内用户有消息需要接收。白色的区域表示用户处于空闲状态没有消息需要接收。时间片轮转算法的目的是保证用户使用即时通信需要接收消息时，客户端与服务器存在通信链接[6]。而用户没有使用即时通信时，客户端与服务器之间不存在通信链接，从而释放了服务器的资源。时间片轮转算法的规则如下：

（1） 当客户端需要接收消息时，当前时间片为忙碌状态。相反如果没有消息需要接收，则当前时间片处于空闲状态。当用户登录软件后，默认第一个时间片为忙碌状态，并且客户端向服务器发送建立通信链接的请求。

（2） 如果当前时间片客户端处于忙碌状态，那么接下来的个时间片客户端都将主动向服务器端发送建立链接的请求。

（3） 如果当前时间片的前个时间片处于空闲状态，那么当前时间片的链接状态与前一个时间片的链接状态相反。例如前一个时间片客户端与服务器有通信链接，那么当前时间片客户端将向服务器发送断开链接的请求。

（4） 如果当前时间片的前个时间片中的任何一个时间片客户端处于忙碌状态，那么当前时间片客户端将向服务器发送建立链接的请求。

1.2 通信链接的检测和恢复

为了保证消息的即时传输，提高服务器长链接的效率，保证服务器与客户端链接稳定，避免意外中断情况的出现，采用有效的长链接检测方法和消息恢复方法[7]。理论上称客户端发送询问信息的过程为心跳过程，心跳时间指客户端向服务器发送询问信息的间隔时间。为了避免客户端频繁地发送心跳信息，消耗能量，或者避免心跳时间过长，导致消息传输的延迟。本文提出了心跳时间衰减函数如下：

（1）

式中：表示第时刻的心跳时间；表示第时刻的心跳时间；和表示时间衰减系数都是常量；表示最短的心跳时间间隔，同样也是一个常量；表示最长的心跳时间间隔，也是一个常量；new表示客户端发送了新的消息或者是服务器向客户端推送了新的消息。心跳机制和时间片轮转结合后，客户端只有处于忙碌状态时才会发送心跳信息。这样既保证了通信链接的稳定，又节约了服务器的资源。

1.3 客户端通信恢复机制

当客户端启动后，在客户端的后台会启动两个线程，在Android中使用Service服务，Service相当于Activity，只是没有界面而是运行在后台的服务。其中一个线程按照定时器的设定不停地向服务器发送心跳信息，确认客户端与服务器的通信链接是否正常[8]。另外一个线程用于监听服务器，接收服务器推送的消息。通过心跳机制，当客户端检测到与服务器的通信长链接断开时，需要向服务器请求再次建立链接以及获取离线数据。

为了进一步降低服务器的数据处理压力，提升用户体验。提出了一种获取离线消息的方法，通过短链接的方式获取离线消息[9]。短链接指的是客户端向服务器发送请求会携带必要的参数，而服务器做出响应时也会把客户端想获取的数据返回，当客户端得到数据后链接就断开，如图2所示。

基于这种方式，当客户端与服务器的链接再次建立后，由客户端主动发送获取离线消息的请求，获取离线消息可以使用HTTP协议。客户端不用发送确认信息，服务器在返回信息后可以直接清除数据库中暂存的数据，同时服务器也不用每次都对新建立的链接做查询操作，这样大大减少了服务器的压力，同时使获取离线消息的过程变得清晰，不会出现消息重复的情况。

1.4 消息并发推送

如果某一时刻发送消息的用户较多，而服务器来不及把消息推送给目标客户端，那么就会造成服务器需要推送的消息越来越多，最终导致服务器消息的阻塞。消息阻塞虽然不会导致消息的丢失，但是会严重影响消息的即时传输，会给用户带来特别不好的使用体验。

为了解决这个问题，在服务器端使用了消息的并发机制。当服务器从客户端接收到一条新的消息后，把消息存放在本地数据库的同时也会把消息存放进一个队列。而在服务器的后台，即时通信系统会根据服务器处理器的使用情况开启若干个线程，每一个线程所做的操作都相同，从队列中取出一个消息，然后根据消息中的目标地址，查询与其是否有通信链接，如果存在则把消息推送给客户端，如果不存在则不做任何处理。这样服务器可以在同一时间推送多条消息，有效地利用了服务器的资源，降低了消息阻塞的可能性。

2 消息的可靠传输

2.1 消息握手协议

为了确保消息在传输过程中不会出现丢失，提出了消息传输的握手协议。握手协议分为客户端给服务器发送消息的握手和服务器给客户端推送消息的握手。握手协议的本质是客户端与服务器端约定的消息传输规则，握手的主要目的就是为了确保消息不会丢失。

（1） 正向握手协议

正向握手协议是指客户端向服务器端发送消息时消息的确认协议。客户端需要发送消息时，会先把消息存放在本地数据库中，然后再调用发送消息的接口，存入本地数据库中的消息标记为未发送。如果服务器成功接收到消息，会给客户端返回一个包含了消息ID的反馈信息，表示自己已经接收到消息，客户端接收到反馈信息后，根据ID把本地数据库中的消息标记为已经发送，这样就完成了一次客户端到服务器的握手。如果没有接收到服务器的反馈信息，那么客户端将继续向服务器发送这条消息。

（2） 反向握手协议

反向握手协议指的是服务器端向客户端推送消息时消息的确认协议。当服务器接收到客户端的消息后，首先会把消息存在数据库中，然后从消息中解析出接收人的地址信息，然后根据地址信息查找目标客户端与自己是否有通信链接。

2.2 文件传输协议

为了避免使用通信长链接传输文件，提出了文件和文件地址相分离的传输方法，文件存储服务的提供商会提供文件上传的相应接口，客户端通过调用接口，上传文件后，会得到一个文件的网络地址，通过该网络地址用户就可以直接下载文件。

3 高复用架构

3.1 服务器

消息即时传输系统具有高复用性，就不能与应用软件的功能结合，本文提出了单系统双服务的系统架构。单系统指功能完全的应用软件系统，而双服务指为应用软件提供了后台服务的两套服务系统：消息的即时通信系统和数据功能处理系统。这样把消息和软件功能分离后，就可以使消息的即时传输服务在任何应用软件中使用，其功能模块如图3所示。

为了保证消息后台服务器的安全性，本节提出了双服务权限认证的方法。为了叙述简便，把消息后台服务器简称为消息系统，而应用软件的数据处理服务器简称为功能系统，如图4所示。通过这种方式，不仅增加了通信系统的安全性，同时也做到了功能的分离，使即时通信系统的后台通用性更高。

3.2 客户端

客户端和服务器的设计思想类似，单独把即时通信的功能打包封装，仅对外提供数据的操作接口，如图5所示。客户端的即时通信主要包含五个功能：发送建立链接的请求；发送消息；接收消息；发送心跳信息；断开通信链接，用户退出系统时会调用断开通信链接的功能，用于释放服务器的资源。应用程序的客户端添加即时通信的功能包后，只需要根据自己消息格式修改对本地数据库的操作，对外提供的接口不变[10]。

4 系统测试

4.1 测试系统介绍

测试系统的主要功能是用于学校老师、学生家长和学生之间的沟通，为学校管理学生带来便利。同时也包含了即时通信的功能模块，用于用户之间的交流沟通，发送团队公告信息和发送申请加入团队的申请信息。

应用系统在添加即时通信功能时，采用了本文设计的即时通信框架。后台使用了双服务器设计，提供了一个独立的消息系统和一个功能系统，两个系统之间使用同一个权限缓存。消息系统主要负责处理与客户端的消息通信，功能系统使用的是短链接，为客户端提供了获取数据的接口。客户端加入了即时通信包，并按照自己的需求对数据存储格式和数据读取格式做了修改。

服务器的配置是2 GB内存、双核、2.6 GB的主频，2 MB的网络带宽，客户端使用Android系统的手机。把一个客户端叫A，另一个客户端叫B。

4.2 实验结果

测试过程中通过改变客户端的工作状态来模拟用户的各种使用情况。

测试1：参数设置：客户端A、客户端B同时登陆系统，客户端A给客户端B发送消息。测试结果：客户端B能正常接收到客户端A发送的消息。

测试2：参数设置：客户端A、客户端B同时登陆系统，客户端A和客户端B同时给对方发送消息。测试结果：客户端A和客户端B都能正常接收到对方发送的消息。

测试3：参数设置：客户端A登陆系统，向客户端B发送消息。客户端B在客户端A发送消息后，登陆系统。测试结果：客户端A发送消息成功，客户端B正常接收到客户端A发送的消息。

通过用例测试，应用程序中的即时通信功能在很多情况下正常使用，满足了本文对即时通信框架功能的要求。

压力测试中，设置3个测试参数，并发人数、每个客户端共发送消息的条数、每两条消息发送的时间间隔（单位：ms）。对私人聊天、群聊天和发送通知进行了压力测试，消息发送和接收的成功率都在100%。但也有消息发送和接收不到100%，甚至有88%的成功率。通过分析可以发现，当消息发送成功率不高时，客户端的在线人数和发送消息的量普遍偏高，发送消息的频率也较快，而且发送成功率和这几个参数之间还有反比的关系。

即时通信现状篇（10）

1 引言

防火墙部署于网络流量的必经节点，如果防火墙出现故障，将会导致网络中断。防火墙的热备机制保证了单点故障后，当前的会话或者后建立的会话不会中断。双机热备的机制支持A/S模式和A/A模式两种工作模式，在这两种模式下防火墙即可部署在透明模式又可以部署在路由模式，可广泛适用于各种复杂的组网需求。

2 双机热备工作模式

双机热备解决方案根据组网情况有两种工作模式：主备模式（A/S）和负载均衡模式（A/A）。在这两种模式中，设备的角色根据是否承担流量来决定：有流量经过的设备即为主设备，无流量经过的设备即为备份设备。

2.1 A/S模式设计

A/S（Active/Standby）模式即主备模式，其中一个防火墙称为Active_Firewall，另一个防火墙称为Standby_Firewall。正常情况下Active_Firewall处理所有通信任务。并将自身的会话信息和状态信息实时的复制给Standby_Firewall；Standby防火墙不处理任何通信，只接收Standby防火墙的会话信息和状态信息。当Active防火墙出现故障，Standby防火墙立刻接管Active防火墙的所有通信。进而确保新建立起的会话能正常通信，当前正在运行的会话也不会中断。具体的设计方式如图1所示。

2.2 A/A模式设计

A/A（Active/ Active）模式即负载均衡模式，也即是两个防火墙均称为Active防火墙。他们在正常通信时根据当前的流量自动调整自己的会话，保证每个防火墙的压力都不是很大，进而提高防火墙资源的利用率，同时两台防火墙各自实时对对端的防火墙的会话信息进行备份。当其中一个防火墙出现故障，另外一个防火墙立刻接管故障防火墙的所有会话，保证通信不会中断。但是这台防火墙的压力会变大。具体的设计方式如图2所示。

3 双机热备实现机制

3.1 数据同步

两种工作模式的“心跳线” 链接用于在两台防火墙之间传递主备协商消息和配置同步。可以用以Ethernet链路作为故障切换的链接，这个Ethernet接口就不能再同时用于其他用途。它的好处在于可以支持两台相距较远的防火墙热备，并且配置的同步更快。两台防火墙除了“心跳线”链接外，还可以增加“状态链接”，“状态链接”用于在两台防火墙之间传递TCP链接状态等系统实时状态信息。状态链接仅支持用Ethernet链接。如果两台防火墙之间只有“心跳线”，没有“状态线”链接，当防火墙切换时会话会暂时中断，之后重新建立会话链接。但是当两条链接都具备时候，防火墙切换不会中断。因为通过“状态”链路，活动防火墙会实时的将自己的状态发给备份防火墙。当备份防火墙初始化完成后，会从活动防火墙同步配置；此时查看查看从防火墙的配置和状态信息与主防火墙一致。当登录到备份防火墙的配置界面时候，见到的是主防火墙的配置界面。

3.2 流量切换

负载均衡模式中，两个设备可以同时传送流量。当其中一个设备down掉时候，另外一个设备自动接管全部流量。主备模式中，同一时间，只能有一个设备传输流量，另一个设备作为备份用。当主防火墙down掉时候，备份防火墙接管主防火墙的所有流量。

4 双机热备的条件限制

双机热备的两台防火墙应满足如下条件：首先，要求设备型号和硬件（设备模块、接口类型，接口数量，CPU，内存，flash闪存等）配置相同；其次，软件的版本号和特征集（如支持的加密同为DES或者3DES）一致；最后防火墙部署模式必须同为路由模式或者透明模式。否则初始化的信息以及运行中的状态信息无法复制到令外一个设备上。致使会话错误。总之，A/S模式防火墙利用率低，A/A模式防火墙利用率高，但是具体选择哪种模式要根据网络的需求而定。

参考文献

[1]陈波，于泠.防火墙技术与应用[M].北京：机械工业出版社，2013.

[2]阎慧，王伟，宁宇.防火墙原理与技术[M].北京：机械工业出版社，2009.

作者简介