CN102769582B - 逻辑服务器、即时通信系统和即时通信方法 - Google Patents
逻辑服务器、即时通信系统和即时通信方法 Download PDFInfo
- Publication number
- CN102769582B CN102769582B CN201210273295.0A CN201210273295A CN102769582B CN 102769582 B CN102769582 B CN 102769582B CN 201210273295 A CN201210273295 A CN 201210273295A CN 102769582 B CN102769582 B CN 102769582B
- Authority
- CN
- China
- Prior art keywords
- logical server
- account
- server
- logical
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Abstract
本发明提供了一种逻辑服务器,包括:判断单元,向账号服务器发送获取请求,根据返回的账号数据判断请求账号是否属于逻辑服务器的管辖范围,账号服务器用于保存每个逻辑服务器的节点号以及管辖的账号数据;查找单元,在请求账号不属于管辖范围时,查找出相应的逻辑服务器,并将相应的节点号返回至请求账号;信息反馈单元,在登录成功后,通过数据服务器获取相关联的信息并反馈至请求账号,数据服务器用于保存与每个账号相关联的信息。本发明还提出了一种即时通信系统和一种即时通信方法。通过本发明的技术方案,采用特定的设计框架,既可以提高数据传输的速度与可靠性,又可以节省成本,满足了即时通讯支持大量用户的需求。
Description
技术领域
本发明涉及计算机通信领域,具体而言,涉及一种逻辑服务器、一种即时通信系统和一种即时通信方法。
背景技术
在当前随着移动互联网的崛起,在移动终端上都需要一种个性化的即时通讯工具进行一些专用领域的沟通交流需求。一些大型企业需要本企业专用的企业即时通讯工具和移动终端一起组成一个大的体系,通过PC、移动终端,随时随地实现自己的专用沟通交流需求。
即时通讯要求消息发送快速,实时,稳定。还需要能获知关心用户的状态。特别是大型企业,每个人需要实时获知其他所有人的状态,而每次状态变化都需要广播很多客户端,对服务端设计和架构带来不小的挑战。
因此,需要一种新的即时通信软件,通过采用特定的设计框架,既可以提高数据传输的速度与可靠性,又可以节省成本。
发明内容
本发明正是基于上述问题,提出了一种逻辑服务器,既可以提高数据传输的速度与可靠性,又可以节省成本。
有鉴于此,根据本发明的一个方面,提出了一种逻辑服务器,包括:判断单元,向账号服务器发送获取请求,根据所述账号服务器返回的账号数据,判断发出登录请求的请求账号是否属于所述逻辑服务器的管辖范围,所述账号服务器用于保存每个逻辑服务器的节点号以及每个逻辑服务器管辖的账号数据;查找单元,用于在所述请求账号不属于所述管辖范围时,通过所述账号服务器查找出应管辖所述请求账号的逻辑服务器,并将查找出的逻辑服务器的节点号返回至所述请求账号;信息反馈单元,在所述请求账号登录成功后,通过数据服务器获取与所述请求账号相关联的信息并将获取的信息反馈至所述请求账号,所述数据服务器用于保存与每个账号相关联的信息。
在该技术方案中,每个逻辑服务器的可管辖一个或多个账号,每个账号也对应着相应的逻辑服务器,每个逻辑服务器的地位平等,多个逻辑服务器形成一个网状结构,账号的登录和信息获取不必通过中心服务器才能实现,也就没有负载压力施加在登录节点或中心节点上,而且也不需要为了追求可靠性而闲置的热备份节点、冷备份节点,减少了服务器资源的浪费。其中,与每个账号相关联的信息可以是成功登录信息,用户组列表信息,用户状态信息,离线消息等、用户之间的交流消息。
另一方面,数据服务器可以采用nosql(非关系型的数据库)思想,将数据存储于共享内存中,进一步地,可以采用哈希(hash)账号存储每个账号的相关数据,这保证了在数据服务器中有节点崩溃的情况下或断电时,数据在内存也不会丢失,可以在数据服务器的其他未崩溃或未断电的节点上查询到数据,这种结构完全抛弃了数据库,避免了数据库在查询、更新数据上的慢速而成为整个系统的瓶颈。而且数据库软件本身价格昂贵,而当今内存已经相对廉价而且容量大。
通过上述结构既可以提高数据传输的速度与可靠性,又可以节省成本。
在上述技术方案中,优选地,还可以包括:通信单元,建立所述逻辑服务器与其他逻辑服务器之间的连接,将与所述逻辑服务器管辖的账号相关联的信息发送至所述其他逻辑服务器进行保存;请求接管单元,在所述逻辑服务器发生崩溃时,请求所述其他逻辑服务器中管辖账号的数目最小的逻辑服务器接管所述逻辑服务器所管辖的账号,以及在所述逻辑服务器正常启动时,请求所述管辖账号的数目最小的逻辑服务器重新由所述逻辑服务器管辖原有账号。
在该技术方案中,多个逻辑服务器可以组成的前端节点集群为用户服务,所有逻辑服务器之间两两互联,当一逻辑服务器登录到另一逻辑服务器上时,都可以相当于一个用户客户端登录到该另一逻辑服务器上,当一个本地逻辑服务器检测到另一个逻辑服务器登录进来,即开始检测本地的逻辑服务器是否有需要通知另一个逻辑服务器的信息,如果有,可以一个报文将大量的用户信息压缩发送至另一个逻辑服务器,并同时检测本地的逻辑服务器是否有需要推送至另一个逻辑服务器的离线消息,如果有,则将其推送至另一个逻辑服务器。这种处理流程使得逻辑服务器的模型设计变得简单。
由于逻辑服务器之间两两互联,其中一个逻辑服务器发生崩溃时,其他逻辑服务器都可以感知到此逻辑服务器发生崩溃,而且任一逻辑服务器都可以检测到其他逻辑服务器的负载状态(所有逻辑服务器全部崩溃的情况为极小概率事件,所以总会存在一个未崩溃的逻辑服务器可以为用户返回信息),因此,当请求账号请求登录的逻辑服务器发生崩溃时,多个逻辑服务器中管辖账号的数目最小(即负载最小)的逻辑服务器暂时接受该请求账号的登录,而当两个逻辑服务器之间的连接断开时,则说明其中一个逻辑服务器已经崩溃且不能对外服务了,此时未崩溃的逻辑服务器也可以在多个逻辑服务器中查询到一个负载最小的逻辑服务器作为已崩溃的逻辑服务器的备份节点(即暂时接替崩溃逻辑服务器完成其工作)。
当崩溃的逻辑服务器恢复正常时,其他逻辑服务器可以检测到其恢复正常,那么暂时接管的逻辑服务器停止接受恢复工作的逻辑服务器所管辖的账号的登录,并其管辖的账号可重新登录至恢复工作的逻辑服务器。
这种结构使得用户在管辖其账号的逻辑服务器发生崩溃时也可以登录其他逻辑服务器并进行相应操作,并在管辖其账号的逻辑服务器恢复工作后,可以自动重新登录至恢复工作的逻辑服务器。
在上述技术方案中,优选地,还可以包括:通知单元,在所述请求账号不属于所述逻辑服务器的管辖范围且所述查找出的逻辑服务器发生崩溃时,将所述管辖账号的数目最小的逻辑服务器的节点号通知所述请求账号。
在该技术方案中,当用户登录的逻辑服务器不是管辖其账号的逻辑服务器或查找出的逻辑服务器发生崩溃时,可以将负载最小的逻辑服务器的节点告知登录账号,供登录账号选择是否登录。
在上述技术方案中,优选地,所述通信单元通过传输控制协议与所述其他逻辑服务器建立数据连接。
在该技术方案中,逻辑服务器之间可以采用传输控制协议(TCP,Transmission Control Protocol)连接,虽然传输层复杂,但是逻辑层简单。传输数据可靠,安全,能随时方便地传输大量数据,而且在检测用户是否下线的判断上比UDP(User Datagram Protocol,用户数据报协议)具有天然的优势,特别是在支持基于企业架构的IM(Instant Messenger,即时通信)时,客户端登录时需要传输的瞬时爆发数据量很大,TCP可以以一个报文将所有数据传输至客户端。
而且TCP采用二进制,和一些文本的IM协议相比减少了文本编解码在中央处理器上的开销,减小了报文长度,减少了服务端和客户端每次发送数据的长度,节省了系统资源,特别对于移动互联网设备,能够减小带宽和电量消耗,而一些基于UDP的IM协议,需要定时发送心跳信息,增加了流量和系统开销。
在上述任一技术方案中,优选地,还包括:状态序列号生成单元,根据所述请求账号上次成功登录所生成的状态序列号生成当前登录操作的状态序列号;控制登录单元,若所述请求帐号具有多个登录操作,则执行所述状态序列号最大的登录操作,以登录所述逻辑服务器;存储单元,保存所述请求账号本次登录的状态序列号。
在该技术方案中,一个逻辑服务器可能同时收到其他逻辑服务器和IM用户的登录状态通知,相当于一个全局数据接收到了不同数据源的更新请求,由于网络传输和逻辑处理的问题,先产生的状态后到,后产生的状态先到,如果不管理好顺序,则可能发生错误的状态覆盖,那么就必须判断出采用那个数据才是正确的,以免产生错误的状态覆盖。
本申请采用以一个序列号来标记数据的时间的先后顺序,如对于登录操作,可以从上次登录成功的逻辑服务器取回状态序列号,然后加一,得到当前登录的状态序列号,那么在一个账号存在多个登录操作时,则可以根据状态序列号,只保留状态序列号最大的登录操作在线,保证了一号一登录实例的要求,避免了登录状态异常。
根据本发明的另一方面,还提出了一种即时通信系统,包括:多个上述任一项所述的逻辑服务器、至少一个数据服务器和至少一个账号服务器,其中,所述多个逻辑服务器之间通过传输控制协议建立数据连接;所述账号服务器连接至每个所述逻辑服务器,用于保存所述逻辑服务器所管辖的账号数据;所述数据服务器连接至每个所述逻辑服务器,用于保存与每个账号相关联的信息。
在该技术方案中,每个逻辑服务器的可管辖一个或多个账号,每个账号也对应着相应的逻辑服务器,每个逻辑服务器的地位平等,多个逻辑服务器形成一个网状结构,账号的登录和信息获取不必通过中心服务器才能实现,也就没有负载压力施加在登录节点或中心节点上,而且也不需要为了追求可靠性而闲置的热备份节点、冷备份节点,减少了服务器资源的浪费。其中,与每个账号相关联的信息可以是成功登录信息,用户组列表信息,用户状态信息,离线消息等、用户之间的交流消息。
逻辑服务器管理IM用户设计上,所有用户都可以放在用户组里,用户组以树状结构管理,和企业的组织结构上在模型的逻辑的抽向上时完全一致的。这种设计能够同时支持企业的组织结构和基于个人的IM需求,同用户组的用户之间可以互相看到对方的状态,进而在用户登录系统时,系统可以智能地判断一个用户能够看到哪些用户的状态,而不像采用其他协议的系统,需要发送订阅信息,系统才能够根据订阅信息判断应该发送哪位用户的状态,这增加了交互的报文和系统进行逻辑处理的模块。
根据本发明的又一方面,还提出了一种即时通信方法,用于所述即时通讯系统,包括:在登录所述即时通讯系统中的逻辑服务器时,判断发出登录请求的请求账号是否属于所述逻辑服务器的管辖范围;在所述请求账号不属于所述管辖范围时,通过所述即时通讯系统中的账号服务器查询到管辖所述请求账号的逻辑服务器,并将查找出的逻辑服务器的节点号返回至所述请求账号;所述请求账号根据所述节点号向所述查找出的逻辑服务器发送登录请求,在登录成功后,所述查找出的逻辑服务器向所述请求账号返回与所述请求账号相关联的信息。
在该技术方案中,每个逻辑服务器的管辖范围内可以包括多个账号,每个账号也对应着相应的逻辑服务器,每个逻辑服务器的地位平等,多个逻辑服务器形成一个网状结构,账号的登录和信息获取不必通过中心服务器才能实现,也就没有负载压力施加在登录节点或中心节点上,而且也不需要为了追求可靠性而闲置的热、冷备份节点,减少了服务器资源的浪费。其中,与每个账号相关联的信息可以是成功登录信息,用户组列表信息,用户状态信息,离线消息等。
另一方面,数据服务器可以采用nosql思想,将数据存储于共享内存中,进一步地,可以采用hash账号存储每个账号的相关数据,这保证了在数据服务器中有节点崩溃的情况下或断电时,数据在内存也不会丢失,可以在数据服务器的其他未崩溃或未断电的节点上查询到数据,这种结构完全抛弃了数据库,避免了数据库在查询、更新数据上的慢速而成为整个系统的瓶颈。而且数据库软件本身价格昂贵,而当今内存已经相对廉价而且容量大。
通过上述结构既可以提高数据传输的速度与可靠性,又可以节省成本。
在上述技术方案中,优选地,还包括:所述查找出的逻辑服务器将与所管辖的账号相关联的信息发送至所述其他逻辑服务器进行保存;若所述查找出的逻辑服务器发生崩溃,则由所述其他逻辑服务器中管辖账号的数目最小的逻辑服务器接管所述查找出的逻辑服务器所管辖的账号;若所述查找出的逻辑服务器重新正常启动,则重新由所述查找出的逻辑服务器管辖原有账号。
在该技术方案中,多个逻辑服务器可以组成前端节点集群为用户服务,而且所有逻辑服务器之间两两互联,每个逻辑服务器都可以相当于一个用户登录到其他逻辑服务器上,当一个逻辑服务器检测到另一个逻辑服务器登录进来时,开始检测本地的逻辑服务器是否有需要通知另一个逻辑服务器的信息,如果有,则可以一个报文将大量的用户信息压缩发送至另一个逻辑服务器,同时检测本地的逻辑服务器是否有需要推送至另一个逻辑服务器的离线消息,如果有,则将离线消息推送至另一个逻辑服务器。这种处理流程使得逻辑服务器的模型设计变得简单。
由于逻辑服务器之间两两互联,其中一个逻辑服务器发生崩溃时,其他逻辑服务器都可以感知到此逻辑服务器发生崩溃,而且任一逻辑服务器都可以检测到其他逻辑服务器的负载状态(所有逻辑服务器全部崩溃的情况为极小概率事件,所以总会存在一个未崩溃的服务器可以为用户返回信息),因此,当账号登录的逻辑服务器发生崩溃时,多个逻辑服务器中管辖账号的数目最小(即负载最小)的逻辑服务器暂时接受账号的登录,而当两个逻辑服务器之间的连接断开时,则说明其中一个逻辑服务器已经崩溃且不能对外服务了,此时未崩溃的逻辑服务器也可以在多个逻辑服务器中查询到一个负载最小的逻辑服务器作为已崩溃的逻辑服务器的备份节点(即暂时完成其工作)。
当崩溃的逻辑服务器恢复正常时,其他逻辑服务器可以检测到其恢复正常,那么暂时接管的逻辑服务器停止接受恢复工作的逻辑服务器所管辖的账号的登录,并定向账号重新登录至恢复工作的逻辑服务器。
这种结构使得用户在管辖其账号的逻辑服务器发生崩溃时也可以登录并进行相应操作,并在管辖其账号的逻辑服务器恢复工作后,可以自动重新登录至恢复工作的逻辑服务器。
在上述技术方案中,优选地,还可以包括:在所述请求账号登录所述查找出的逻辑服务器时,若所述查找出的逻辑服务器发生崩溃,则尝试登录所述其他逻辑服务器中的一个逻辑服务器;若所述其他逻辑服务器中的一个逻辑服务器不是所述管辖账号数目最小的逻辑服务器,则由所述其他逻辑服务器中的一个逻辑服务器通知所述请求账号所述管辖账号数目最小的逻辑服务器的节点号。
在该技术方案中,当用户登录的逻辑服务器不是管辖其账号的逻辑服务器或查找出的逻辑服务器发生崩溃时,可以将负载最小的逻辑服务器的节点告知登录账号,供登录账号选择是否登录。
在上述技术方案中,优选地,所述查找出的逻辑服务器与所述其他逻辑服务器之间通过传输控制协议建立数据连接。
在该技术方案中,逻辑服务器之间可以采用传输控制协议连接,虽然传输层复杂,但是逻辑层简单。传输数据可靠,安全,能随时方便地传输大量数据,而且在检测用户是否下线的判断上比UDP具有天然的优势,特别是在支持基于企业架构的IM时,客户端登录时需要传输的瞬时爆发数据量很大,TCP可以以一个报文将所有数据传输至客户端。
而且TCP采用二进制,和一些文本的IM协议相比减少了文本编解码在中央处理器上的开销,减小了报文长度,减少了服务端和客户端每次发送数据的长度,节省了系统资源,特别对于移动互联网设备,能够减小带宽和电量消耗,而一些基于UDP的IM协议,需要定时发送心跳信息,增加了流量和系统开销。
在上述任一技术方案中,优选地,还可以包括:获取所述请求账号上次成功登录所生成的状态序列号;根据所述状态序列号得到当前登录操作的状态序列号;若所述请求帐号具有多个登录操作,则执行所述状态序列号最大的登录操作,以登录所述查找出的逻辑服务器;保存本次成功登录的状态序列号。
在该技术方案中,一个逻辑服务器可能同时收到其他逻辑服务器和IM用户的登录状态通知,相当于一个全局数据接收到了不同数据源的更新请求,而由于网络传输和逻辑处理的问题,可能先产生的状态后到,后产生的状态先到,如果不管理好顺序,则可能发生错误的状态覆盖,那么就必须判断出采用那个数据才是正确的,以免产生错误的状态覆盖。
本申请采用以一个序列号来标记数据的时间的先后顺序,如对于登录操作,可以从上次登录成功的逻辑服务器取回状态序列号,然后加一,得到当前登录的状态序列号,那么在一个账号存在多个登录操作时,则可以根据状态序列号,只保留状态序列号最大的登录操作在线,保证了一号一登录实例的要求,避免了登录状态异常。
通过以上技术方案,既可以提高数据传输的速度与可靠性,又可以节省成本。
附图说明
图1示出了根据本发明的实施例的逻辑服务器的框图;
图2示出了根据本发明的实施例的即时通信系统的框图;
图3示出了根据本发明的实施例的即时通信方法的流程图;
图4示出了本发明的实施例的客户端登录的流程图;
图5示出了本发明的实施例的逻辑服务器与客户端之间交互的流程图;
图6示出了根据本发明的实施例的逻辑服务器之间交互的流程图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是,在不冲突的情况下,本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是,本发明还可以采用其他不同于在此描述的其他方式来实施,因此,本发明的保护范围并不受下面公开的具体实施例的限制。
图1示出了根据本发明的实施例的逻辑服务器的框图。
如图1所示,逻辑服务器100包括:判断单元102,向账号服务器发送获取请求,根据账号服务器返回的账号数据,判断发出登录请求的请求账号是否属于逻辑服务器100的管辖范围,该账号服务器用于保存每个逻辑服务器100的节点号以及每个逻辑服务器管辖的账号数据;查找单元104,用于在请求账号不属于管辖范围时,通过账号服务器查找出应管辖请求账号的逻辑服务器,并将查找出的逻辑服务器的节点号返回至请求账号;信息反馈单元106,在请求账号登录成功后,通过数据服务器获取与请求账号相关联的信息并将获取的信息反馈至请求账号,数据服务器用于保存与每个账号相关联的信息。
在该技术方案中,每个逻辑服务器100可管辖一个或多个账号,每个账号也对应着相应的逻辑服务器100,每个逻辑服务器100的地位平等,多个逻辑服务器100形成一个网状结构,账号的登录和信息获取不必通过中心服务器才能实现,也就没有负载压力施加在登录节点或中心节点上,而且也不需要为了追求可靠性而闲置的热备份节点、冷备份节点,减少了服务器资源的浪费。其中,与每个账号相关联的信息可以是成功登录信息,用户组列表信息,用户状态信息,离线消息、用户之间的交流消息等。
另一方面,数据服务器可以采用nosql(非关系型的数据库)思想,将数据存储于共享内存中,进一步地,可以采用哈希(hash)账号存储每个账号的相关数据,这保证了在数据服务器中有节点崩溃的情况下或断电时,数据在内存也不会丢失,可以在数据服务器的其他未崩溃或未断电的节点上查询到数据,这种结构完全抛弃了数据库,避免了数据库在查询、更新数据上的慢速而成为整个系统的瓶颈。而且数据库软件本身价格昂贵,而当今内存已经相对廉价而且容量大。
通过上述结构既可以提高数据传输的速度与可靠性,又可以节省成本。
在上述技术方案中,优选的,还可以包括:通信单元108,建立逻辑服务器100与其他逻辑服务器100之间的连接,将与逻辑服务器100管辖的账号相关联的信息发送至其他逻辑服务器100进行保存;请求接管单元110,在逻辑服务器100发生崩溃时,请求其他逻辑服务器100中管辖账号的数目最小的逻辑服务器100接管逻辑服务器100所管辖的账号,以及在逻辑服务器100正常启动时,请求管辖账号的数目最小的逻辑服务器100重新由逻辑服务器100管辖原有账号。
在该技术方案中,多个逻辑服务器100可以组成的前端节点集群为用户服务,所有逻辑服务器100之间两两互联,当一逻辑服务器登录到另一逻辑服务器上时,都可以相当于一个用户客户端登录到该另一逻辑服务器100上,当一个本地逻辑服务器100检测到另一个逻辑服务器登录进来,即开始检测本地的逻辑服务器100是否有需要通知另一个逻辑服务器的信息,如果有,可以一个报文将大量的用户信息压缩发送至另一个逻辑服务器,并同时检测本地的逻辑服务器100是否有需要推送至另一个逻辑服务器100的离线消息,如果有,则将其推送至另一个逻辑服务器。这种处理流程使得逻辑服务器100的模型设计变得简单。
由于逻辑服务器100之间两两互联,其中一个逻辑服务器发生崩溃时,其他逻辑服务器都可以感知到此逻辑服务器发生崩溃,而且任一逻辑服务器都可以检测到其他逻辑服务器的负载状态(所有逻辑服务器全部崩溃的情况为极小概率事件,所以总会存在一个未崩溃的逻辑服务器可以为用户返回信息),因此,当请求账号请求登录的逻辑服务器100发生崩溃时,多个逻辑服务器中管辖账号的数目最小(即负载最小)的逻辑服务器100暂时接受该请求账号的登录,而当两个逻辑服务器之间的连接断开时,则说明其中一个逻辑服务器已经崩溃且不能对外服务了,此时未崩溃的逻辑服务器也可以在多个逻辑服务器中查询到一个负载最小的逻辑服务器作为已崩溃的逻辑服务器的备份节点(即暂时接替崩溃逻辑服务器完成其工作)。
当崩溃的逻辑服务器恢复正常时,其他逻辑服务器可以检测到其恢复正常,那么暂时接管的逻辑服务器停止接受恢复工作的逻辑服务器所管辖的账号的登录,并其管辖的账号可重新登录至恢复工作的逻辑服务器。
这种结构使得用户在管辖其账号的逻辑服务器发生崩溃时也可以登录其他逻辑服务器并进行相应操作,并在管辖其账号的逻辑服务器恢复工作后,可以自动重新登录至恢复工作的逻辑服务器。
在上述技术方案中,优选的,该逻辑服务器100还可以包括:通知单元112,在请求账号不属于逻辑服务器100的管辖范围且查找出的逻辑服务器发生崩溃时,将管辖账号的数目最小的逻辑服务器100的节点号通知请求账号。
在该技术方案中,当用户登录的逻辑服务器不是管辖其账号的逻辑服务器或查找出的逻辑服务器发生崩溃时,可以将负载最小的逻辑服务器的节点告知登录账号,供登录账号选择是否登录。
在上述技术方案中,通信单元108通过传输控制协议与其他逻辑服务器100建立数据连接。
在该技术方案中,逻辑服务器100之间可以采用传输控制协议连接,虽然传输层复杂,但是逻辑层简单。传输数据可靠,安全,能随时方便地传输大量数据,而且在检测用户是否下线的判断上比用户数据报协议(UDP,User Datagram Protocol)具有天然的优势,特别是在支持基于企业架构的即时通讯(IM,Instant Messenger)时,客户端登录时需要传输的瞬时爆发数据量很大,传输控制协议(TCP)可以以一个报文将所有数据传输至客户端。
而且TCP采用二进制,和一些文本的IM协议相比减少了文本编解码在中央处理器上的开销,减小了报文长度,减少了服务端和客户端每次发送数据的长度,节省了系统资源,特别对于移动互联网设备,能够减小带宽和电量消耗,而一些基于UDP的IM协议,需要定时发送心跳信息,增加了流量和系统开销。
在上述任一技术方案中,还可以包括:状态序列号生成单元114,根据请求账号上次成功登录所生成的状态序列号生成当前登录操作的状态序列号;控制登录单元116,若请求帐号具有多个登录操作,则执行状态序列号最大的登录操作,以登录该逻辑服务器;存储单元118,保存请求账号本次登录的状态序列号。
在该技术方案中,一个逻辑服务器100可能同时收到其他逻辑服务器和IM用户的状态通知,相当于一个全局数据接收到了不同数据源的更新请求,由于网络传输和逻辑处理的问题,先产生的状态后到,后产生的状态先到,如果不管理好顺序,则可能发生错误的状态覆盖,那么就必须判断出采用那个数据才是正确的,以免产生错误的状态覆盖。本申请采用序列号来标记数据的时间的先后顺序,如对于登录操作,可以从上次登录成功的逻辑服务器100取回状态序列号,然后加一,得到当前登录的状态序列号,那么在一个账号存在多个登录操作时,则可以根据状态序列号,只保留状态序列号最大的登录操作在线,保证了一号一登录实例的要求,避免了登录状态异常。
图2示出了根据本发明的实施例的即时通信系统的框图。如图2所示,即时通信系统200包括:多个如图1所示的逻辑服务器100、至少一个数据服务器202和至少一个账号服务器204,其中,多个逻辑服务器100之间通过传输控制协议建立数据连接;账号服务器204连接至每个逻辑服务器100,用于保存逻辑服务器100所管辖的账号数据;数据服务器202连接至每个逻辑服务器100,用于保存与每个账号相关联的信息。
在该技术方案中,即时通信系统200中的每个逻辑服务器100具有与图1所示的逻辑服务器相同的技术效果,每个逻辑服务器100可管辖一个或多个账号,每个账号也对应着相应的逻辑服务器100,每个逻辑服务器100的地位平等,多个逻辑服务器100形成一个网状结构,账号的登录和信息获取不必通过中心服务器才能实现,也就没有负载压力施加在登录节点或中心节点上,而且也不需要为了追求可靠性而闲置的热备份节点、冷备份节点,减少了服务器资源的浪费。其中,与每个账号相关联的信息可以是成功登录信息,用户组列表信息,用户状态信息,离线消息、用户之间的交流消息等。
逻辑服务器100管理IM用户设计上,所有用户都可以放在用户组里,用户组以树状结构管理,和企业的组织结构上在模型的逻辑的抽向上时完全一致的。这种设计能够同时支持企业的组织结构和基于个人的IM需求,同用户组的用户之间可以互相看到对方的状态,进而在用户登录系统时,系统可以智能地判断一个用户能够看到哪些用户的状态,而不像采用其他协议的系统,需要发送订阅信息,系统才能够根据订阅信息判断应该发送哪位用户的状态,这增加了交互的报文和系统进行逻辑处理的模块。
图3示出了根据本发明的实施例的即时通信方法的流程图。
如图3所示,根据本发明的实施例的即时通信方法包括:
步骤302,在登录如图2所示的即时通讯系统中的逻辑服务器时,判断发出登录请求的请求账号是否属于逻辑服务器的管辖范围;步骤304,在请求账号不属于管辖范围时,通过即时通讯系统中的账号服务器查询到管辖请求账号的逻辑服务器,并将查找出的逻辑服务器的节点号返回至请求账号;步骤306,请求账号根据节点号向所述查找出的逻辑服务器发送登录请求;步骤308,在登录成功后,查找出的逻辑服务器向请求账号返回与请求账号相关联的信息。
在该技术方案中,每个逻辑服务器的可管辖一个或多个账号,每个账号也对应着相应的逻辑服务器,每个逻辑服务器的地位平等,多个逻辑服务器形成一个网状结构,账号的登录和信息获取不必通过中心服务器才能实现,也就没有负载压力施加在登录节点或中心节点上,而且也不需要为了追求可靠性而闲置的热备份节点、冷备份节点,减少了服务器资源的浪费。其中,与每个账号相关联的信息可以是成功登录信息,用户组列表信息,用户状态信息,离线消息、用户之间的交流消息等。
另一方面,数据服务器可以采用nosql思想,将数据存储于共享内存中,进一步地,可以采用哈希(hash)账号存储每个账号的相关数据,这保证了在数据服务器中有节点崩溃的情况下或断电时,数据在内存也不会丢失,可以在数据服务器的其他未崩溃或未断电的节点上查询到数据,这种结构完全抛弃了数据库,避免了数据库在查询、更新数据上的慢速而成为整个系统的瓶颈。而且数据库软件本身价格昂贵,而当今内存已经相对廉价而且容量大。
通过上述结构既可以提高数据传输的速度与可靠性,又可以节省成本。
在上述技术方案中,还包括:查找出的逻辑服务器将与所管辖的账号相关联的信息发送至其他逻辑服务器进行保存;若查找出的逻辑服务器发生崩溃,则由其他逻辑服务器中管辖账号的数目最小的逻辑服务器接管查找出的逻辑服务器所管辖的账号;若查找出的逻辑服务器重新正常启动,则重新由查找出的逻辑服务器管辖原有账号。
在该技术方案中,多个逻辑服务器可以组成的前端节点集群为用户服务,而且所有逻辑服务器之间两两互联,当一逻辑服务器登录到另一逻辑服务器上时,都可以相当于一个用户客户端登录到该另一逻辑服务器上,当一个本地逻辑服务器检测到另一个逻辑服务器登录进来时,开始检测本地的逻辑服务器是否有需要通知另一个逻辑服务器的信息,如果有,则可以一个报文将大量的用户信息压缩发送至另一个逻辑服务器,同时检测本地的逻辑服务器是否有需要推送至另一个逻辑服务器的离线消息,如果有,则将离线消息推送至另一个逻辑服务器。这种处理流程使得逻辑服务器的模型设计变得简单。
由于逻辑服务器之间两两互联,其中一个逻辑服务器发生崩溃时,其他逻辑服务器都可以感知到此逻辑服务器发生崩溃,而且任一逻辑服务器都可以检测到其他逻辑服务器的负载状态(所有逻辑服务器全部崩溃的情况为极小概率事件,所以总会存在一个未崩溃的逻辑服务器可以为用户返回信息),因此,当请求账号请求登录的逻辑服务器发生崩溃时,多个逻辑服务器中管辖账号的数目最小(即负载最小)的逻辑服务器暂时接受该请求账号的登录,而当两个逻辑服务器之间的连接断开时,则说明其中一个逻辑服务器已经崩溃且不能对外服务了,此时未崩溃的逻辑服务器也可以在多个逻辑服务器中查询到一个负载最小的逻辑服务器作为已崩溃的逻辑服务器的备份节点(即暂时接替崩溃逻辑服务器完成其工作)。
当崩溃的逻辑服务器恢复正常时,其他逻辑服务器可以检测到其恢复正常,那么暂时接管的逻辑服务器停止接受恢复工作的逻辑服务器所管辖的账号的登录,并其管辖的账号可重新登录至恢复工作的逻辑服务器。
这种结构使得用户在管辖其账号的逻辑服务器发生崩溃时也可以登录其他逻辑服务器并进行相应操作,并在管辖其账号的逻辑服务器恢复工作后,可以自动重新登录至恢复工作的逻辑服务器。
在上述技术方案中,还包括:在请求账号登录查找出的逻辑服务器时,若查找出的逻辑服务器发生崩溃,则尝试登录其他逻辑服务器中的一个逻辑服务器;若其他逻辑服务器中的一个逻辑服务器不是管辖账号数目最小的逻辑服务器,则由其他逻辑服务器中的一个逻辑服务器通知请求账号管辖账号数目最小的逻辑服务器的节点号。
在该技术方案中,当用户登录的逻辑服务器不是管辖其账号的逻辑服务器或查找出的逻辑服务器发生崩溃时,可以将负载最小的逻辑服务器的节点告知登录账号,供登录账号选择是否登录。
在上述技术方案中,查找出的逻辑服务器与其他逻辑服务器之间通过传输控制协议建立数据连接。
在该技术方案中,逻辑服务器之间可以采用传输控制协议连接,虽然传输层复杂,但是逻辑层简单。传输数据可靠,安全,能随时方便地传输大量数据,而且在检测用户是否下线的判断上比UDP具有天然的优势,特别是在支持基于企业架构的IM时,客户端登录时需要传输的瞬时爆发数据量很大,TCP可以以一个报文将所有数据传输至客户端。
而且TCP采用二进制,和一些文本的IM协议相比减少了文本编解码在中央处理器上的开销,减小了报文长度,减少了服务端和客户端每次发送数据的长度,节省了系统资源,特别对于移动互联网设备,能够减小带宽和电量消耗,而一些基于UDP的IM协议,需要定时发送心跳信息,增加了流量和系统开销。
在上述任一技术方案中,还包括:获取请求账号上次成功登录所生成的状态序列号;根据状态序列号得到当前登录操作的状态序列号;若请求帐号具有多个登录操作,则执行状态序列号最大的登录操作,以登录查找出的逻辑服务器;保存本次成功登录的状态序列号。
在该技术方案中,一个逻辑服务器可能同时收到其他逻辑服务器和IM用户的登录状态通知,相当于一个全局数据接收到了不同数据源的更新请求,由于网络传输和逻辑处理的问题,先产生的状态后到,后产生的状态先到,如果不管理好顺序,则可能发生错误的状态覆盖,那么就必须判断出采用那个数据才是正确的,以免产生错误的状态覆盖。
本申请采用以一个序列号来标记数据的时间的先后顺序,如对于登录操作,可以从上次登录成功的逻辑服务器取回状态序列号,然后加一,得到当前登录的状态序列号,那么在一个账号存在多个登录操作时,则可以根据状态序列号,只保留状态序列号最大的登录操作在线,保证了一号一登录实例的要求,避免了登录状态异常。
图4示出了根据本发明的实施例的客户端登录的流程图。
如图4所示,客户端登录的过程包括:
步骤402,客户端登录时,首先检查是否有上次登录成功的服务器节点;步骤404,如果不存在,则向建议登录的节点发出登录请求;步骤406,如果存在,就向上次登录节点发起登录请求,并取回上次登录的最新的状态序列号;如果在客户端登录时,本地没有保存任何关于服务器节点的信息,则可能是在一个新设备上登录,则向几个域名设备同时发起登录请求,一般情况下这几个域名的服务器不可能同时崩溃,总有一个能够为用户返回服务端的节点信息,和这个用户建议登录的节点和上次登录成功的节点也同时返回这个账号上次登录成功的状态序列号;
如果本地没有上次登录成功的服务器节点则向建议登录节点登录。向服务端发起登录后,可能会收到服务端节点重定向的请求,则应该向重定向的节点登录,因为服务端集群经过裁决,重定向的节点才能接受客户端的登录请求,向最终裁决的节点登录,获取上次登录的最新的状态序列号,此时将这个状态序列号加壹向裁决的节点登录;
步骤408,登录成功后,本地应该保存服务列表信息,本账号被管辖的节点,本次成功登录的节点和最后的状态序列号;
步骤410,当登录过程发生了异常,逻辑服务器端集群在判断序列号出现了冲突就说明可能一个两个客户端同时登录了,就将其中一个客户端下线。如果真的存在这样的一个客户端,那么他它会再重新登录。当后台逻辑服务端器集群在收到状态报告的位置在不同服务器节点时,就将序号号小的节点上的登录的用户下线。因为他的账号在其他服务器上后登录了,他被挤下线了,这样解决了异常和保证一号一登录实例的要求;
步骤412,客户端登录后,先收到登录回应是否成功的消息。当是成功登录后他会收到后续的用户组列表信息;收到用户组列表信息后会收到用户列表信息报文;接着收到用户所属的用户组的关系列表信息。客户端这时能显示出企业组织结构或者个人版的用户列表信息;下面再收到用户状态信息;这个状态信息包括所在节点,序列号,是否有摄像头,邮箱,手机等状态信息;接着收到离线的聊天消息,在这个用户离线时,其他用户给他发送的消息;接着会收到一些离线的控制消息,例如,聊天室邀请,加好友,联系人邀请信息。
图5示出了根据本发明的实施例的逻辑服务器与客户端交互的流程图。如图5所示,本发明的实施例的逻辑服务器与客户端交互的流程包括:
步骤502,检查发出登录请求的账号是否归本逻辑服务器管辖;
步骤504,如果不是,则从数据服务器查询到管辖该账号的服务器节点号;
步骤506,如果此节点崩溃无法登录,则返回帮崩溃节点暂时接管服务的节点;
步骤508,当逻辑服务器接受该客户端登录后,向他返回用户组列表,用户组所属用户列表,这些用户的状态信息,登录用户的离线消息;
步骤510,服务端检测与登录用户的状态相关联的用户,如果相关联的用户在本服务器节点则,向本服务器的用户发送状态信息,如果相关联的用户不在本服务器节点,则向这些用户所在的服务器节点发送状态信息。其他节点收到这状态通知后再具体判断把这些状态发送给谁。
图6示出了根据本发明的实施例的逻辑服务器之间交互的流程图。如图6所示,逻辑服务器之间交互的流程包括:
步骤602,逻辑服务器启动时,向其他的所有逻辑服务器发送登录请求;
步骤604,接受登录的逻辑服务器向登录的逻辑服务器发送该登录服务器节点管辖的用户能看到的所有用户的状态、离线消息以及离线控制报文;
步骤606,登录的逻辑服务器收到后更新本地服务器内存的信息;
步骤608,判断两个逻辑服务器之间的连接是否断开;
步骤610,当连接断开,则可判定其中的一个逻辑服务器已经崩溃,可能不能对外服务,此时对应的逻辑服务器就将一个负载小的逻辑服务器节点作为此逻辑服务器的备份节点。
步骤612,当崩溃的逻辑服务器恢复服务后,他会重新向其他逻辑服务器登录,此时其他的逻辑服务器就归还他原来负责的用户。
以上结合附图详细说明了本发明的技术方案,考虑到相关技术中,即时通讯要求消息发送快速,实时,稳定,而当应对大量的数据传输时,会对服务端设计和架构带来不小的挑战。通过本发明的技术方案,采用特定的设计框架,既可以提高数据传输的速度与可靠性,又可以节省成本,满足即时通讯支持大量用户的需求。
术语“多个”指两个或两个以上,除非另有明确的限定。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (11)
1.一种逻辑服务器,其特征在于,包括:
判断单元,向账号服务器发送获取请求,根据所述账号服务器返回的账号数据,判断发出登录请求的请求账号是否属于所述逻辑服务器的管辖范围,所述账号服务器用于保存每个逻辑服务器的节点号以及每个逻辑服务器管辖的账号数据;
查找单元,在所述判断单元的判断结果为所述请求账号不属于所述管辖范围时,通过所述账号服务器查找出应管辖所述请求账号的逻辑服务器,并将查找出的逻辑服务器的节点号返回至所述请求账号;
信息反馈单元,在所述请求账号登录成功后,通过数据服务器获取与所述请求账号相关联的信息并将获取的信息反馈至所述请求账号,所述数据服务器用于保存与每个账号相关联的信息,其中,所述数据服务器可以采用非关系型的数据库(nosql)思想,将数据存储于共享内存中,进一步地,可以采用哈希(hash)账号存储每个账号的相关数据,这保证了在所述数据服务器中有节点崩溃的情况下或断电时,数据在内存也不会丢失,可以在所述数据服务器的其他未崩溃或未断电的节点上查询到数据。
2.根据权利要求1所述的逻辑服务器,其特征在于,还包括:通信单元,建立所述逻辑服务器与其他逻辑服务器之间的连接,将与所述逻辑服务器管辖的账号相关联的信息发送至所述其他逻辑服务器进行保存;
请求接管单元,在所述逻辑服务器发生崩溃时,请求所述其他逻辑服务器中管辖账号的数目最小的逻辑服务器接管所述逻辑服务器所管辖的账号,以及在所述逻辑服务器正常启动时,请求所述所管辖账号的数目最小的逻辑服务器重新由所述逻辑服务器管辖原有账号。
3.根据权利要求2所述的逻辑服务器,其特征在于,还包括:通知单元,在所述请求账号不属于所述逻辑服务器的管辖范围且所述查找出的逻辑服务器发生崩溃时,将所述管辖账号的数目最小的逻辑服务器的节点号通知所述请求账号。
4.根据权利要求2所述的逻辑服务器,其特征在于,所述通信单元 通过传输控制协议与所述其他逻辑服务器建立数据连接。
5.根据权利要求1至4中任一项所述的逻辑服务器,其特征在于,还包括:状态序列号生成单元,根据所述请求账号上次成功登录所生成的状态序列号生成当前登录操作的状态序列号;
控制登录单元,若所述请求帐号具有多个登录操作,则执行所述状态序列号最大的登录操作,以登录所述逻辑服务器;
存储单元,保存所述请求账号本次登录的状态序列号。
6.一种即时通信系统,其特征在于,包括:多个如权利要求1至5中任一项所述的逻辑服务器、至少一个数据服务器和至少一个账号服务器,其中,所述多个逻辑服务器之间通过传输控制协议建立数据连接;
所述账号服务器连接至每个所述逻辑服务器,用于保存每个所述逻辑服务器所管辖的账号数据;
所述数据服务器连接至每个所述逻辑服务器,用于保存与每个账号相关联的信息。
7.一种即时通信方法,其特征在于,用于如权利要求6所述的即时通讯系统,包括以下步骤:
在登录所述即时通讯系统中的逻辑服务器时,判断发出登录请求的请求账号是否属于所述逻辑服务器的管辖范围;
在所述请求账号不属于所述管辖范围时,通过所述即时通讯系统中的账号服务器查询到管辖所述请求账号的逻辑服务器,并将查找出的逻辑服务器的节点号返回至所述请求账号;
所述请求账号根据所述节点号向所述查找出的逻辑服务器发送登录请求,在登录成功后,所述查找出的逻辑服务器向所述请求账号返回与所述请求账号相关联的信息。
8.根据权利要求7所述的即时通信方法,其特征在于,还包括:所述查找出的逻辑服务器将与本身所管辖的账号相关联的信息发送至所述即时通讯系统中的其他逻辑服务器进行保存;
若所述查找出的逻辑服务器发生崩溃,则由所述其他逻辑服务器中管辖账号的数目最小的逻辑服务器接管所述查找出的逻辑服务器所管辖的账 号;
若所述查找出的逻辑服务器重新正常启动,则重新由所述查找出的逻辑服务器管辖原有账号。
9.根据权利要求8所述的即时通信方法,其特征在于,还包括:在所述请求账号登录所述查找出的逻辑服务器时,若所述查找出的逻辑服务器发生崩溃,则尝试登录所述其他逻辑服务器中的一个逻辑服务器;
若所述其他逻辑服务器中的一个逻辑服务器不是所述管辖账号数目最小的逻辑服务器,则由所述其他逻辑服务器中的一个逻辑服务器通知所述请求账号所述管辖账号数目最小的逻辑服务器的节点号。
10.根据权利要求8所述的即时通信方法,其特征在于,所述查找出的逻辑服务器与所述其他逻辑服务器之间通过传输控制协议建立数据连接。
11.根据权利要求7至10中任一项所述的即时通信方法,其特征在于,还包括:获取所述请求账号上次成功登录所生成的状态序列号;
根据所述状态序列号得到当前登录操作的状态序列号;
若所述请求帐号具有多个登录操作,则执行所述状态序列号最大的登录操作,以登录所述查找出的逻辑服务器;
保存本次成功登录的状态序列号。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210273295.0A CN102769582B (zh) | 2012-08-02 | 2012-08-02 | 逻辑服务器、即时通信系统和即时通信方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210273295.0A CN102769582B (zh) | 2012-08-02 | 2012-08-02 | 逻辑服务器、即时通信系统和即时通信方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102769582A CN102769582A (zh) | 2012-11-07 |
CN102769582B true CN102769582B (zh) | 2015-06-03 |
Family
ID=47096836
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210273295.0A Expired - Fee Related CN102769582B (zh) | 2012-08-02 | 2012-08-02 | 逻辑服务器、即时通信系统和即时通信方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102769582B (zh) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104426885B (zh) * | 2013-09-03 | 2019-04-16 | 深圳市腾讯计算机系统有限公司 | 异常账号提供方法及装置 |
CN105357169B (zh) * | 2014-08-20 | 2018-06-05 | 阿里巴巴集团控股有限公司 | 识别账号的方法及系统 |
CN105306737A (zh) * | 2015-11-30 | 2016-02-03 | 东莞酷派软件技术有限公司 | 一种信息管理方法及用户终端 |
CN107105049B (zh) * | 2017-05-10 | 2018-10-02 | 腾讯科技(深圳)有限公司 | 数据迁移方法和装置 |
CN107204996A (zh) * | 2017-07-31 | 2017-09-26 | 广州云移信息科技有限公司 | 一种智能交接班方法及系统 |
CN109617924B (zh) * | 2019-01-28 | 2022-04-26 | 杭州数梦工场科技有限公司 | 一种账号使用行为检测方法及装置 |
CN113760569B (zh) * | 2021-01-06 | 2024-04-05 | 北京沃东天骏信息技术有限公司 | 一种多账号管理方法和系统 |
CN113364666B (zh) * | 2021-05-25 | 2022-06-28 | 杭州复杂美科技有限公司 | 即时通讯方法、计算机设备和存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1094645A2 (en) * | 1999-10-21 | 2001-04-25 | Sun Microsystems, Inc. | Method and apparatus for providing scalable services using a packet distribution table |
CN101072103A (zh) * | 2007-03-09 | 2007-11-14 | 腾讯科技(深圳)有限公司 | 一种多账号登录即时通讯软件的方法及系统 |
CN101155079A (zh) * | 2006-09-26 | 2008-04-02 | 阿里巴巴公司 | 一种监控即时通讯服务器的方法、装置和系统 |
CN101355476A (zh) * | 2008-05-23 | 2009-01-28 | 林云帆 | 一种基于服务器群集的数据文件存储、分发和应用的系统和方法 |
-
2012
- 2012-08-02 CN CN201210273295.0A patent/CN102769582B/zh not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1094645A2 (en) * | 1999-10-21 | 2001-04-25 | Sun Microsystems, Inc. | Method and apparatus for providing scalable services using a packet distribution table |
CN101155079A (zh) * | 2006-09-26 | 2008-04-02 | 阿里巴巴公司 | 一种监控即时通讯服务器的方法、装置和系统 |
CN101072103A (zh) * | 2007-03-09 | 2007-11-14 | 腾讯科技(深圳)有限公司 | 一种多账号登录即时通讯软件的方法及系统 |
CN101355476A (zh) * | 2008-05-23 | 2009-01-28 | 林云帆 | 一种基于服务器群集的数据文件存储、分发和应用的系统和方法 |
Also Published As
Publication number | Publication date |
---|---|
CN102769582A (zh) | 2012-11-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102769582B (zh) | 逻辑服务器、即时通信系统和即时通信方法 | |
JP4122341B2 (ja) | クライアント端末装置とサーバーとの間のセッション再設定のためのシステム及び方法 | |
US8880725B2 (en) | Continuous replication for session initiation protocol based communication systems | |
CN102958008B (zh) | 一种实现即时通讯的方法、系统和移动终端 | |
CN101917437B (zh) | 基于sip的用户离线检测方法以及sip用户状态检测系统 | |
CN102137033A (zh) | 一种基于通讯录的im系统及即时通信方法 | |
CN101753597B (zh) | 对等节点-客户端架构下对等节点与客户端间保活方法 | |
CN103684988A (zh) | 一种跨移动终端的消息推送方法及装置 | |
CN103475566A (zh) | 一种实时消息交换平台及分布式集群组建方法 | |
JP2000165419A (ja) | ネットワーク代理応答サーバ、ネットワークシステム及びこのネットワークシステムの消費電力低減方法 | |
CN105531979A (zh) | 建立用于数据交换的上下文的http协议上的消息传递api | |
CN105337973A (zh) | 消息交互方法及其系统 | |
CN100563197C (zh) | 一种图片共享系统和方法 | |
CN101448004A (zh) | 基于即时通信的用户状态发布方法、服务器及系统 | |
CN107395686A (zh) | 切换长连接的方法、设备和系统 | |
CN101184273A (zh) | 一种使用移动终端查询企业通信录的系统和方法 | |
CN111277483A (zh) | 一种多端消息的同步方法、服务器及可存储介质 | |
CN102185701A (zh) | 一种实现群组信息交互的方法及系统 | |
CN102546710A (zh) | 基于移动终端登录聊天组的方法、系统及服务器 | |
CN105515936A (zh) | 消息通信的方法、服务器和系统 | |
US7543030B2 (en) | Peer-to-peer communication for instant messaging between different instant message application types | |
KR20060112350A (ko) | 메신저를 이용한 알림 시스템 및 방법 | |
CN112733051A (zh) | 一种基于WebSocket的信息推送管理系统及其方法 | |
CN108337152A (zh) | 多级人脉关系任务求助处理方法及服务器 | |
CN108712297A (zh) | 一种物联网节点设备自主切换网关的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20150603 Termination date: 20210802 |
|
CF01 | Termination of patent right due to non-payment of annual fee |