即时通信现状范例(3篇)
即时通信现状范文
智能家居要求家用电器经网络（总线）实现互联、互操和即插即用。目前，国内市场的相关产品大多基于自定义的某种技术规范，尚无得到广泛认同的统一家电接口标准。从技术角度而言，更多意义上还是一种概念性产品。国家经贸委和信息产业部第七标准化小组将在2003年推出有关智能家居网络系统的标准，其中一个重要的标准就是家电的接口规范。智能家居产业的健康发展有赖于这一标准和规范的指导。
国际上主流的家庭网络标准有：美国的X10、消费总线（CEBus）、日本的家庭总线（HomeBus）、欧洲的安装总线（EIB）。技术上并不先进的X10，只支持开关量，用于面板开关和继电器类的简单电器，但凭借价格低廉、性能可靠，尤其是它的易用性，一般用户均能自行安装，商业上取得了巨大的成功：450万户美国家庭采用X10，累计销售了1．2亿个模块。1984年，美国电子工业协会（ElectronicsIndustryAssociation?EIA）认为X10协议已经不能满足现代生活的需要，并在1992年了CEBus（ConsumerElectronicBus）协议，其目标是建立一个针对消费类电子产品的开放性协议。1994年，CEBus工业委员会（CIC）成立，其成员为国际知名厂商。2002年6月，微软和CIC共同宣布支持基于CEBus的简单控制协议SCP，SCP是微软UPnP协议的子集。如果说X10是在低技术层次上，通过简单的操作来达到产品易用性，则CEBus是在高技术层次上，通过家电的互联、互操和即插即用来实现产品的易用性。HomePnP（HPnP）是CIC制定的基于公共应用语言（CommonApplicationLanguage，简称CAL）的家电系统相互协同进行互操的规范。HPnP不是一种语言，它为支持CAL的家电提供统一的应用规则来实现家电的即插即用功能。
1HPnP中传输协议的独立性
传输协议的独立性是HomePnP规范的最主要目标之一。HomePnP规范使生产厂家可以使用一个应用协议，并选择合适的独立的传输网络（RF，PL，IR）。由于HomePnP计划运行于已有的消费电子产品协议如CEBus和IEEE1394（FireWire）之上，所以它对下面的传输层只提出最少的要求，保持其独立性。
家庭产品即插即用（HomePnP）采用分层结构，通过三个主要的功能模块来处理应用层和更高层的问题。如图1所示。
最下层代表应用层及其相关的公共应用语言（CAL），它包含在EIA－600（CEBus）、EIA－721和EIA－766标准中，从而免去在不同产品之间设置昂贵的语言翻译网关。
上下文数据结构层代表各种各样用CAL句法开发而成的产品模型。通过定义安防、照明、环境、能源管理、家电设备、计算机和娱乐等的上下文，构成业界认同的家电产品模型。
最上层是系统指南，它指出即插即用安装的产品必须具有哪些行为特征。这些指导性的原则涉及到EIA－600中尚未解决的一些难题。
2HPnP的结构
HomePnp通过5个不同层次的架构来实现家电的互操性。如表1所示。
HomePnP的架构组成要素
CAL提供的构造模块设备，上下文，上下文号，对象，实例变量，CAL报告，HomPnP广播和直接消息传输HomePnP采用的构造模块子系统，状态对象，侦听对象，请求对象，传感器信息共享，报警和故障诊断报告，家居模式子系统间的互操性模块松耦合，动态上下文序号，状态信息广播，状态向量，自动绑定和手动绑定子系统内的互操作模块紧耦合，安装工具其他的互操需求设备启用，设置，资源管理，消息处理，认证和加密的传输需求下面，仅对HomePnP构造模块和子系统互操模块进行介绍。
2．1子系统?subsystem?
子系统是家庭控制网络中功能相似和相关的设备和设备集。例如：安防系统、照明系统、环境控制系统、家庭娱乐系统。一个子系统包含了一系列的CAL上下文，这些CAL上下文分别负责一部分的控制功能。HomePnP的子系统可以只存在一个设备当中，也可以分布在多个设备当中。
2．2状态对象，侦听对象和请求对象
在CAL中按照设备的功能预定义了多种对象，在HomPnP中按照对信息的收发方式将这些对象分为3类，分别采用一种特定的符号来表示。
状态对象（statusobject）：也称为“信息提供者”，它具有报告功能，对象的报告头?report＿header?报告地址?report＿address?绑定到CAL的报告功能向后面的“侦听对象”发送状态或数据；其中状态对象又细分为接收和不接收“请求对象”命令两类。
侦听对象?listenerobject?：它接收“状态对象”的报告，并能够根据接收的内容调整自己的工作。侦听对象没有报告功能。
请求对象?reqeustobject?：能够发送“请求”改变状态对象的状态，它也是采用报告的机制实现的，请求对象的目的上下文就是状态对象所属的上下文。
在一个家庭自动化网络中，请求对象引起设备改变状态，接着状态对象公布设备状态的变化，所有的工作着的侦听对象都能收听到这个状态信息。这三种对象构成各子系统并通过松耦合实现互操作的基础。
2．3家居模式上下文（HomeModeContext）
家居模式上下文是用来表示当前家庭状况的一个上下文，这是HomePnP一个重要的特性。这个上下文为所有的HomePnP子系统提供了表示当前家庭状况（如在家，离开，休息）的通用方法。通过接收关于这个上下文的HomePnP广播，所有子系统可以根据它们自己的设计来调整相应的行为。这种方法为家庭控制系统提供了一个完整和协调的解决方案。
3互操性及其相关概念
互操性是指子系统可以和其系统内部的设备或者和其它的子系统进行协同工作，也就是说CAL的上下文模型支持子系统内或者子系统间的上下文协同工作。图2是互操性的模型示意。
3．1绑定（bind）
对象之间的连接称为“绑定”(bind)。图3是一个带状态反馈的控制面板、指示面板与电风扇绑定，用户操作控制面板发出控制信号到电风扇的侦听对象，电风扇的工作状态改变之后，又发出一个报告，这个报告反馈到控制面板，指示用户命令执行状态，同时另一个指示面板也收到电扇的状态报告，从而可以在远端更新指示。每个符号的箭头表示信息的流向。
在HomePnP中定义了缺省报告地址、目的对象以及用CAL描述的报告内容的数据格式。当报告地址采用广播地址的时候，所有的设备都可以听到这个消息，但是不是所有的设备都会处理这个消息，因为有些设备没有报告中指定的目的对象。因此，一个传感器设备可以按照规定将测量得到的信号根据HomePnP的要求以CAL报告的形式发送到网络上；在其它设备中构造一个目的对象，也就是侦听对象，就可以获取这个信息。
3．2子系统间的互操性
子系统间的互操性主要表现为松耦合(loosecoupling)和缺省绑定（defaultbinding）。
在HomePnP的规格说明书中，对每一种状态对象都规定了相应的侦听对象，它们有特定的对象序号，存在于特定的上下文中。状态对象在缺省情况下向一个正确的侦听对象发送消息。当然，侦听对象可以选择接收哪一个设备发出的状态消息，这就是“缺省绑定”。
某个状态设备正常工作时，用缺省绑定的方法把信息广播到网络上，它并不关心那些设备收到了消息。其它设备中只要有一个对应的侦听对象就可以获得这个信息，这样就可以省略数据链路层的绑定过程。由于收发设备之间没有明确的地址联系，因而称为“松耦合”（loosecoupling）。松耦合采用HomePnP广播地址作为其报告地址。
松耦合是HomePnP的一个特点。HomePnP结构采用子系统松耦合等新思想，使设备的复杂性可按自然形态分层。在松耦合方式中，子系统可以向所有其它的HomePnP子系统报告状态信息，使得厂家在设计产品时不必详细了解其它厂家的产品。例如，我们可以设计一安全系统：如果窗户打开时空调器被启动，安全系统便发出告警。采用松耦合方式，安全系统只需配备一个合适的收听对象，用于收听来自环境监视的信息，按照约定接收来自空调器的报告。安全系统可以根据自己的设计决定使用或者不使用这个信息。请求对象也可通过网络引起状态变化。
3．3系统内的互操性
HomePnP中也支持以确定的目的地址作为状态对象的报告地址的报告机制，这种报告叫做“紧耦合”（tightcoupling）。由于紧耦合有明确的目标地址，因此可以减少网络冲突，并可以采用立即响应的方式。
子系统内的互操一般采用紧耦合的方式，如温控器和空调的关系，开关和灯的关系等等。紧耦合和松耦合的方法不同，松耦合的对象之间用虚线相连，表示为HomePnP广播消息，而紧耦合的对象之间用实线相连。
4具有互操作性的即插即用家电系统
通过家庭即插即用，我们可以建立一个完整的具有互操作性的家电系统。其结构如图4所示。状态对象和侦听对象主要用于子系统内互操，而请求对象一般用于系统间互操作。在子系统A的控制器中实现一个状态对象，执行机构中实现对应的侦听对象。当用户操作控制器、或者控制器得到的传感器值变化时，就改变当前的状态并将更新的状态发送出去，然后执行机构根据这个状态调整自己的工作。请求对象存在于另外一个子系统B中，当它要改变A中执行机构的运行时，就向这个子系统的状态对象发送命令，从而实现子系统间互操。
典型的应用是这样的：家庭的每一个子系统都有一个控制器，这个控制器通过绑定关系与一些的传感器关联，可自动控制执行机构。各种传感器、控制器、以及用户输入按钮显示器等分散在家庭的多个设备中，通过绑定关系建立关联，它们之间的信息交换属于子系统内互操；在电视机中有各系统的请求对象，用户通过遥控器与电视机“对话”，从而控制其它任意一个子系统。电视机（或者是计算机）起到了集中监视和控制的作用，可以让用户浏览并控制所有设备，属于系统间互操。如图4所示。
图4是一个粗略的示意图，实际上图中的每一个子系统都有复杂的组织结构。图5为基于CEBus的家庭智能住宅结构图。
即时通信现状范文
技术状态控制。技术状态控制是对技术状态项基线的控制，也就是在技术状态基线建立之后，对相关技术状态文件更改所进行的控制。对于非技术状态项，或者技术状态基线未经正式审查或审核建立之前，对相关文件的更改不实行技术状态控制，但必须按照各单位的《设计文件更改制度》《图样管理制度》等相关制度进行管理。只有在基线建立之后，对技术状态项的更改才要实施技术状态控制。技术状态纪实的内容包括已确定的技术状态文件、提出的更改状况和已批准更改的执行情况；技术状态纪实的具体活动或形式是对上述内容所作的正式记录和报告。
技术状态审核通常有两类：功能技术状态审核和物理技术状态审核。功能技术状态审核是指为证实技术状态项是否达到了功能技术状态文件（功能基线加上已批准的更改）和分配技术状态文件（分配基线加上已批准的更改）中规定的功能和性能特性所进行的正式检查。物理技术状态审核是指为证实已制出的技术状态项是否符合其产品技术状态文件中规定的物理特性所进行的正式检查。每一个技术状态项都应进行功能技术状态审核和物理技术状态审核。对通信系统实施技术状态管理就是为了确保通信系统研制过程中产生的所有技术状态文件都与其相对应的已制定的技术状态项文实相符，而技术状态审核正是为判断技术状态项是否符合技术状态文件所进行的正式的检查。技术状态审核的具体形式通常是在通信系统研制完成以后，由供需双方对其所进行的验收。在美军的研制程序中，在其工程研制阶段的后期和生产部署阶段的前期，进行功能技术状态审核和物理技术状态审核后，研制产品即可进入成批生产，不再进行合格鉴定。通常，对通信产品的技术状态审核是在产品完成研制后，对已制成品的最后审核和验收，审核和验收的内容包括技术状态项和通信系统的所有功能特性和物理特性，包括：功能、性能、物理特性、环境适应性、可靠性、维修性、保障性、安全性、可测量性等等，即技术状态文件规定的所有内容。
一个具有良好的技术状态管理的项目可以确保：设计的可追溯性；更改受到控制并形成文件；接口得到定义并便于理解；产品及其支持文件保持一致。总之，技术状态管理可以使得通信系统、分系统、技术状态项的研制、生产、使用能有序或顺利地进行。
值得一提的是，对于Configuration一词的译法，从上世纪80年代中期这一名词引用后，就有多种不同意见。在英汉技术词典中，该词的直译为外形、轮廓；构造、构型；配置等。当时，用法较多的是构型、技术状态和配置。1987年颁发的《军工产品质量管理条例》提出了要实行技术状态管理的要求，并明确了技术状态管理的内容就是Configuration的内容。针对软件研制的特点和习惯，软件采用了“配置”的提法，故，软件的配置管理就是技术状态管理在软件工程中的具体形式。
技术状态管理
根据技术状态管理的4个工作内容，通信系统的技术状态管理应包括以下活动：选择技术状态项；确定每个技术状态项所需的技术状态文件；指定技术状态项及规范文件（包括内部和外部接口文件）的标识号；发放技术状态文件；建立技术状态基线；对技术状态进行审核、纪实和控制等等。技术状态管理是以技术状态项作为单元来进行的，恰当地确定技术状态项是有效进行技术状态管理的首要内容。技术状态项的定义为：“能满足最终使用功能，并被指定作为单个实体进行技术状态管理的硬件、软件或其集合体”。选择通信系统的技术状态项主要依据以下两个条件予以判断：（1）能满足最终使用功能，即该项目具备功能特性和物理特性。通信系统一般更侧重于功能特性；（2）被指定为单个实体，也就是说，它是一个独立的单个的实体而不是一个普通的零、部件。只有这种项目才能对其功能特性和物理特性进行标识控制和审核，才有进行技术状态管理的必要。
技术状态管理的策划是技术状态管理过程的基础。技术状态管理的策划包括：确定产品技术状态管理活动的人员与职责；明确技术状态项；确定产品技术状态管理的里程碑；确定每个技术状态项所需的技术状态文件；指定技术状态项及规范文件（包括内部和外部接口文件）的标识号；明确产品技术状态管理各项活动的管理流程，包括：技术状态文件发放、技术状态控制、技术状态纪实及技术状态审核；分承制方/供应商的控制；数据管理等等。技术状态的管理最终是对技术状态基线的管理。技术状态基线即是在技术状态项研制过程的某一特定时刻，被正式确认、并被作为今后研制、生产活动基准的技术状态文件。GJB3206A－2010标准明确要求确定三种技术状态基线：功能基线、分配基线和产品基线。
技术状态基线的具体形式是技术状态文件。在研制初期阶段，首先制定系统级的功能技术状态文件，确定功能基线；根据功能技术状态文件，即功能基线的要求，在下一研制阶段中，制定描述各技术状态项功能的技术状态文件，即分配技术状态文件，确定分配基线；根据分配技术状态文件，即分配基线的要求，进一步制定产品制造所必须的各类文件、图样，即产品技术状态文件，确定产品基线。上述技术状态文件在不同的研制阶段进行编制，批准和保持，且在内容上逐级细化，即构成各级的技术状态基线。通过对设计基线的控制实现对通信系统、分系统及技术状态项的研制工作控制，同时，基线也是转阶段决策的重要输入。至此，我们可以进一步说，通信系统的技术状态管理实质是就是以技术状态项作为单元，对技术状态项及通信系统产品技术基线的管理。
通信系统技术状态管理实例
某通信系统是一个可自组网的移动通信系统，通过移动交换机可实现整个系统的动中通，并实现与多种网系的互联互通。该系统包括移动分系统、移动交换机；其中移动分系统包括移动基站和移动终端，一个移动基站可带50个移动终端。
（1）对系统按组成进行结构分解，形成WBS（工作结构分解）图，如图1所示。根据该通信系统结构分解，可列出该系统的项目编码表，见表1。
（2）确定技术状态项根据通信系统的特点，选择准则至少有以下3条：
1）系统项目；
2）用于通信系统管理和信道分配与接入的项目；
3）对功能性能起关键作用的项目。
按照上述四项准则，该系统的技术状态项为：
第一级：依据准则1，移动通信系统为技术状态项。第二级：依据准则1，移动分系统为技术状态项；依据准则2，移动交换机为技术状态项。
第三级：依据准则3，移动基站、移动终端为技术状态项；依据准则2和准则3，移动交换机的主处理单元、网关单元、接口1单元、接口2单元、A接口单和接口4单元为技术状态项。
第四级：依据准则3，移动基站的基带单元、发射单元、接收单元和功放单元为技术状态项。故该通信系统技术状态项如表2所示。
（3）确定技术状态计划
GJB3206A-2010中附录B针对技术状态管理计划进行了说明，文中明确：技术状态文件的载体形式和文字格式按自行规定执行，但给出了通常应包括的13项内容。分析文中给出的13项内容，其中有半数内容当产品类型一定，则内容即可确定。故就通信产品而言，可针对不同的产品类型编制不同的技术状态计划。每一名设计师或相关人员进入该产品设计团队，必须先学习技术状态计划，了解进而熟悉该产品类型技术状态管理的基本职责和要求，包括：技术状态管理的职责；技术状态项及规范文件的标识方法；技术状态文件发放、控制、纪实及审核的要求和流程；分承制方/供应商的控制规定；数据管理规则等等，此后才能从事该产品相关的设计和开发工作。其中有一部分内容，虽然是同一类型产品，但针对不同的设计和开发项目其内容必然不同，如技术状态项的选择，技术状态文件的识别等等，针对这些内容必须编制一对一的技术状态计划。这部分内容可单独形成技术状态计划，也可放入该项目的设计和开发计划之中。
（4）技术状态基线的确定
在项目论证阶段，与顾客协商确认技术状态要求；项目确定以后，由项目技术负责人组织编制移动通信系统（第一级）功能基线的技术状态文件。在总体方案设计阶段，由项目技术负责人组织编制移动通信系统（第一级）分配基线的技术状态文件。移动通信系统（第一级）分配基线的技术状态文件即是第二级移动分系统和移动交换机的功能基线的技术状态文件。在技术实施方案设计阶段，由移动分系统和移动交换机的项目技术负责人组织编制移动分系统和移动交换机的分配基线的技术状态文件。移动分系统的分配基线的技术状态文件即是移动基站的功能基线的技术状态文件。同样移动基站的技术负责人应依据移动基站的功能基线技术状态文件组织编制移动基站分配基线的技术状态文件。最后，当系统设计定型后，所有技术状态项的产品基线确定。
结束语
即时通信现状范文篇3
关键词：即时通信；XMPP；XML
中图分类号：TP312文献标识码：A文章编号：1007-9599(2011)16-0000-02
XMPP-basedReal-TimeCommunicationProtocolIntroduction
LiuWei
(InformationCenterofSuzhouRailwayTransportationCompanyLtd.,Suzhou215007,China)
Abstract:XMPPhasbeensuccessfullyappliedinmanyindustryfields.Thisarticlegivesanintroductionandanalysisonthecharacteristics,architecture,conceptandcorefeaturesofXMPP.
Keywords:Real-timecommunication;XMPP;XML
一、XMPP协议起源
第一版XMPP技术于1998年由JeremieMiller开发，当时名为Jabber，目的是用于可靠的在线交流，之后改名为XMPP（eXtensibleMessagingandPresenceProtocol）可扩展消息与状态协议，该协议以XML（eXtensibleMarkupLanguage）格式交换数据，最初专用于即时通信领域，经过十多年的发展XMPP已成为即时通信协议中最可靠最具灵活性的协议之一。
二、XMPP协议特点
XMPP协议是自由、开放和公开的，当前在客户端和服务器端有多种实现，其源代码也都是开放的。
XMPP协议是标准协议，互联网工程任务组（IETF）已将其标准化并收录到技术规范RFC3920和RFC3921中。
XMPP协议具备优良的可扩展性，很容易为其添加新的功能，由此使得XMPP协议在即时通信之外的领域得到了广泛的使用，包括网络管理、协同工具、远程系统监控和网络游戏等。
XMPP协议具备良好的安全性，简单认证安全层（SASL）和传输层安全（TLS）技术已内建在XMPP技术规范中。
三、XMPP架构分析
XMPP技术使用一种松散的客户端-服务器架构，有些类似于电子邮件网络服务，没有唯一的服务器负责为所有用户提供服务，而是很多的服务器都分散在不同位置，每一台服务器只为特定一批用户服务，如果位于不同服务器内的用户有通信需求，通过服务器连接模块将服务器连接起来就可以。当一处的服务器出现故障只会影响当地的用户，而不会对其他用户中断服务。
四、XMPP基本概念
首先，任何系统的使用都需要一个账号，在XMPP的世界里这个账号称作JabberID简称JID，JID的格式和电子邮件地址类似，例如就可以是一个JID。
其次，在上面的JID中，还有一个概念就是域（Domain），比如上面的，在登陆的时候客户端就是用这个域去寻找可用的XMPP服务器而不是用IP地址。
另外，由于XMPP服务器允许同一账号重复登录，比如同时在手机和电脑上用登陆服务器，这时手机的XMPP客户端软件会自动在账号后面追加一个资源名（resource）例如/mobile，而电脑的XMPP客户端软件提交给服务器的全名则可能是/pc，这样在不同设备的同一个账号就可以在XMPP服务器里被区分开来。形如JID/resource这种账号形式XMPP社区通常将其称为fullJID，而当没有resource的时候则称为bareJID。
XMPP技术是基于XML流（XMLstream）的技术，当和XMPP服务器创建会话时，需要先和服务器建立一个TCP长连接并在这个连接上给服务器发送XML流进行服务协商，在协商过程中服务器也会给客户端发送XML流来回应请求。一旦协商通过，客户端和服务器就会通过XML流和对方用以下三种XML节（XMLstanza）进行数据交换：，和。
这三种XMLstanza是XMPP技术的最基本语义单元，下面对它们的用途做说明。
标签用于将信息从一处通过服务器传送到另一处，常用于一对一聊天，多人聊天，通知，预警和报错，下面的例子就是用户a给用户b发送了一条“Hello”的文本消息。
to="b@123.lit"
type="chat">
Hellovar_userid='';var_siteid=2230;var_istoken=1;var_model='Model03';WebPageSpeed=234;UrchinTrack();
标签用于通知或转发客户端的状态信息，比如上线下线等，下面的例子是用户a将自己的状态信息“xa”（离开）和附加状态文字“gotolibrary!”发给服务器，服务器会将a的状态转发给订阅了a的状态的在线用户；
xa
gotolibrary!
这个标签用于请求-回应操作，类似于HTTP协议的GET，POST和PUT方法，它和前面的，的最大不同在于发出请求后一定要收到回复即使回复是空的，通常客户端针对好友列表管理的添删改查操作都是用这个标签操作的。
下面这个例子是在PDA上登录的用户向XMPP服务器请求这个账号的好友列表数据。
id="rr82a1z7"
to=""
type="get">
接下来是服务器的回复。
id="rr82a1z7"
to="/pda"
type="result">
五、XMPP核心功能
作为服务于即时通信的技术标准，其核心功能不外乎两个――消息发送（Messaging）和状态（Presence），这里对这两项功能做相应说明。
（一）状态
在XMPP网络中，查看他人的状态信息（Presence）并非是需求方一厢情愿就够的，需要得到被查看方的允许，因为并非所有人都同意自己在网络中的状态被别人随意看到。
所以当用户需要看某人的状态信息时，他需要向对方发送请求并得到对方的允许，XMPP术语将这个发送请求称为subscriberequest.
上面是用户向用户发出订阅状态信息的请求。
如果用户c同意a的订阅请求，用户a会收到如下的XMLstanza：
如果用户c不同意a的订阅请求，用户a收到的信息则是：
在上面的例子中，如果用户c同意a的订阅请求，a会把c加入到自己的好友列表中，同时c也会把a加入自己的好友列表中（针对不同的XMPP服务器实现，c不一定会加a）。
接下来分析用户登录过程中，用户的好友如何获得用户的上线状态的。
1.用户客户端和服务端协商建立XMLstream；
2.客户端给服务器发送一个登录初始状态的XMLstanza，如；
3.服务器检索出有哪些人成功订阅了这个用户的状态；
4.服务器将这个用户的状态发送给这些订阅者。
在登录完成之后使用客户端过程中，如果用户将自己状态由在线（available）改为离开（away），也是通过类似流程将新的状态信息通知给这些订阅者的。
（二）消息传送
这个部分分析XMPP的聊天消息是如何快速的从发送方转到接收方的。
由于XMPP的设计初衷就是应用于即时通信，故而在处理实时传送消息数量很多而每条消息内容又相对较少的聊天业务时，在设计和实现上做了很多优化。
还是用一个具体的例子来说明，用户给发一条消息“Whoareyou?”，XMLstanza的内容如下所示：
to=""
type="chat">
Whoareyou?var_userid='';var_siteid=2230;var_istoken=1;var_model='Model03';WebPageSpeed=203;UrchinTrack();
用户jack将消息发送给这台服务器后，服务器从这个XMLstanza中取出“to”地址，对其它内容则不做任何处理以提高性能，发现目标地址是服务器，于是通过服务器连接模块马上和服务器建立一条XMLstream（如果之前和有过通信则建立XMLstream的步骤可省略）并将这个XMLstanza发到服务器。
收到这条消息后，也是从中取出目标“to”地址，发现其域名和自己一致，于是在本地网络查找用户bill是否在线，如果bill在线就将消息发送给bill，如果不在线就丢弃（可配置写入数据库待上线后再发送）。在这个过程中服务器对XMLstanza不做任何其他多余的解析，也不会将收到的stanza写入数据库保持起来（成功发给接收用户情况下），因此消息的传送是非常快速和及时的。