CN104506424A - 即时通讯中联系人状态的通知方法及通知装置 - Google Patents
即时通讯中联系人状态的通知方法及通知装置 Download PDFInfo
- Publication number
- CN104506424A CN104506424A CN201410852163.2A CN201410852163A CN104506424A CN 104506424 A CN104506424 A CN 104506424A CN 201410852163 A CN201410852163 A CN 201410852163A CN 104506424 A CN104506424 A CN 104506424A
- Authority
- CN
- China
- Prior art keywords
- state
- terminal
- contact person
- contacts
- data block
- 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.)
- Granted
Links
Landscapes
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提供了一种即时通讯中联系人状态的通知方法及通知装置,其中,即时通讯中联系人状态的通知方法,包括:设置用于表示联系人状态的状态表,每个所述状态表用于对所有联系人的多种状态中对应的一种状态进行标识,每个所述状态表包括多个指示位,每个所述指示位用于对相应的一个联系人的当前状态是否是所述每个状态表对应的状态进行标识;将用于对所述所有联系人的至少一种状态进行标识的至少一个所述状态表发送至所述所有联系人中每个联系人对应的终端,以由所述每个联系人对应的终端根据至少一个所述状态表确定所述所有联系人的当前状态。通过本发明的技术方案,可以有效地降低服务器在传输状态报文时的数据流量。
Description
技术领域
本发明涉及即时通讯技术领域,具体而言,涉及一种即时通讯中联系人状态的通知方法和一种即时通讯中联系人状态的通知装置。
背景技术
目前,企业内部通常都需要使用即时通信服务,由于使用个人版的即时通讯工具(如QQ、MSN等)存在公司敏感信息被窃取的风险,并且不能有效管理员工是否使用此类即时通讯工具进行工作。因此,在有些公司内部会使用专有的即时通信软件。
通常情况下,企业的每个员工都要能看到整个企业通讯录中的员工状态,即是否在线、繁忙、离开等即时通信状态。由于整个企业的员工状态对每个员工而言是可见的,而每个员工得状态是时刻变动的,当员工登录时,服务器需要发送的状态报文个数是n×n/2(n是企业员工个数),而在上班时间段则是n×n的报文个数,当企业员工上万时,则需要广播的状态报文个数是上亿个,导致服务器需要发送的数据量较大。
同时,在移动技术高速发展的今天,用户可能在PC端、手机端、平板端等多个终端上进行登录,因此服务器在发送状态报文时也需要实时获取每个联系人在那些终端上登录,并且需要获取每个联系人在每个终端上的状态。所有这些造成了服务器端需要广播的员工状态报文包的个数庞大,导致服务器端传输的数据流量巨大。
因此,如何能够减少服务器发送状态报文的数据量,降低状态报文的传输流量成为亟待解决的技术问题。
发明内容
本发明正是基于上述技术问题至少之一,提出了一种新的即时通讯中联系人状态的通知方案,可以有效地降低服务器在传输状态报文时的数据流量。
有鉴于此,本发明提出了一种即时通讯中联系人状态的通知方法,包括:设置用于表示联系人状态的状态表,每个所述状态表用于对所有联系人的多种状态中对应的一种状态进行标识,每个所述状态表包括多个指示位,每个所述指示位用于对相应的一个联系人的当前状态是否是所述每个状态表对应的状态进行标识;将用于对所述所有联系人的至少一种状态进行标识的至少一个所述状态表发送至所述所有联系人中每个联系人对应的终端,以由所述每个联系人对应的终端根据至少一个所述状态表确定所述所有联系人的当前状态。
在该技术方案中,通过设置状态表,且每个状态表用于对联系人的一种状态进行标识,每个状态表中的每个指示位对相应的一个联系人的当前状态是否是每个状态表对应的状态进行标识,使得在向每个联系人对应的终端发送所有联系人的当前状态时,仅需通过状态报文传输对应于每个联系人的指示位即可,如一个4096字节的状态表可以表示4096×8个联系人的一种状态(如在线、离线、离开、繁忙、就餐中的一种状态),即便需要发送多个状态表(即分别对应于在线、离线、离开、繁忙、就餐中的状态表),传输的数据量也远远小于现有技术中传输每个联系人的ID及其对应的状态的数据量,有效地降低了服务器传输状态报文的数据流量。
其中,每个联系人对应的终端在接收到至少一个状态表时,可以通过至少一个状态表中相应的指示位确定所有联系人的当前状态。优选情况下,服务器需要将用于对所有联系人的多种状态(如所有状态)进行标识的多个状态表发送至所有联系人中每个联系人对应的终端。
在上述技术方案中,优选地,还包括:获取所述每个联系人在多个终端中每个终端上的状态;根据所述多个终端的优先级,选择所述每个联系人在所述多个终端中优先级最高的终端上的状态作为所述每个联系人的当前状态。
在该技术方案中,由于每个联系人可能在多个终端上登录,因此当联系人在多个终端上登录上,可以根据多个终端的优先级,确定每个联系人的当前状态。如联系人可能在PC端、手机端、平板端和固话端登录,则可以设置优先级从高到低依次为PC端、手机端、平板端和固话端,进而可以取优先级较高的终端上的联系人的状态作为联系人的当前状态。
在上述技术方案中,优选地,还包括:设置终端类型表,每个终端类型表包括多个指示位,每个终端类型表中的每个指示位用于对所述所有联系人中相应的一个联系人在所述多个终端中的一个终端上的当前状态;将用于对所述所有联系人在所述多个终端上的当前状态进行标识的多个所述终端类型表发送至所述每个联系人对应的至少一个终端,以由所述每个联系人对应的至少一个终端根据多个所述终端类型表确定所述所有联系人在所述多个终端中每个终端上的状态。
在该技术方案中,类似于状态表的设计方案,服务器可以设置终端类型表,以将每个联系人在多个终端上的状态发送至每个联系人对应的至少一个终端,进而能够确保每个联系人能够查看到其他联系人在多个终端上的状态,同时也能够有效降低服务器的传输数据量。其中,每个联系人对应的至少一个终端可以是每个联系人对应的所有终端或任意数量的终端。
在上述技术方案中,优选地,将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端的步骤具体包括:将每个所述状态表或每个所述终端类型表划分为多个数据块,根据所述多个数据块中每个数据块包含的指示位的值,确定所述每个数据块的值;将所述每个数据块的值发送至所述每个联系人对应的终端,或仅将所述多个数据块中指定数据块的值发送至所述每个联系人对应的终端,其中,所述指定数据块中包含的所有指示位的值不同。
在该技术方案中,通过将状态表或终端类型表划分为多个数据块,以根据每个数据块包含的指示位的值确定每个数据块的值,进而将每个数据块的值发送至每个联系人对应的终端,或仅将上述指定数据块的值发送至每个联系人对应的终端,使得能够在确保将所有联系人的状态或所有联系人在每个终端上的状态发送至其他联系人对应的终端的前提下,有效降低服务器的传输数据量。
在上述技术方案中,优选地,还包括:通过具有预定格式的数据报文将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端;其中,所述预定格式包括:表示所述状态表或所述终端类型表的报头部分、表示所述每个数据块的值的数据部分和表示所述每个数据块的属性的描述部分。
在上述技术方案中,优选地,还包括:检测所述所有联系人的当前状态是否发生变化;每经过预定时间后,将所述当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至所述每个联系人对应的终端。
在该技术方案中,通过在每经过预定时间后,将当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至每个联系人对应的终端,可以避免在有联系人的状态发生变化时就发送状态报文而导致服务器需要广播的报文数量较多的问题,同样可以降低服务器传输状态报文的数据流量。
在上述技术方案中,优选地,每个所述状态表中的每个指示位对应于一个所述联系人的标识信息,以及每个所述终端类型表中的每个指示位对应于一个所述联系人的标识信息。
在上述技术方案中,优选地,根据所述所有联系人的数量和/或处理***单次能够读取或处理的数据量,设置每个所述状态表和/或每个所述终端类型表的大小。
在该技术方案中,通过根据处理***单次能够读取或处理的数据量,设置每个状态表和/或每个终端类型表大小,能够最大程度地提高处理***的处理速度。
根据本发明的另一方面,还提出了一种即时通讯中联系人状态的通知装置,包括:设置单元,用于设置用于表示联系人状态的状态表,每个所述状态表用于对所有联系人的多种状态中对应的一种状态进行标识,每个所述状态表包括多个指示位,每个所述指示位用于对相应的一个联系人的当前状态是否是所述每个状态表对应的状态进行标识;发送单元,用于将用于对所述所有联系人的至少一种状态进行标识的至少一个所述状态表发送至所述所有联系人中每个联系人对应的终端,以由所述每个联系人对应的终端根据至少一个所述状态表确定所述所有联系人的当前状态。
在该技术方案中,通过设置状态表,且每个状态表用于对联系人的一种状态进行标识,每个状态表中的每个指示位对相应的一个联系人的当前状态是否是每个状态表对应的状态进行标识,使得在向每个联系人对应的终端发送所有联系人的当前状态时,仅需通过状态报文传输对应于每个联系人的指示位即可,如一个4096字节的状态表可以表示4096×8个联系人的一种状态(如在线、离线、离开、繁忙、就餐中的一种状态),即便需要发送多个状态表(即分别对应于在线、离线、离开、繁忙、就餐中的状态表),传输的数据量也远远小于现有技术中传输每个联系人的ID及其对应的状态的数据量,有效地降低了服务器传输状态报文的数据流量。
其中,每个联系人对应的终端在接收到至少一个状态表时,可以通过至少一个状态表中相应的指示位确定所有联系人的当前状态。优选情况下,服务器需要将用于对所有联系人的多种状态(如所有状态)进行标识的多个状态表发送至所有联系人中每个联系人对应的终端。
在上述技术方案中,优选地,还包括:获取单元,用于获取所述每个联系人在多个终端中每个终端上的状态;选择单元,用于根据所述多个终端的优先级,选择所述每个联系人在所述多个终端中优先级最高的终端上的状态作为所述每个联系人的当前状态。
在该技术方案中,由于每个联系人可能在多个终端上登录,因此当联系人在多个终端上登录上,可以根据多个终端的优先级,确定每个联系人的当前状态。如联系人可能在PC端、手机端、平板端和固话端登录,则可以设置优先级从高到低依次为PC端、手机端、平板端和固话端,进而可以取优先级较高的终端上的联系人的状态作为联系人的当前状态。
在上述技术方案中,优选地,所述设置单元还用于,设置终端类型表,每个终端类型表包括多个指示位,每个终端类型表中的每个指示位用于对所述所有联系人中相应的一个联系人在所述多个终端中的一个终端上的当前状态;所述发送单元还用于,将用于对所述所有联系人在所述多个终端上的当前状态进行标识的多个所述终端类型表发送至所述每个联系人对应的至少一个终端,以由所述每个联系人对应的至少一个终端根据多个所述终端类型表确定所述所有联系人在所述多个终端中每个终端上的状态。
在该技术方案中,类似于状态表的设计方案,服务器可以设置终端类型表,以将每个联系人在多个终端上的状态发送至每个联系人对应的至少一个终端,进而能够确保每个联系人能够查看到其他联系人在多个终端上的状态,同时也能够有效降低服务器的传输数据量。其中,每个联系人对应的至少一个终端可以是每个联系人对应的所有终端或任意数量的终端。
在上述技术方案中,优选地,所述发送单元包括:划分单元,用于将每个所述状态表或每个所述终端类型表划分为多个数据块;确定单元,用于根据所述多个数据块中每个数据块包含的指示位的值,确定所述每个数据块的值;执行单元,用于将所述每个数据块的值发送至所述每个联系人对应的终端,或仅将所述多个数据块中指定数据块的值发送至所述每个联系人对应的终端,其中,所述指定数据块中包含的所有指示位的值不同。
在该技术方案中,通过将状态表或终端类型表划分为多个数据块,以根据每个数据块包含的指示位的值确定每个数据块的值,进而将每个数据块的值发送至每个联系人对应的终端,或仅将上述指定数据块的值发送至每个联系人对应的终端,使得能够在确保将所有联系人的状态或所有联系人在每个终端上的状态发送至其他联系人对应的终端的前提下,有效降低服务器的传输数据量。
在上述技术方案中,优选地,所述执行单元具体用于:通过具有预定格式的数据报文将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端;其中,所述预定格式包括:表示所述状态表或所述终端类型表的报头部分、表示所述每个数据块的值的数据部分和表示所述每个数据块的属性的描述部分。
在上述技术方案中,优选地,还包括:检测单元,用于检测所述所有联系人的当前状态是否发生变化;所述发送单元还用于,每经过预定时间后,将所述当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至所述每个联系人对应的终端。
在该技术方案中,通过在每经过预定时间后,将当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至每个联系人对应的终端,可以避免在有联系人的状态发生变化时就发送状态报文而导致服务器需要广播的报文数量较多的问题,同样可以降低服务器传输状态报文的数据流量。
在上述技术方案中,优选地,每个所述状态表中的每个指示位对应于一个所述联系人的标识信息,以及每个所述终端类型表中的每个指示位对应于一个所述联系人的标识信息。
在上述技术方案中,优选地,所述设置单元还用于,根据所述所有联系人的数量和/或处理***单次能够读取或处理的数据量,设置每个所述状态表和/或每个所述终端类型表的大小。
在该技术方案中,通过根据处理***单次能够读取或处理的数据量,设置每个状态表和/或每个终端类型表大小,能够最大程度地提高处理***的处理速度。
通过以上技术方案,有效地降低了服务器传输状态报文的数据流量。
附图说明
图1示出了根据本发明的实施例的即时通讯中联系人状态的通知方法的示意流程图;
图2示出了根据本发明的实施例的即时通讯中联系人状态的通知装置的示意框图;
图3示出了根据本发明的一个实施例的IM服务器状态广播***的示意框图;
图4示出了根据本发明的实施例的服务器发送至客户端的数据格式示意图;
图5示出了根据本发明的另一个实施例的IM服务器状态广播***的示意框图;
图6示出了根据本发明的实施例的对每个用户的状态报文进行编码后的结构示意图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是,在不冲突的情况下,本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是,本发明还可以采用其他不同于在此描述的其他方式来实施,因此,本发明的保护范围并不受下面公开的具体实施例的限制。
图1示出了根据本发明的实施例的即时通讯中联系人状态的通知方法的示意流程图。
如图1所示,根据本发明的实施例的即时通讯中联系人状态的通知方法,包括:步骤102,设置用于表示联系人状态的状态表,每个所述状态表用于对所有联系人的多种状态中对应的一种状态进行标识,每个所述状态表包括多个指示位,每个所述指示位用于对相应的一个联系人的当前状态是否是所述每个状态表对应的状态进行标识;步骤104,将用于对所述所有联系人的至少一种状态进行标识的至少一个所述状态表发送至所述所有联系人中每个联系人对应的终端,以由所述每个联系人对应的终端根据至少一个所述状态表确定所述所有联系人的当前状态。
在该技术方案中,通过设置状态表,且每个状态表用于对联系人的一种状态进行标识,每个状态表中的每个指示位对相应的一个联系人的当前状态是否是每个状态表对应的状态进行标识,使得在向每个联系人对应的终端发送所有联系人的当前状态时,仅需通过状态报文传输对应于每个联系人的指示位即可,如一个4096字节的状态表可以表示4096×8个联系人的一种状态(如在线、离线、离开、繁忙、就餐中的一种状态),即便需要发送多个状态表(即分别对应于在线、离线、离开、繁忙、就餐中的状态表),传输的数据量也远远小于现有技术中传输每个联系人的ID及其对应的状态的数据量,有效地降低了服务器传输状态报文的数据流量。
其中,每个联系人对应的终端在接收到至少一个状态表时,可以通过至少一个状态表中相应的指示位确定所有联系人的当前状态。优选情况下,服务器需要将用于对所有联系人的多种状态(如所有状态)进行标识的多个状态表发送至所有联系人中每个联系人对应的终端。
在上述技术方案中,优选地,还包括:获取所述每个联系人在多个终端中每个终端上的状态;根据所述多个终端的优先级,选择所述每个联系人在所述多个终端中优先级最高的终端上的状态作为所述每个联系人的当前状态。
在该技术方案中,由于每个联系人可能在多个终端上登录,因此当联系人在多个终端上登录上,可以根据多个终端的优先级,确定每个联系人的当前状态。如联系人可能在PC端、手机端、平板端和固话端登录,则可以设置优先级从高到低依次为PC端、手机端、平板端和固话端,进而可以取优先级较高的终端上的联系人的状态作为联系人的当前状态。
在上述技术方案中,优选地,还包括:设置终端类型表,每个终端类型表包括多个指示位,每个终端类型表中的每个指示位用于对所述所有联系人中相应的一个联系人在所述多个终端中的一个终端上的当前状态;将用于对所述所有联系人在所述多个终端上的当前状态进行标识的多个所述终端类型表发送至所述每个联系人对应的至少一个终端,以由所述每个联系人对应的至少一个终端根据多个所述终端类型表确定所述所有联系人在所述多个终端中每个终端上的状态。
在该技术方案中,类似于状态表的设计方案,服务器可以设置终端类型表,以将每个联系人在多个终端上的状态发送至每个联系人对应的至少一个终端,进而能够确保每个联系人能够查看到其他联系人在多个终端上的状态,同时也能够有效降低服务器的传输数据量。其中,每个联系人对应的至少一个终端可以是每个联系人对应的所有终端或任意数量的终端。
在上述技术方案中,优选地,将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端的步骤具体包括:将每个所述状态表或每个所述终端类型表划分为多个数据块,根据所述多个数据块中每个数据块包含的指示位的值,确定所述每个数据块的值;将所述每个数据块的值发送至所述每个联系人对应的终端,或仅将所述多个数据块中指定数据块的值发送至所述每个联系人对应的终端,其中,所述指定数据块中包含的所有指示位的值不同。
在该技术方案中,通过将状态表或终端类型表划分为多个数据块,以根据每个数据块包含的指示位的值确定每个数据块的值,进而将每个数据块的值发送至每个联系人对应的终端,或仅将上述指定数据块的值发送至每个联系人对应的终端,使得能够在确保将所有联系人的状态或所有联系人在每个终端上的状态发送至其他联系人对应的终端的前提下,有效降低服务器的传输数据量。
在上述技术方案中,优选地,还包括:通过具有预定格式的数据报文将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端;其中,所述预定格式包括:表示所述状态表或所述终端类型表的报头部分、表示所述每个数据块的值的数据部分和表示所述每个数据块的属性的描述部分。
在上述技术方案中,优选地,还包括:检测所述所有联系人的当前状态是否发生变化;每经过预定时间后,将所述当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至所述每个联系人对应的终端。
在该技术方案中,通过在每经过预定时间后,将当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至每个联系人对应的终端,可以避免在有联系人的状态发生变化时就发送状态报文而导致服务器需要广播的报文数量较多的问题,同样可以降低服务器传输状态报文的数据流量。
在上述技术方案中,优选地,每个所述状态表中的每个指示位对应于一个所述联系人的标识信息,以及每个所述终端类型表中的每个指示位对应于一个所述联系人的标识信息。
在上述技术方案中,优选地,根据所述所有联系人的数量和/或处理***单次能够读取或处理的数据量,设置每个所述状态表和/或每个所述终端类型表的大小。
在该技术方案中,通过根据处理***单次能够读取或处理的数据量,设置每个状态表和/或每个终端类型表大小,能够最大程度地提高处理***的处理速度。
图2示出了根据本发明的实施例的即时通讯中联系人状态的通知装置的示意框图。
如图2所示,根据本发明的实施例的即时通讯中联系人状态的通知装置200,包括:设置单元202,用于设置用于表示联系人状态的状态表,每个所述状态表用于对所有联系人的多种状态中对应的一种状态进行标识,每个所述状态表包括多个指示位,每个所述指示位用于对相应的一个联系人的当前状态是否是所述每个状态表对应的状态进行标识;发送单元204,用于将用于对所述所有联系人的至少一种状态进行标识的至少一个所述状态表发送至所述所有联系人中每个联系人对应的终端,以由所述每个联系人对应的终端根据至少一个所述状态表确定所述所有联系人的当前状态。
在该技术方案中,通过设置状态表,且每个状态表用于对联系人的一种状态进行标识,每个状态表中的每个指示位对相应的一个联系人的当前状态是否是每个状态表对应的状态进行标识,使得在向每个联系人对应的终端发送所有联系人的当前状态时,仅需通过状态报文传输对应于每个联系人的指示位即可,如一个4096字节的状态表可以表示4096×8个联系人的一种状态(如在线、离线、离开、繁忙、就餐中的一种状态),即便需要发送多个状态表(即分别对应于在线、离线、离开、繁忙、就餐中的状态表),传输的数据量也远远小于现有技术中传输每个联系人的ID及其对应的状态的数据量,有效地降低了服务器传输状态报文的数据流量。
其中,每个联系人对应的终端在接收到至少一个状态表时,可以通过至少一个状态表中相应的指示位确定所有联系人的当前状态。优选情况下,服务器需要将用于对所有联系人的多种状态(如所有状态)进行标识的多个状态表发送至所有联系人中每个联系人对应的终端。
在上述技术方案中,优选地,还包括:获取单元206,用于获取所述每个联系人在多个终端中每个终端上的状态;选择单元208,用于根据所述多个终端的优先级,选择所述每个联系人在所述多个终端中优先级最高的终端上的状态作为所述每个联系人的当前状态。
在该技术方案中,由于每个联系人可能在多个终端上登录,因此当联系人在多个终端上登录上,可以根据多个终端的优先级,确定每个联系人的当前状态。如联系人可能在PC端、手机端、平板端和固话端登录,则可以设置优先级从高到低依次为PC端、手机端、平板端和固话端,进而可以取优先级较高的终端上的联系人的状态作为联系人的当前状态。
在上述技术方案中,优选地,所述设置单元202还用于,设置终端类型表,每个终端类型表包括多个指示位,每个终端类型表中的每个指示位用于对所述所有联系人中相应的一个联系人在所述多个终端中的一个终端上的当前状态;所述发送单元204还用于,将用于对所述所有联系人在所述多个终端上的当前状态进行标识的多个所述终端类型表发送至所述每个联系人对应的至少一个终端,以由所述每个联系人对应的至少一个终端根据多个所述终端类型表确定所述所有联系人在所述多个终端中每个终端上的状态。
在该技术方案中,类似于状态表的设计方案,服务器可以设置终端类型表,以将每个联系人在多个终端上的状态发送至每个联系人对应的至少一个终端,进而能够确保每个联系人能够查看到其他联系人在多个终端上的状态,同时也能够有效降低服务器的传输数据量。其中,每个联系人对应的至少一个终端可以是每个联系人对应的所有终端或任意数量的终端。
在上述技术方案中,优选地,所述发送单元204包括:划分单元2042,用于将每个所述状态表或每个所述终端类型表划分为多个数据块;确定单元2044,用于根据所述多个数据块中每个数据块包含的指示位的值,确定所述每个数据块的值;执行单元2046,用于将所述每个数据块的值发送至所述每个联系人对应的终端,或仅将所述多个数据块中指定数据块的值发送至所述每个联系人对应的终端,其中,所述指定数据块中包含的所有指示位的值不同。
在该技术方案中,通过将状态表或终端类型表划分为多个数据块,以根据每个数据块包含的指示位的值确定每个数据块的值,进而将每个数据块的值发送至每个联系人对应的终端,或仅将上述指定数据块的值发送至每个联系人对应的终端,使得能够在确保将所有联系人的状态或所有联系人在每个终端上的状态发送至其他联系人对应的终端的前提下,有效降低服务器的传输数据量。
在上述技术方案中,优选地,所述执行单元2046具体用于:通过具有预定格式的数据报文将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端;其中,所述预定格式包括:表示所述状态表或所述终端类型表的报头部分、表示所述每个数据块的值的数据部分和表示所述每个数据块的属性的描述部分。
在上述技术方案中,优选地,还包括:检测单元210,用于检测所述所有联系人的当前状态是否发生变化;所述发送单元204还用于,每经过预定时间后,将所述当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至所述每个联系人对应的终端。
在该技术方案中,通过在每经过预定时间后,将当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至每个联系人对应的终端,可以避免在有联系人的状态发生变化时就发送状态报文而导致服务器需要广播的报文数量较多的问题,同样可以降低服务器传输状态报文的数据流量。
在上述技术方案中,优选地,每个所述状态表中的每个指示位对应于一个所述联系人的标识信息,以及每个所述终端类型表中的每个指示位对应于一个所述联系人的标识信息。
在上述技术方案中,优选地,所述设置单元202还用于,根据所述所有联系人的数量和/或处理***单次能够读取或处理的数据量,设置每个所述状态表和/或每个所述终端类型表的大小。
在该技术方案中,通过根据处理***单次能够读取或处理的数据量,设置每个状态表和/或每个终端类型表大小,能够最大程度地提高处理***的处理速度。
以下结合图3至图6详细说明本发明的技术方案。
如图3所示,根据本发明的一个实施例的IM服务器状态广播***300,包括:细节状态存储单元302、状态仲裁单元304、企业状态bit表单元306、终端类型bit表单元308、员工ID回收单元310、bit表裁剪单元312、bit表报文单元314、bit表报文编码单元316。
其中,细节状态存储单元302用于存储即时通信的细节状态,包括一般企业网常用的几种状态,如在线、离开、繁忙、离线、就餐等。细节状态存储单元302存储每个用户对应的多个终端的具体细节状态,也就是存贮每个用户有那几种终端和对应的终端是什么状态,终端包括PC,手机,平板,固话等。
当一个用户对应的多个终端都在线时,每个终端有一个状态,在企业通讯录中只能显示一个状态,也就是用户的主状态。状态仲裁单元304负责对多个终端的状态进行裁剪,选取一个状态作为用户的主状态,也就是对外呈现的状态。状态仲裁单元304根据终端的特性和使用频度等认定为:PC优先级大于手机,手机优先级大于平板,平板优先级大于固话,当任何一种优先级高的终端在线时,则取优先级高的终端的状态作为主状态。例如:PC不在线时,若手机在线,则取手机状态为主状态,若手机也不在线,则判断平板是否在线。
企业状态bit表单元306,用于存储企业所有用户每个状态的bit表,每个bit代表所有用户是否是为对应的状态,为1代表是此种状态,0代表非此种状态。例如,可以1代表在线,0代表不在线;也可以反过来。bit表的每个bit的位置代表每个用户的ID对应企业员工ID的偏移,例如,第一个bit位代表员工ID为1的员工的状态,这样做可省略给客户端传输报文状态时需要给客户端传输企业员工ID,而一个ID一般要使用4个字节,在员工数量较多时会形成较显著的数据量。同时服务器端在给客户端发送bit表时,无需担心被更改而进行数据拷贝,也无需要对bit表加密,因为任何更改只会更改每个bit位,也就是bit位的翻转,不会导致整体数据的过多失真。其中,一个4096字节的bit表(4096字节的数组)可表示3万多人(即4096×8)的状态,也就是8K字节(8192字节)可表示一个6万多人的企业的状态,则基本能覆盖大部分企业。此外,企业状态bit表单元306及终端类型bit表单元308的数据结构大小,可以根据处理器一次读取或处理的数据块大小来确定,这样可以提高处理速度。例如,现行处理器一次从内存中读取4KB数据,则可以将这些数据结构的大小设置为4KB的整数倍,可以最大程度地提高处理速度。此外,服务器需要将每个状态对应的bit表发送至终端,由终端综合确定每个用户的当前状态。
终端类型bit表单元308:目前移动互联情况下,一般用户按照硬件划分有PC,手机,平板,固话几种终端,则每个企业还需要保存每个用户对应的有那几个终端在线,因此终端类型bit表单元308用于存储终端类型,同状态bit表单元一样,终端类型bit表对应的bit位为1则表示对应终端在线,为0则表示对应的终端不在线,则一个企业需要保存4个终端类型bit表(具体可根据终端类型进行确定终端类型bit表的数量),同样一个4k字节的bit表则可表示3万多人的一个终端是否在线。
员工ID回收单元310:状态bit表和终端类型bit的初衷是企业员工ID是连续紧凑的,不存在空洞,但是可能一个企业在长期运行过程中,一些员工离职,一些临时员工等,为了保证企业员工ID的连续和紧凑,离职员工或者临时员工的ID应该被回收,用于新员工的ID的分配,保证企业员工ID是连续紧凑的。在此说明本发明实施例中的员工ID与企业员工编码(或工号)之间的区别:这两者可以相同,也可以不同,在员工ID与企业员工编码不同的情况下,两者之间存在一定对应关系,可以通过对照表或者其他管理工具来体现和维护两者之间的对应关系。此外,各企业的员工编码可以采取不同设置方法,有些企业员工离职后,其编码会进行回收,以使得最终的员工编码是连续的;有些企业则不回收离职员工的编码,这样员工编码会存在大量冗余。但上述情况都可以应用本发明的技术方案,因为员工ID回收后,不管其员工编码是否回收,只要相应地修改员工ID与员工编码之间的对应关系即可。
bit表裁剪单元312:一个bit表可能在低位0和最高位4095字节处为1,这样可能就2个bit位为1,但是需要传输给客户端4K字节给客户端。bit表裁剪单元312按照一个机器字长,32位字节判断,bit表裁剪单元对bit数组按照一个32位的整数逐个判断是否为0,为0则表示这个数据块(连续的32个bit)都为0,这个数据是不需要传输给客户端的,bit表是个稀疏数组时,对bit表进行网格划分,只传输不为1的数据块可有效减少传输的流量,bit表裁剪单元312在数据的流量和报文的复杂性、性能、数据是否要拷贝、是否要加密之间获取一个平衡点。
服务器端发送给客户端(即终端)的数据格式为bit表报文单元314。如图4所示,bit表报文单元314包含三部分:第一部分是报头部分,描述这个报文状态类型(终端类型)及是否含有网格描述块;第二部分是bit表网格数据区,数据区是真实发送的bit流;第三部分是bit表网格描述数据块,其标记数据区那些块是为有效的块,可以由bit表裁剪单312生成。
bit表报文单元编码单元316,负责对bit表报文单元314进行编码。
此外,客户端上设置有bit表报文单元解码单元,用于对服务器端下发的bit表进行解码。
上述方案中所述的IM服务器状态广播***主要用于在用户登录时,减少传输流量和服务器端编码的性能开销。
下面描述的是当用户登录到服务器端后,IM服务器端对在线用户实时广播变动的员工的状态,如果按照每个员工状态变化就广播的驱动模式,则将导致广播的报文数量太大,因为每个报文都有包头,则实际有效载荷是占比比较小的。本发明优化为按时间驱动的方式,取定为每2秒(可以根据实际需要进行设定)服务器端进行广播次,假设每2秒对当前的状态变动的员工进行打包发送,如果在瞬间并发很高时能将多个变化的终端的状态进行合并发送。在一定意义上,需要广播的报文数量为人数的线性关系。下面结合图5描述根据本发明的另一个实施例的IM服务器状态广播***500所包含的单元。
当前员工状态变动存储单元502,负责存储本企业当前所有状态变动的用户的链表。
广播状态报文编码单元504,负责对每个用户进行编码,对每个用户进行编码需要32个bit,如图6所示,24个bit表示这个员工的ID,每3bit表示这个员工的一种终端的状态,12bit刚好表示4种状态的状态。一个32bit的整数表示的数据是独立的,相互之间没有耦合性,可方便状态的合并。
广播状态传输层单元506,负责对广播状态报文进行传输和合并的工作。广播状态的逻辑是和IM的逻辑独立的,没有相关性,并且广播状态的报文数量比较大,可能冲击正常的IM报文的信令,广播状态传输层降低广播状态报文的优先级,只要有非广播状态的报文则优先发送。此外,待传输的队列报文数量大时,可把待传输的队列的所有报文合并成一个报文进行传输。
以下结合图3至图6再次详细说明本发明的技术方案:
当企业员工的状态变化,且对应于用户的某个终端的状态发生变化后,这些信息存储到细节状态存储单元302中。然而,一个员工有多个终端,则同时有多个状态,需要对外只呈现一个状态作为这个企业员工的主状态。所以,细节状态存储单元302单元向状态仲裁单元304发送请求,以请求状态仲裁单元304裁剪过滤出这个员工的主状态。主状态是这个企业员工的即时通信的唯一的状态。
状态仲裁单元304接收到细节状态存储单元302单元的请求后,根据多个终端的终端类型的优先级顺序进行计算,这里多终端类型有PC、手机、平板、智能固话,这几种终端根据硬件特点设置的优先级顺序为依次递减。当优先级高的终端在线时,取这个终端的状态为主状态,否则按照优先级顺序取下一个终端的状态作为主状态,如果这几个终端都不在线,则这个员工的主状态明显为离线。
企业状态bit表单元306,在确定某员工的主状态之后,则首先根据员工ID计算出这个员工在bit表中的位置偏移,计算出位置偏移后,对bit表中对应位置的bit位的值进行设置,如果为此状态,则对应bit位的值就设为1,否则设置为0。同时对这个bit表的最大最小为1位置的索引进行判断更新,始终保存最大位置为和最小位置为1的索引。如果设置为逻辑意义上为在线的状态(例如离开、繁忙、就餐等)时,则需要同步设置在线bit表中对应的bit位。同时,如果设置为离线,则需要在其他所有的bit表中的对应位同步设置。因为每种状态对应一个bit表,任何设置主状态的操作都需要将这几种表从逻辑意义上的设置为重置,同时同步更新其最大和最小位置的索引。
此外,企业状态bit表在默认情况下是一个4K页面的存储空间,也就是能支持3万人,如果在运行期企业员工个数增长,则需要对这个4K页面进行扩展,这个扩展可以是按4K单位增长进行的。
同企业状态bit表一样,企业终端类型bit表也是同样的处理方式,只不过对应bit位是否为1代表这个员工当前是否有对应的终端在线。因为一个员工的PC、手机、平板、固话类的终端按照在线使用几率上来看也是逐步递减的,因此对上述各类终端分别进行编码,将能大大减小传输的数据量。当一个员工初次登录时,IM服务器端将给客户端下发这个员工的企业状态bit表和终端bit表,在客户端将知道整个企业的员工各自的主状态和对应的各终端是否在线,但是不能获知各种终端的细节状态。当然这个主状态是这个员工的第一个终端的状态,优先级低的终端的状态被简称为是否在线。从这个目的意义上是为了当一个企业员工上万时,大大减小给客户端的传输的数据流量。
但是,一个bit表可能为一个稀疏数组,在一定程度上也可看作是一个只有一行的稀疏矩阵,当一个企业有多个4K页的状态表时,则可能是一个多行的稀疏矩阵(当然这种情况比较少,因为上3万人的企业比较少)。如果按照稀疏矩阵的压缩算法来进行压缩,可能并不是性能最好的,结合bit表和计算机的特点,对bit表的内存地址转成一个整数的指针进行按照一个32位的整数来判断,判断一个整数是否为0就能判断32个人是否同时为0。当然对于64位***,一个整数判断一次就能判断64个人是否同时为0,为了兼容32位和64位***,采用32作为bit表裁剪单元的一个网格的大小,也就是一个4k页按照32的网格大小划分为128个网格(grid)。在bit表裁剪单元312中保存一个128bit大小的一个数组,描述对应网格值是否为0,如果为0,则网格描述bit位设置为0,否则设置为1。
当用户登录时,根据bit表的稀疏情况进行编码进行数据压缩,特别是能减小移动互联网敏感的传输流量,这个维护网格是否稀疏的工作也就是bit表裁剪单元312负责的工作。
经过bit表裁剪单元312的维护工作后,当用户登录时,要传输例如一个企业几万人的状态数据给客户端时,一个报文的大小一般在几百字节,最长的情况下就是4K大小。如果反转稀疏的判断标准,来编码则是最长的情况下的一半,即2K大小。图4描述了一个bit表报文的结构,分为三部分:报头、bit表网格数据区、bit表网格描述数据,其中,Bit表网格描述数据是描述bit表数据区的稀疏情况的。
如果bit表数据区的数据量很大时,如达到了4K,则在综合权衡情况下,这个bit表网格描述是可以在这个报文里完全进行省略。
在这个bit表报文构造出来后,在给客户端发送时,服务器端是可以直接引用bit表数据和bit表网格描述数据的,这个内存块是不用加密和内存拷贝的,因为这个数据是二值化的,任何更改更能将最新的数据的值发送到客户端,错误的值只能为最新更改的值。
当客户端接收到bit表报文单元后,首先根据网格描述表取出bit表数据区,因为bit表数据区表示的每个数据块只可能为一个32bit连续的数据块,整体上数据可能不连续。在解码取出数据后,对每个字节可根据预先计算的一个字节的查找表,可查找出一个字节有几个bit为1,以及当为一个字节为0到255的值时,对应的那几个bit为1。同时根据bit位的偏移位置计算出对应为那个员工的员工ID。在多终端情况下,首次登录的客户端只能获得整个企业的员工的主状态,但是大多数情况下,一个企业的员工只登录了一个终端的概率是最高的,所以这个是不存在问题。同时,在一个企业的员工登录了多个终端的情况下,这个主状态代表了这个员工的第一优先顺序的终端的状态,后面的优先顺序的终端被近似的设置为在线状态。这个近似的设置在一定程度上是可接受的。客户端根据这个进行解码后设置进行UI的显示,客户端能查询到每个员工有那几种终端在线和对应的终端是什么状态。例如:服务器端报告的某员工终端类型有PC、手机、平板同时状态为繁忙,那么这个用户的PC状态肯定为繁忙;若服务器端报告的某终端类型有手机、平板,没有PC,那么手机的状态肯定为繁忙,平板在线,因为手机的优先级大于平板。当这个终端登录后,这个企业的某员工的状态变化,和那个终端进行了变化,则实时通知到对应客户端。
在一个员工的状态变化或这个员工的某终端上下线,则需要将这个状态数据广播给这个企业所有在线的员工。但是这个数据不能立即全企业广播,这个变化数据存入当前的状态变化链表中。IM服务器每隔2秒检查次状态变化链表,如果没有状态变化的数据则不做任何操作;如果有状态变化的数据,则需要现在向全企业广播,这个变化的链表可能目前有多个人的状态数据或者只有一个人的状态数据。但是在按时间的分隔情况下,能确保发包个数基本为人数的线性关系。广播状态报文编码单元504对当前的变化的链表进行编码报文,其中,广播状态报文每个报文都有一个序号,编码报文成功后,投递到广播报文传输层单元506进行广播发送。
广播状态传输层单元506收到请求后,对一个企业的SOCKET组进行广播操作,对每个SOCKET通道记录当前需要待发送的最大的广播状态报文的序号,每个SOCKET通道同时记录了当前待发送的广播状态报文的序号也就是最小的序号,由于各个SOCKET传输的速度差异性,各自发送的进度可能不一样,当SOCKET通道传输一个广播状态报文完成后,如果有非状态报文的报文发送,则先发送非状态报文。否则发送状态报文,发送状态报文时,检查当前的待发送的广播状态报文序号,是否有多个待发送的,如果有则整个进行合并成一个报文发送。
以上结合附图详细说明了本发明的技术方案,本发明提出了一种新的即时通讯中联系人状态的通知方案,可以有效地降低服务器在传输状态报文时的数据流量。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (14)
1.一种即时通讯中联系人状态的通知方法,其特征在于,包括:
设置用于表示联系人状态的状态表,每个所述状态表用于对所有联系人的多种状态中对应的一种状态进行标识,每个所述状态表包括多个指示位,每个所述指示位用于对相应的一个联系人的当前状态是否是所述每个状态表对应的状态进行标识;
将用于对所述所有联系人的至少一种状态进行标识的至少一个所述状态表发送至所述所有联系人中每个联系人对应的终端,以由所述每个联系人对应的终端根据至少一个所述状态表确定所述所有联系人的当前状态。
2.根据权利要求1所述的即时通讯中联系人状态的通知方法,其特征在于,还包括:
获取所述每个联系人在多个终端中每个终端上的状态;
根据所述多个终端的优先级,选择所述每个联系人在所述多个终端中优先级最高的终端上的状态作为所述每个联系人的当前状态。
3.根据权利要求2所述的即时通讯中联系人状态的通知方法,其特征在于,还包括:
设置终端类型表,每个终端类型表包括多个指示位,每个终端类型表中的每个指示位用于对所述所有联系人中相应的一个联系人在所述多个终端中的一个终端上的当前状态;
将用于对所述所有联系人在所述多个终端上的当前状态进行标识的多个所述终端类型表发送至所述每个联系人对应的至少一个终端,以由所述每个联系人对应的至少一个终端根据多个所述终端类型表确定所述所有联系人在所述多个终端中每个终端上的状态。
4.根据权利要求1至3中任一项所述的即时通讯中联系人状态的通知方法,其特征在于,将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端的步骤具体包括:
将每个所述状态表或每个所述终端类型表划分为多个数据块,根据所述多个数据块中每个数据块包含的指示位的值,确定所述每个数据块的值;
将所述每个数据块的值发送至所述每个联系人对应的终端,或仅将所述多个数据块中指定数据块的值发送至所述每个联系人对应的终端,其中,所述指定数据块中包含的所有指示位的值不同。
5.根据权利要求4所述的即时通讯中联系人状态的通知方法,其特征在于,还包括:
通过具有预定格式的数据报文将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端;
其中,所述预定格式包括:表示所述状态表或所述终端类型表的报头部分、表示所述每个数据块的值的数据部分和表示所述每个数据块的属性的描述部分。
6.根据权利要求1至3中任一项所述的即时通讯中联系人状态的通知方法,其特征在于,还包括:
检测所述所有联系人的当前状态是否发生变化;
每经过预定时间后,将所述当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至所述每个联系人对应的终端。
7.根据权利要求1至3中任一项所述的即时通讯中联系人状态的通知方法,其特征在于:
每个所述状态表中的每个指示位对应于一个所述联系人的标识信息,以及每个所述终端类型表中的每个指示位对应于一个所述联系人的标识信息;和/或
根据所述所有联系人的数量和/或处理***单次能够读取或处理的数据量,设置每个所述状态表和/或每个所述终端类型表的大小。
8.一种即时通讯中联系人状态的通知装置,其特征在于,包括:
设置单元,用于设置用于表示联系人状态的状态表,每个所述状态表用于对所有联系人的多种状态中对应的一种状态进行标识,每个所述状态表包括多个指示位,每个所述指示位用于对相应的一个联系人的当前状态是否是所述每个状态表对应的状态进行标识;
发送单元,用于将用于对所述所有联系人的至少一种状态进行标识的至少一个所述状态表发送至所述所有联系人中每个联系人对应的终端,以由所述每个联系人对应的终端根据至少一个所述状态表确定所述所有联系人的当前状态。
9.根据权利要求8所述的即时通讯中联系人状态的通知装置,其特征在于,还包括:
获取单元,用于获取所述每个联系人在多个终端中每个终端上的状态;
选择单元,用于根据所述多个终端的优先级,选择所述每个联系人在所述多个终端中优先级最高的终端上的状态作为所述每个联系人的当前状态。
10.根据权利要求9所述的即时通讯中联系人状态的通知装置,其特征在于:
所述设置单元还用于,设置终端类型表,每个终端类型表包括多个指示位,每个终端类型表中的每个指示位用于对所述所有联系人中相应的一个联系人在所述多个终端中的一个终端上的当前状态;
所述发送单元还用于,将用于对所述所有联系人在所述多个终端上的当前状态进行标识的多个所述终端类型表发送至所述每个联系人对应的至少一个终端,以由所述每个联系人对应的至少一个终端根据多个所述终端类型表确定所述所有联系人在所述多个终端中每个终端上的状态。
11.根据权利要求8至10中任一项所述的即时通讯中联系人状态的通知装置,其特征在于,所述发送单元包括:
划分单元,用于将每个所述状态表或每个所述终端类型表划分为多个数据块;
确定单元,用于根据所述多个数据块中每个数据块包含的指示位的值,确定所述每个数据块的值;
执行单元,用于将所述每个数据块的值发送至所述每个联系人对应的终端,或仅将所述多个数据块中指定数据块的值发送至所述每个联系人对应的终端,其中,所述指定数据块中包含的所有指示位的值不同。
12.根据权利要求11所述的即时通讯中联系人状态的通知装置,其特征在于,所述执行单元具体用于:
通过具有预定格式的数据报文将每个所述状态表或每个所述终端类型表发送至所述每个联系人对应的终端;
其中,所述预定格式包括:表示所述状态表或所述终端类型表的报头部分、表示所述每个数据块的值的数据部分和表示所述每个数据块的属性的描述部分。
13.根据权利要求8至10中任一项所述的即时通讯中联系人状态的通知装置,其特征在于,还包括:
检测单元,用于检测所述所有联系人的当前状态是否发生变化;
所述发送单元还用于,每经过预定时间后,将所述当前状态发生变化的联系人的标识信息和变化后的状态通过广播报文的方式发送至所述每个联系人对应的终端。
14.根据权利要求8至10中任一项所述的即时通讯中联系人状态的通知装置,其特征在于:
每个所述状态表中的每个指示位对应于一个所述联系人的标识信息,以及每个所述终端类型表中的每个指示位对应于一个所述联系人的标识信息;和/或
所述设置单元还用于,根据所述所有联系人的数量和/或处理***单次能够读取或处理的数据量,设置每个所述状态表和/或每个所述终端类型表的大小。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410852163.2A CN104506424B (zh) | 2014-12-31 | 2014-12-31 | 即时通讯中联系人状态的通知方法及通知装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410852163.2A CN104506424B (zh) | 2014-12-31 | 2014-12-31 | 即时通讯中联系人状态的通知方法及通知装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104506424A true CN104506424A (zh) | 2015-04-08 |
CN104506424B CN104506424B (zh) | 2018-07-13 |
Family
ID=52948139
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410852163.2A Active CN104506424B (zh) | 2014-12-31 | 2014-12-31 | 即时通讯中联系人状态的通知方法及通知装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104506424B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105050111A (zh) * | 2015-06-15 | 2015-11-11 | 上海斐讯数据通信技术有限公司 | 一种接入点向服务器报告终端接入状态的方法及*** |
WO2017219815A1 (zh) * | 2016-06-24 | 2017-12-28 | 中兴通讯股份有限公司 | 消息传输***、消息发送方法和装置、接收方法和装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101404627A (zh) * | 2008-11-13 | 2009-04-08 | 腾讯科技(深圳)有限公司 | 即时通讯***更新联系人状态的方法及即时通讯*** |
US20110252099A1 (en) * | 2010-04-07 | 2011-10-13 | Amol Pattekar | Apparatus and method for efficiently managing data in a social netwroking service |
CN102347847A (zh) * | 2011-09-26 | 2012-02-08 | 深圳中兴网信科技有限公司 | 一种联系人状态发布方法及其*** |
CN102368747A (zh) * | 2011-09-11 | 2012-03-07 | 上海量明科技发展有限公司 | 即时通信中用以提供上线信息的方法及*** |
CN103281382A (zh) * | 2013-05-31 | 2013-09-04 | 合一网络技术(北京)有限公司 | 一种基于p2p的文件传输方法和节点 |
-
2014
- 2014-12-31 CN CN201410852163.2A patent/CN104506424B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101404627A (zh) * | 2008-11-13 | 2009-04-08 | 腾讯科技(深圳)有限公司 | 即时通讯***更新联系人状态的方法及即时通讯*** |
US20110252099A1 (en) * | 2010-04-07 | 2011-10-13 | Amol Pattekar | Apparatus and method for efficiently managing data in a social netwroking service |
CN102368747A (zh) * | 2011-09-11 | 2012-03-07 | 上海量明科技发展有限公司 | 即时通信中用以提供上线信息的方法及*** |
CN102347847A (zh) * | 2011-09-26 | 2012-02-08 | 深圳中兴网信科技有限公司 | 一种联系人状态发布方法及其*** |
CN103281382A (zh) * | 2013-05-31 | 2013-09-04 | 合一网络技术(北京)有限公司 | 一种基于p2p的文件传输方法和节点 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105050111A (zh) * | 2015-06-15 | 2015-11-11 | 上海斐讯数据通信技术有限公司 | 一种接入点向服务器报告终端接入状态的方法及*** |
CN105050111B (zh) * | 2015-06-15 | 2018-05-18 | 上海斐讯数据通信技术有限公司 | 一种接入点向服务器报告终端接入状态的方法及*** |
WO2017219815A1 (zh) * | 2016-06-24 | 2017-12-28 | 中兴通讯股份有限公司 | 消息传输***、消息发送方法和装置、接收方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN104506424B (zh) | 2018-07-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102668516B (zh) | 一种云消息服务中实现消息传递的方法和装置 | |
CN109714330B (zh) | 一种跨网络的断点续传方法和*** | |
US11593029B1 (en) | Identifying a parent event associated with child error states | |
US11869083B2 (en) | Fair credit screened market data distribution | |
CN100357901C (zh) | 一种主设备和备份设备之间数据核查的方法 | |
TWI531919B (zh) | 文檔收發系統和方法及其文檔收發裝置 | |
CN101305577B (zh) | 与消息传送相关的设备和方法 | |
CN112015815B (zh) | 数据同步方法、装置及计算机可读存储介质 | |
CN102148833A (zh) | 数据报表的传输方法、服务器、客户端以及*** | |
CN110232044B (zh) | 一种大数据汇总调度服务的实现***及方法 | |
CN102523290A (zh) | 数据的处理方法、设备和*** | |
CN109088933A (zh) | 大批量名单传送方法、获取方法及相应的装置、电子设备 | |
CN103457802A (zh) | 一种信息传输***及方法 | |
CN104080059A (zh) | 一种收发短信的实现方法、装置及*** | |
CN103490978A (zh) | 终端、服务器和消息监视方法 | |
CN107181794B (zh) | 基于dimse消息发送与接收的dicom网络传输方法 | |
CN104506424A (zh) | 即时通讯中联系人状态的通知方法及通知装置 | |
CN104092754B (zh) | 文件存储***和文件存储方法 | |
CN103297477A (zh) | 一种数据采集上报***及数据处理方法和代理服务器 | |
CN115982133A (zh) | 数据处理方法及装置 | |
CN112256446B (zh) | 一种Kafka消息总线管控方法及*** | |
WO2017167101A1 (zh) | 彩信附件管理方法、装置、通信***及计算机存储介质 | |
CN102238166A (zh) | 装置管理用户端及其提取物件的方法 | |
CN110019025B (zh) | 一种流数据处理方法和装置 | |
CN104703154B (zh) | 一种lte上行家庭网关的短信存储方法及*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |