即时通讯中联系人状态的通知方法及通知装置

摘要

本发明提供了一种即时通讯中联系人状态的通知方法及通知装置，其中，即时通讯中联系人状态的通知方法，包括：设置用于表示联系人状态的状态表，每个所述状态表用于对所有联系人的多种状态中对应的一种状态进行标识，每个所述状态表包括多个指示位，每个所述指示位用于对相应的一个联系人的当前状态是否是所述每个状态表对应的状态进行标识；将用于对所述所有联系人的至少一种状态进行标识的至少一个所述状态表发送至所述所有联系人中每个联系人对应的终端，以由所述每个联系人对应的终端根据至少一个所述状态表确定所述所有联系人的当前状态。通过本发明的技术方案，可以有效地降低服务器在传输状态报文时的数据流量。

说明书

技术领域

本发明涉及即时通讯技术领域，具体而言，涉及一种即时通讯中联系 人状态的通知方法和一种即时通讯中联系人状态的通知装置。

背景技术

目前，企业内部通常都需要使用即时通信服务，由于使用个人版的即 时通讯工具(如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通道传输一个广播状态报文完成 后，如果有非状态报文的报文发送，则先发送非状态报文。否则发送状态 报文，发送状态报文时，检查当前的待发送的广播状态报文序号，是否有 多个待发送的，如果有则整个进行合并成一个报文发送。

以上结合附图详细说明了本发明的技术方案，本发明提出了一种新的 即时通讯中联系人状态的通知方案，可以有效地降低服务器在传输状态报 文时的数据流量。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于 本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精 神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明 的保护范围之内。