CN107306296A - 域名替代使用方法 - Google Patents

域名替代使用方法 Download PDF

Info

Publication number
CN107306296A
CN107306296A CN201610237872.9A CN201610237872A CN107306296A CN 107306296 A CN107306296 A CN 107306296A CN 201610237872 A CN201610237872 A CN 201610237872A CN 107306296 A CN107306296 A CN 107306296A
Authority
CN
China
Prior art keywords
domain name
domainid
inquiry
eicm
icmsvr
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.)
Pending
Application number
CN201610237872.9A
Other languages
English (en)
Inventor
***
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to CN201610237872.9A priority Critical patent/CN107306296A/zh
Publication of CN107306296A publication Critical patent/CN107306296A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了域名替代使用方法，通过建立域名和DomainID的对应关系，在消息中需要携带域名相关信息的地方替代为“携带对应的DomainID”，或者，在需要存储域名相关信息的地方，替代为“存储对应的DomainID”；在面向用户时，根据待输出内容中的DomainID，按照所建立的对应关系，获取对应的域名；向用户侧输出所获取的域名。该方法兼顾了效率和易用性要求。还公开ICMSys，通过建立域名和DomainID的对应关系，ICMSvr接收到EICM发送的相关查询请求后，获取相应的域名或DomainID，将相应的查询结果回复给所述EICM。这样，使得所述对应关系数据能够得到轻便、有效、便捷的维护。

Description

域名替代使用方法
技术领域
本发明涉及互联网通信，更确切地说涉及域名替代使用方法，以及有关的***。
背景技术
在互联网通信中，涉及到全球统一身份(GUID，Global Unified Identity)，所述GUID包括两部分：归属码(HCode，Home Code)和用户码(UCode，User Code)。其中，HCode指示该GUID，也即该GUID对应的互联网用户(IUsr，Internet User)归属于即时通信网络(IMN，Instant Messenger Network)中哪一个即时通信***(IMS，Instant Messenger System)的哪一个归属服务器(HSvr，Home Server)；UCode用于指示一个HCode下不同的GUID或IUsr。
一般地，一个IMS只拥有一个HSvr。
通过建立HCode和HSvr的对应关系，根据一个HCode可以获得所指向的一个HSvr。
所述HCode可以是一个域名，对应的GUID为一邮件地址(简称邮址)，其中的UCode为该邮址的用户名。此时，GUID表示形式一般为：用户名@域名，这里@为邮址指示符。
所述HCode也可以是一个国际商码(IBC，International Business Code)，对应的UCode为一级用户标识(FLUI，First Level User Identity)。对应的GUID为一主从码(MsC，Master-slave Code)。此时，GUID表示形式一般为：FLUI#IBC，这里，#为MsC指示符。
影码作为一种特殊的GUID，其对应的HCode是一个归属二元组(H2T，Home Two-Tuple)。所述H2T包括两部分：国家码(CC，Country Code)和国内商码(NBC，National Business Code)，即(CC,NBC)或CC*NBC。影码的表示形式一般为：CC*NBC*UCode，这里*为影码指示符或分隔符。由于影码在去除影码指示符后都为数字，因此，通常情况下，影码指示符被省略。
在全球范围内标识一个互联网用户，是归属于不同IMS的用户间交互的基础，也即，是不同IMS间互联互通的基础。例如，对于归属于两个不同IMS的IUsr：UsrA和UsrB来说，UsrA要与UsrB进行跨IMS的即时通信，那么UsrA就要知道UsrB的GUID，以确定UsrB是哪一个IMS的哪一个用户。反之，UsrB要知道UsrA的GUID。
更多信息，参见申请号为201310037232.X的《通信方法和***》发明专利，以及申请号为201310049772.X的《影码寻址方法》发明专利。
一个IMS可以拥有多个HCode。但通常，一个IMS只需要拥有一个域名类HCode即可。这种情况下，一个用户只需记住好友提供的一个email地址形式的GUID，即可与相应的好友保持通信联系。
如图7所示，为IMN示例图。在该图中：
A服务商(SP-A)的HSvr为HSvr-A，其中，注册有用户A(UsrA)和用户X(UsrX)；
B服务商(SP-B)的HSvr为HSvr-B，其中，注册有用户B(UsrB)和用户Y(UsrY)；
C服务商(SP-C)的HSvr为HSvr-C，其中，注册有用户C(UsrC)和用户Z(UsrZ)；
D服务商(SP-D)的HSvr为HSvr-D，其中，注册有用户D(UsrD)和用户O(UsrO)。
例如，SP-A是米聊、SP-B是易信、SP-C是陌陌、SP-D是QQ，其中，HCode值miliao.com归属于HSvr-A，HCode值yixin.im归属于HSvr-B，HCode值immomo.com归属于HSvr-C，HCode值qq.com归属于HSvr-D等等。
但是，由于域名是不定长的，其最大长度可达到67个字节，这样，在消息中需要携带HCode值的地方，直接携带域名，特别地，将该域名作为消息地址的一部分，就会直接影响消息寻址或传输效率。另外，在存储相关数据时，相应存储HCode值的地方，直接存储域名，也会导致存储空间的浪费以及检索效率底下的问题。
不定长IBC类HCode也类似存在上述问题。
为了解决上述在消息中直接携带域名，或者在存储相关数据时直接存储域名，等等所产生的效率底下问题，可以采用固定长度IBC类HCode。例如，直接用一个32bit的二进制数作为HCode。这样，在消息中，或者在存储空间中，只需要4个字节就可以表示一个HCode值，从而，便于在消息中携带，便于根据HCode进行寻址，也便于存储和检索。
但是，用一个32bit的二进制数作为HCode，不便于用户识别和记忆，将会严重影响用户的体验，进而影响到业务的发展。
发明内容
有鉴于此，本发明提供了一种域名替代使用方法，该方法通过建立域名和DomainID的对应关系；在消息中需要携带域名相关信息的地方替代为“携带对应的DomainID”，或者，在需要存储域名相关信息的地方，替代为“存储对应的DomainID”；在面向用户时，根据待输出内容中的DomainID，按照所建立的对应关系，获取对应的域名；向用户侧输出所获取的域名。该方法兼顾了效率和易用性要求。
一种域名替代使用方法，建立域名和域标识(DomainID)的对应关系；在消息中需要携带域名相关信息的地方替代为“携带对应的DomainID”，或者，在需要存储域名相关信息的地方，替代为“存储对应的DomainID”；所述方法包括以下步骤：
a、根据待输出内容中的DomainID，按照所建立的对应关系，获取对应的域名；
b、向用户侧输出所获取的域名。
本发明还提供一种域名替代使用方法，建立域名和DomainID的对应关系；所述方法包括以下步骤：
a、获取用户输入的域名，按照所建立的对应关系，获取对应的DomainID；
b、在消息中需要携带所述域名相关信息的地方替代为“携带所述对应的DomainID”；或者，在需要存储所述域名相关信息的地方，替代为“存储所述对应的DomainID”。
本发明还提供一种IP地址获取方法，用于获取一个DomainID对应的IP地址；建立域名和DomainID的对应关系；所述方法包括以下步骤：
a、根据所述DomainID，按照所建立的对应关系，获取对应的域名；
b、按照域名解析过程，得到所获取域名对应的IP地址。
可选地，在建立的域名和DomainID的对应关系中，进一步包括所述域名对应的IP地址属性；
所述步骤a进一步是：根据所述DomainID，按照所建立的对应关系，获取对应的对应关系记录，判断该记录的IP地址是否有效，如果有效，则结束IP地址求解过程；否则，才执行步骤b；
在步骤b之后，进一步包括，将所获取的IP地址保存在所述记录中。
本发明还提供一种域名相关信息导入方法，建立域名和DomainID的对应关系；所述方法包括以下步骤：
a、根据要导入文件中相应的域名，按照所建立的对应关系，获取对应的DomainID；
b、在向***导入所述域名相关信息时，替代为“导入对应的DomainID”。
本发明还提供一种域名相关信息导出方法，建立域名和DomainID的对应关系；所述方法包括以下步骤：
a、根据要导出数据中相应的DomainID，按照所建立的对应关系，获取对应的域名；
b、在向导出文件输出所述DomainID信息时，替代为“输出对应的域名”。
本发明还公开一种ICMSys，通过建立域名和DomainID的对应关系，ICMSvr接收到EICM发送的相关查询请求后，获取相应的域名或DomainID，将相应的查询结果回复给所述EICM。这样，就使得所述对应关系数据能够在整个网络中各个相应模块内得到轻便、有效、便捷的维护。
所述ICMSys包括互联管理服务器(ICMSvr)和互联管理客户端(EICM)；
在ICMSvr中，建立域名和DomainID的对应关系；
ICMSvr向EICM提供域名查询服务或DomainID查询服务；
所述的ICMSvr向EICM提供的所述域名查询服务是指：ICMSvr接收到EICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述EICM；
所述的ICMSvr向EICM提供的所述DomainID查询服务是指：ICMSvr接收到EICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述EICM。
可选地，进一步设置根互联管理服务器(RICM)；
在RICM中，建立域名和DomainID的对应关系；
RICM向ICMSvr提供域名查询服务或DomainID查询服务；
所述的RICM向ICMSvr提供的所述域名查询服务是指：RICM接收到ICMSvr发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述ICMSvr；
所述的RICM向ICMSvr提供的所述DomainID查询服务是指：RICM接收到ICMSvr发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述ICMSvr。
可选地，所述ICMSvr包括至少一个一级互联管理服务器(FLICM)和若干二级互联管理服务器(SLICM)；
所述的在ICMSvr中建立域名和DomainID的对应关系进一步是：在所述FLICM中建立域名和DomainID的对应关系，在所述SLICM中，也建立域名和DomainID的对应关系；
FLICM向SLICM提供域名查询服务或DomainID查询服务；
所述的FLICM向SLICM提供的域名查询服务是指：FLICM接收到SLICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述SLICM；
所述的FLICM向SLICM提供的DomainID查询服务是指：FLICM接收到SLICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述SLICM；
所述的ICMSvr向EICM提供域名查询服务或DomainID查询服务进一步是：SLICM向EICM提供域名查询服务或DomainID查询服务
所述的SLICM向EICM提供的所述域名查询服务是指：SLICM接收到EICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述EICM；
所述的SLICM向EICM提供的所述DomainID查询服务是指：SLICM接收到EICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述EICM。
所述的RICM向ICMSvr提供域名查询服务或DomainID查询服务进一步是：RICM向FLICM提供域名查询服务或DomainID查询服务；
所述的RICM向FLICM提供的所述域名查询服务是指：RICM接收到FLICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述FLICM；
所述的RICM向FLICM提供的所述DomainID查询服务是指：RICM接收到FLICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述FLICM。
可选地，对于来自下一级模块的域名查询请求或DomainID查询请求，本级模块在本地执行域名查询服务或DomainID查询服务失败时，向相应的上一级模块发送对应的查询请求；在收到来自所述上一级模块返回的查询结果后，保存该查询结果，并将相应的查询结果回复给所述下一级模块。
按照本发明域名替代使用方法，通过域名和DomainID的交替使用，既能满足了***对于效率的要求，又能满足用户对于易用性的要求。特别地，通过实施本发明提出的ICMSys，使得整个IMN网络中，相关的各个模块(需要用到相应的域名和DomainID的对应关系数据)内，只需要保存当前使用的相关域名和DomainID的对应关系数据即可，并且，通过ICMSys***来保证所述相关的各个模块内，相应的域名和DomainID的对应关系数据根据需要自动更新，这样，就极大地方便了整个互联互通网络的维护和运营。
附图说明
图1所示，为本发明总体实施方式流程图。
图2所示，为二层ICMSys示例图。
图3所示，为三层ICMSys示例图。
图4所示，为四层ICMSys示例图。
图5所示，为EICM根据DomainID获取域名的流程三示例图。
图6所示，为EICM根据DomainID获取域名的流程五示例图
图7所示，为IMN示例图。
具体实施方式
为使本发明目的、技术方案和优点更加清楚明白，下面结合实施例，从多个方面进行详细说明。
为了达到预期的技术效果，本发明首先分别针对相关的域名，指配对应的域标识(DomainID，Domain Identity)。
本发明以DomainID是一个32bit的二进制数为例，但不用于限定本发明。
实际当中，可以通过建立域名和DomainID的对应关系表，来保存一个域名对应的DomainID。参见如表1所示的域描述表：
表1
DomainID 域名
1 miliao.com
2 yixin.im
3 immomo.com
4 qq.com
这样，可以根据一个DomainID，按照所述域描述表，来获取对应的域名；反之，可以根据一个域名，按照所述域描述表，来获取对应的DomainID。
本发明后面以{域名最大长度是67字节}为例进行举例说明。
在消息中需要携带域名相关信息的地方，替代为“携带对应的DomainID”。这样，由于DomainID只需占用4个字节，就可以大大压缩消息的长度。特别地，相较于根据域名进行消息寻址，在根据DomainID进行寻址时，还可以大大提高消息的寻址效率，因此，可以大大提高消息的整体传输效率。
相应地，在存储相关数据时，在需要存储域名相关信息的地方，替代为“存储对应的DomainID”。由于DomainID只需占用4个字节，这样，就大大地节省了存储空间。特别地，也由于DomainID只占用4个字节，因而，相较于根据域名进行信息检索，根据DomainID进行信息检索时，可以有效提高信息的检索效率。并且，作为被检索信息，检索相应的DomainID，也比检索相应的域名效率高。
例如，在申请号为201310501013.2的《同基账户通知机制实现方法》发明专利中提到，一个账户的同基账户信息中，可能包括若干个其它HSvr的HCode值。例如，HSvr可以通过在账户信息中设置OtherAddrHomes属性，来保存一个账户的同基账户信息。
以{最多允许的同基账户个数是3，}为例，这种情况下，如果该HCode直接是域名的话，OtherAddrHomes属性就需要占用134(即(3-1)*67)个字节，这样，就占用了很大存储空间。而如果所述HCode值是一个32bit的DomainID的话，OtherAddrHomes属性只需要占用8(即(3-1)*4)个字节，对比之下，优势非常明显。
还例如，在申请号为201610028014.3的《号码字典》发明专利中，提到，在号码字典中会保存相应电话号码对应的相关属性信息。
所述电话号码对应的相关属性信息一般地包括相应HSvr的HCode。以该HCode是域名为例，例如，易信的域名yixin.im，陌陌的域名immomo.com，米聊的域名miaoliao.com，微信的域名weixin.qq.com等等。用户根据一个电话号码在陌陌服务器里注册了账户，则，在号码字典中，保存一条记录，以登记该电话号码对应的域名包括immomo.com。
这种情况下，在号码字典中就需要保存大量的域名信息，特别地，在需要批量查询电话号码的属性信息时，将会严重影响查询效率。
如果所述HCode值是一个32bit的DomainID的话，在号码字典中，登记的HCode只占用4个字节，这样，就可以大大地节省存储空间。特别地，在批量查询电话号码的属性信息时，查询回复消息中，一次可以携带更多的查询结果。
还例如，在申请号为201610086133.4的《交换方法和交换云》发明专利中提到一种消息交换方法，所述消息包括目的SPAddr；该方法设置路由数据(RoutingData)；该方法根据消息的目的SPAddr，按照设置的RoutingData，确定消息的下一站地址(NextAddr)，即确定目标NextAddr；按照所确定的目标NextAddr，将所述消息发送出去。按照该方法，交换云(XCld，eXchange Cloud)中各个交换服务器(XS，eXchange Server)通过配合，就可以实现各个驻地服务器(RSvr，Residence Server)之间的消息交互。
其中，SPAddr为半永久地址，所述SPAddr由账户地址(AccoAddr)和驻地码(RCode)组成。而AccoAddr都由一个地址基(AddrBase)和一个地址归属(AddrHome)构成。所述AddrHome是相应HSvr的HCode。
关于SPAddr的更多描述，参见申请号为201410098231.0的《基于半永久地址的消息发送方法》发明专利。
如果HCode为域名的话，则，在消息中携带所述目的SPAddr时，仅AddrHome就需要占用67个字节。而如果HCode是一个32bit的DomainID的话，则，在消息中携带所述目的SPAddr时，AddrHome部分只需要占用4个字节，这样就减少了消息长度63个字节。
特别地，在设置RoutingData时，还根据相应HSvr的HCode来进行设置，并且，在寻址时，根据消息的目的SPAddr的AccoAddr的AddrHome，按照设置的RoutingData来确定目标NextAddr。例如，在RoutingData中，根据相应HSvr的HCode值，对应设置默认的NextAddr(DefaultNextAddr)，也即设置HCode-Default对应关系数据，以便根据所述消息的目的SPAddr的AccoAddr的AddrHome来确定消息的目标NextAddr。
这种情况下，如果HCode为域名的话，则，不但增加了RoutingData的数据量，还因为要根据消息的目的SPAddr的AccoAddr的AddrHome来检索相应的RoutingData，而影响检索速度，进而影响到消息的整体寻址效率。
而如果HCode是一个32bit的DomainID的话，则不但可以大大减少RoutingData的数据量，还使得根据消息的目的SPAddr的AccoAddr的AddrHome来检索相应的RoutingData时，可以获得更高的检索速度，从而提高整个寻址的效率。
关于消息交换方法的更多描述，参阅所述的《交换方法和交换云》发明专利，这里不再过度转摘。
还例如，在互联互通的背景下，一个用户的好友列表中，好友的AccoAddr包括好友所在HSvr的HCode，即该AccoAddr的AddrHome。如果HCode为域名的话，相较HCode是一个32bit的DomainID，则，每个好友的AccoAddr要多出63个字节(即67-4)。
下面以{在存储HCode值时，也即，在需要存储相应域名相关信息时，存储对应域名的DomainID；在消息中需要携带HCode值，也即，携带相应域名相关信息时，携带对应域名的DomainID}为例，进行举例说明。
为了解决DomainID不便于用户识别和记忆的问题，本发明提出，在用户接口部分，在面向用户时，将相应的DomainID转换为对应的域名。
如图1所示，为本发明总体实施方式流程图。在该图中，
首先，在步骤11、根据待输出内容中的DomainID，按照所述域描述表，获取对应的域名。
步骤12、向用户输出所获取的域名。
所述输出可以是声光提示，例如通过屏幕显示，也可以是通过语音提示。
所述输出也可以是输出到一个数据文件中。例如，用户要将好友列表中好友数据导出到本地的一个文件中。
例如，在客户端设置域描述表，在从服务器侧或云端获取用户好友列表后，在向用户显示好友列表之前，按照所述域描述表，将相应的DomainID转换为对应的域名来进行显示。
这样，就便于用户的识别、记忆。
用户在打开好友列表时，一般地，要能显示好友的AccoAddr，以便于在社交中传播。例如，该地址可以印刷在用户的名片上。
在互联互通环境中，一个AccoAddr包括AddrBase和AddrHome两部分。友好的接口或用户界面，在显示AccoAddr的AddrHome部分时，不是显示或只显示DomainID值，而应显示出对应的域名，这样，便于用户识别、记忆，有助于AccoAddr的传播。
这里，将好友列表与所述域描述表进行关联显示，是一种成熟的数据表格处理技术，因此，这里不再赘述。
在用户接口部分，在面向***时，将对应的域名转换为DomainID。
例如，在用户输入一个AccoAddr时，例如，用户输入一个AccoAddr值[email protected]，欲加该AccoAddr对应用户为好友。按照所述域描述表，将AccoAddr值[email protected]的域名部分miliao.im置换为对应的DomainID值3。这样，在发送添加好友的消息时，在该消息中携带的AccoAddr值就成为liubei@3。这样，就保证了***内部仍然按照DomainID类HCode来处理消息，从而节约整个***存储空间，提高消息的整体传输和处理效率。
作为重要的接口部分，***配置数据的导入导出是一个非常重要的部分。
例如，XCld在设置RoutingData时，还根据相应HSvr的HCode来进行设置，其中，HCode是一个32bit的DomainID。在***初始化时，XCld根据运营维护人员配置的RoutingData配置文件，来初始化相应的RoutingData。
为了便于运维，在RoutingData配置文件中，相应的HCode为域名。
XCld在初始化时，按照所述域描述表，将RoutingData配置文件中相应的域名替换为对应的DomainID，而后，来初始化相应的RoutingData。
同样，在将XCld中RoutingData导出到RoutingData配置文件中时，按照所述域描述表，将RoutingData中相应的DomainID替换为对应的域名。
这样，既能满足RoutingData所占用内存较少，便于寻址，等优点，又方便了运维。
这样，按照本发明方法，就有效地解决了效率和便利性难以兼顾的问题。
有些情况下，HSvr需要获取一个DomainID对应的HSvr的IP地址，以便与该HSvr进行信息交互，这种情况下，就要根据相应DomainID来确定对应的IP地址。
在根据一个DomainID确定对应的IP地址时，先根据该DomainID，按照所述域描述表，获取对应的域名；按照域名解析过程，得到所获取域名对应的IP地址。
一般地，应用程序通过调用域名解析函数来求解一个域名对应的IP地址。
解析函数将待求解域名放在DNS请求中，以UDP报文方式发给本地域名服务器。本地的域名服务器查到域名后，将对应的IP地址放在应答报文中返回。同时域名服务器还必须具有连向其他服务器的信息以支持不能解析时的转发。若域名服务器不能回答该请求，则此域名服务器就暂成为DNS中的另一个客户，向根域名服务器发出请求解析，根域名服务器一定能找到下面的所有二级域名的域名服务器，这样以此类推，一直向下解析，直到查询到所请求的域名。
关于域名解析，以及根据一个域名，请求相应的域名服务器，获取对应的IP地址的过程，是成熟应用，这里不再赘述。
例如，当HSvr侧收到客户端发送的一个用于发送短信息的消息后，如果发现该消息的目的AccoAddr的AddrHome对应的DomainID是一个陌生的DomainID，即，根据该DomainID，无法获取转发所述消息的连接信息，这时，该HSvr需要根据所述DomainID获取目的HSvr的地址信息，以建立到该目的HSvr的连接，以便通过该连接，将所述消息发送给该目的HSvr。这时，该HSvr就需要根据消息的目的AccoAddr的AddrHome，即对应的DomainID，按照所述域描述表，来获取对应的域名，按照域名解析过程，获取该域名对应的IP地址。然后根据获取的IP地址，建立面向所述目的HSvr的连接，通过建立的连接，将所述消息发送出去。
按照现有的做法，在求解到一个域名对应的IP地址后，一般地，将该结果保存在本地的临时表中，这样，在下一次有应用需要求解同一个域名对应的IP地址时，可以先查询本地的临时表中是否保存了所述域名对应的IP地址。如果保存了，就不用再通过访问远端域名服务器来请求所述域名的IP地址，这样就可以提高求解IP地址的效率。
实际当中，可以在所述临时表中增加一个DomainID字段，用于记录所述域名被指配的DomainID，如果某个域名并没有被指配相应的DomainID，则该域名对应的DomainID值为0，即表示无效。这样，在根据一个DomainID来求解对应的IP地址时，可以先根据该DomainID查询所述临时表，判断是否查找到对应的IP地址，如果是，则结束IP地址求解过程；如果没有，则根据该DomainID，按照所述域描述表，获取对应的域名，然后求解该域名对应的IP地址。在求解到所获取的域名对应的IP地址后，将所获取的域名、所述DomainID、求解到的IP地址等信息保存在所述临时表中，以便以后使用。例如，在求解到所获取的域名对应的IP地址后，在所述临时表中存在该域名对应的记录时，将该记录的DomainID字段设置为所述DomainID；在所述临时表中，如果不存在所获取的域名对应的记录，则新增记录，在该新增记录中保存所获取的域名、所述DomainID、求解到的IP地址等信息。
由于更改所述临时表，涉及广泛，影响较大，因此，较佳地，在如表1所示的域描述表中增加IP地址字段，用于记录相应域名在DNS中被指配的IP地址。参见如表2所示的域描述表：
表2
DomainID 域名 IP
1 miliao.com 对应的IP地址
2 yixin.im 对应的IP地址
3 immomo.com 对应的IP地址
4 qq.com 对应的IP地址
在该表中，如果一个记录对应的IP地址为0，则表示该记录对应的IP地址无效。这种情况下，一般地，缘于尚未有求解对应DomainID的IP地址的事件发生。
在需要根据一个DomainID来求解对应的IP地址时，可以先根据该DomainID查询如表2所示的域描述表，获取对应的记录，判断该记录的IP地址是否有效，如果有效，则结束IP地址求解过程；如果无效，则求解该记录中相应域名对应的IP地址。
在求解到所述记录中相应域名对应的IP地址后，将求解到的IP地址填写到所述记录中，以便以后使用。
实际当中，上述的所述HSvr在{根据消息的目的AccoAddr的AddrHome，即对应的DomainID，按照所述域描述表，来获取对应的域名，按照域名解析过程，获取该域名对应的IP地址；然后根据获取的IP地址，建立面向所述目的HSvr的连接}后，还可以进一步建立该DomainID和所述连接信息的对应关系，例如该连接信息是一个套接口描述符(SktD，SocketDescriptor)，这样，以后再遇到消息的目的AccoAddr的AddrHome为该DomainID，就可以直接按照该对应关系获取对应的连接信息，并根据该连接信息来发送所述消息。
当然，所述连接信息也可以直接是所述IP地址。这种情况下，所述HSvr在按照所述对应关系获取到对应的IP地址后，建立面向所述目的HSvr的连接，而后才，通过建立的连接，将所述消息发送出去。
在HSvr侧，也通过设置所述域描述表，来保存相应域名与DomainID的对应关系。这样，在HSvr侧要获取一个DomainID对应的域名时，直接根据该DomainID，按照所述域描述表，获取对应的域名。
一种粗放的做法是在客户端侧保存所有域名和DomainID的对应关系数据。这样，在客户端需要获取一个DomainID对应的域名，或者是获取一个域名对应的DomainID时，总能从本地保存的域名和DomainID的对应关系数据中获取所要结果。
但是，实际上，这样做没有必要性，也是不可能的。
首先，一个用户的客户端涉及的域名是非常有限的。
以用户所有好友分别对应不同的域名来估计客户端涉及域名的最大数量，那么，一般地，其涉及的域名数量也不会超过用户的好友数量。而实际上，参与互联互通的HSvr的数量可能非常庞大。因此，在客户端侧保存所有域名和DomainID的对应关系数据不是必需的。
其次，参与互联互通的HSvr可能会发生变化。
例如，有新的HSvr参与到互联互通中，这种情况下，在客户端侧保存的域名和DomainID的对应关系数据可能需要随之更新。
因此，一般地，客户端只需要保存自己涉及到的域名和DomainID的对应关系数据即可。
基于此，本发明提供一种互联管理***(ICMSys，InterConnection Management System)。
在ICMSys中，包括互联管理服务器(ICMSvr，InterConnection Management Server)和末端互联管理模块(EICM，End InterConnection Management Module)。
这里，EICM是ICMSvr的下一级模块，ICMSvr是EICM的上一级模块。
如图2所示，为二层ICMSys示例图。在该图中，包括一个ICMSvr和与该ICMSvr连接的三个EICM：EICM-1、EICM-2和EICM-3。
通常，所述ICMSvr设置于HSvr侧，所述EICM设置于客户端侧。
一般地，直接在即时通讯客户端应用(APP)中集成EICM。
在ICMSvr中，设置如表1所示的域描述表，在该表中保存相关的域名和DomainID的对应关系数据。
ICMSvr向EICM提供域名查询服务或DomainID查询服务。
ICMSvr接收到EICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所述域描述表，获取对应的域名，将相应的查询结果回复给所述EICM。
ICMSvr接收到EICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所述域描述表，获取对应的DomainID，将相应的查询结果回复给所述EICM。
在EICM侧，也设置如表1所示的域描述表，以用于保存ICMSvr回复的所述查询结果。
在EICM侧，所设置的域描述表的初始状态一般为空。或者，预先用一些常用的DomainID和域名对应关系数据，来初始化所述域描述表。
所述EICM收到ICMSvr回复的查询结果后，将其保存于本地设置的域描述表中，以备下次使用。
EICM在需要根据DomainID获取域名时，或者在需要根据域名获取DomainID时，先查找本地设置的域描述表，判断是否能够获取所需结果，如果成功，则直接结束；如果不成功，才向ICMSvr发送相应的查询请求。
例一、EICM根据DomainID获取域名
参见如下流程：
步骤101、所述EICM在本地获取对应的域名：根据所述DomainID，按照本地设置的域描述表，获取对应的域名；判断是否成功获取到对应的域名，如果是，则结束流程；否则，进入步骤102。
步骤102、所述EICM向ICMSvr发送域名查询请求，在该请求中携带所述DomainID。
步骤103、所述ICMSvr在收到所述EICM发送的域名查询请求后，在本地获取对应的域名：根据该请求中携带的所述DomainID，按照本地设置的域描述表，获取对应的域名。
步骤104、所述ICMSvr将相应的查询结果回复给所述EICM。
例如，所述查询回复消息中包括所述DomainID和对应的域名。
步骤105、所述EICM收到所述查询结果后，保存该查询结果。
例如，将所述DomainID和对应的域名，保存在本地设置的域描述表中。
例二、EICM根据域名获取DomainID
参见如下流程：
步骤201、所述EICM在本地获取对应的DomainID：根据所述域名，按照本地设置的域描述表，获取对应的DomainID；判断是否成功获取到对应的DomainID，如果是，则结束流程；否则，进入步骤202。
步骤202、所述EICM向ICMSvr发送DomainID查询请求，在该请求中携带所述域名。
步骤203、所述ICMSvr在收到所述EICM发送的DomainID查询请求后，在本地获取对应的DomainID：根据该请求中携带的所述域名，按照本地设置的域描述表，获取对应的DomainID。
步骤204、所述ICMSvr将相应的查询结果回复给所述EICM。
例如，所述查询回复消息中包括所述域名和对应的DomainID。
步骤205、所述EICM收到所述查询结果后，保存该查询结果。
例如，将所述域名和对应的DomainID，保存在本地设置的域描述表中。
所述ICMSvr可以是针对所有HSvr来设置的。这样，所有HSvr的EICM在如上所述的“需要”(如上述步骤102和步骤202中，在所述不成功时)的情况下，都可以向该ICMSvr发送相应的查询请求。
由于EICM数量将会极其庞大，数量级别预计在数千亿之上，因此，在当前技术背景下，所述ICMSvr针对所有HSvr来设置的做法并不是好的选择。
因此，本发明建议，所述ICMSvr属于HSvr的一个子服务模块或子***。后面以此为例，但不用于限定本发明。
如上所述，参与互联互通的HSvr可能会发生变化，例如，有新的HSvr参与到互联互通中，这种情况下，在ICMSvr侧保存的域名和DomainID的对应关系数据就可能需要随之更新。
基于此，本发明进一步设置根互联管理服务器(RICM，Root InterConnection ManagementServer)。
这里，ICMSvr是RICM的下一级模块，RICM是ICMSvr的上一级模块。
如图3所示，为三层ICMSys示例图。在该图中，包括一个RICM，两个ICMSvr：ICMSvr-1和ICMSvr-2，五个EICM：EICM-1、EICM-2、EICM-3、EICM-4和EICM-5。
ICMSvr-1和ICMSvr-2连接到RICM；
EICM-1、EICM-2和EICM-3连接到ICMSvr-1；EICM-4和EICM-5连接到ICMSvr-2。
在RICM中，设置如表1所示的域描述表，在该表中保存相关的域名和DomainID的对应关系数据。
RICM在保存的域名和DomainID的对应关系数据发生变化后，将相关变化信息同步到各个ICMSvr中。
例如，在RICM中，可以保存各个ICMSvr的描述信息，例如地址信息。RICM在保存的域名和DomainID的对应关系数据发生变化后，可以向各个ICMSvr发送变化通知消息。所述变化通知消息中直接携带相应的变化描述数据，各个ICMSvr收到所述变化通知消息后，根据所述变化描述数据，更新自己保存的域名和DomainID的对应关系数据。
还例如，RICM在保存的域名和DomainID的对应关系数据发生变化后，更新最新数据版本号，以及生成数据变化描述。各个ICMSvr定期或不定期查询所述数据版本号，判断自己保存的域名和DomainID的对应关系数据是否是最新的，如果不是，则获取数据变化描述，根据获取的数据变化描述，更新自己保存的域名和DomainID的对应关系数据。
由于两个模块之间的数据同步是成熟技术，因此，这里不再模仿赘述。
所述的域名和DomainID的对应关系数据发生变化可以是新增了一条域名和DomainID的对应关系记录，或者是删除了一条域名和DomainID的对应关系记录。后面不再就此赘述。
一般地，一个HSvr要和互通联盟中其它HSvr进行互通，应先申请加入到互联互通联盟，经过批准后，在RICM中登记其域名，并为其指配一个唯一的DomainID，然后保存该域名和指配的DomainID。
实际当中，在ICMSvr侧也并非一定要保存所有域名和DomainID的对应关系数据。例如，地球上某一偏僻区域的HSvr的用户，只和HSvr-A的用户发生交往，而和HSvr-B的用户没有发生交往，则HSvr-B就不一定要保存那个HSvr的域名和DomainID的对应关系数据。
较佳地，RICM向ICMSvr提供域名查询服务或DomainID查询服务。
RICM接收到ICMSvr发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所述域描述表，获取相应的域名，将相应的查询结果回复给所述ICMSvr。
RICM接收到ICMSvr发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所述域描述表，获取相应的DomainID，将相应的查询结果回复给所述ICMSvr。
在ICMSvr侧，所设置的域描述表的初始状态可以为空，或者，预先用一些常用的DomainID和域名对应关系数据，来初始化所述域描述表。
所述ICMSvr收到RICM回复的查询结果后，将其保存于本地设置的域描述表中，以备下次使用。
ICMSvr在需要根据DomainID获取域名时，或者在需要根据域名获取DomainID时，先查找本地设置的域描述表，判断是否能够获取所需结果，如果成功，则直接结束；如果不成功，才向RICM发送查询请求。
例三、EICM根据DomainID获取域名
参见如下流程：
步骤301、所述EICM在本地获取对应的域名：根据所述DomainID，按照本地设置的域描述表，获取对应的域名；判断是否成功获取到对应的域名，如果是，则结束流程；否则，进入步骤302。
步骤302、所述EICM向ICMSvr发送域名查询请求，在该请求中携带所述DomainID。
步骤303、所述ICMSvr接收到所述EICM发送的所述域名查询请求后，在本地获取对应的域名：根据该请求中携带的所述DomainID，按照本地设置的域描述表，获取对应的域名；判断是否成功，如果是，则直接进入步骤308；否则，进入步骤304。
步骤304、所述ICMSvr向RICM发送域名查询请求，在该请求中携带所述DomainID。
步骤305、RICM接收到所述ICMSvr发送的所述域名查询请求后，在本地获取对应的域名：根据该请求中携带的所述DomainID，按照本地设置的域描述表，获取对应的域名。
步骤306、RICM将相应的查询结果回复给所述ICMSvr。
例如，所述查询回复消息中包括所述DomainID和对应的域名。
步骤307、所述ICMSvr收到所述查询结果后，保存该查询结果。
例如，将所述DomainID和对应的域名，保存在本地设置的域描述表中。
步骤308、所述ICMSvr将相应的查询结果回复给所述EICM。
例如，所述查询回复消息中包括所述DomainID和对应的域名。
步骤309、所述EICM收到所述查询结果后，保存该查询结果。
例如，将所述DomainID和对应的域名，保存在本地设置的域描述表中。
如图5所示，为EICM根据DomainID获取域名的流程三示例图。
例四、EICM根据域名获取DomainID
参见如下流程：
步骤401、所述EICM在本地获取对应的DomainID：根据所述域名，按照本地设置的域描述表，获取对应的DomainID；判断是否成功获取到对应的DomainID，如果是，则结束流程；否则，进入步骤402。
步骤402、所述EICM向ICMSvr发送DomainID查询请求，在该请求中携带所述域名。
步骤403、所述ICMSvr接收到所述EICM发送的所述DomainID查询请求后，在本地获取对应的DomainID：根据该请求中携带的所述域名，按照本地设置的域描述表，获取对应的DomainID；判断是否成功，如果是，则直接进入步骤408；否则，进入步骤404。
步骤404、所述ICMSvr向RICM发送DomainID查询请求，在该请求中携带所述域名。
步骤405、RICM接收到所述ICMSvr发送的所述DomainID查询请求后，在本地获取对应的DomainID：根据该请求中携带的所述域名，按照本地设置的域描述表，获取对应的DomainID。
步骤406、RICM将相应的查询结果回复给所述ICMSvr。
例如，所述查询回复消息中包括所述域名和对应的DomainID。
步骤407、所述ICMSvr收到所述查询结果后，保存该查询结果。
例如，将所述域名和对应的DomainID，保存在本地设置的域描述表中。
步骤408、所述ICMSvr将相应的查询结果回复给所述EICM。
例如，所述查询回复消息中包括所述域名和对应的DomainID。
步骤409、所述EICM收到所述查询结果后，保存该查询结果。
例如，将所述域名和对应的DomainID，保存在本地设置的域描述表中。
实际当中，当一个HSvr的用户数量非常庞大时，例如10至50亿用户，该HSvr会是一个非常庞大的分布式***或网络。参见所述的《基于半永久地址的消息发送方法》发明专利，其中提到一种HSvr，所述HSvr包括多个RSvr。一般地，每个RSvr会连接大量的用户客户端，以响应用户客户端的业务请求。
以所述客户端集成了所述EICM为例。
当用户客户端需要查看号码簿号码中哪些号码在互联互通联盟中哪些HSvr里注册了相应的账户时，该客户端会向RSvr发送号码字典查询请求，请求中携带号码簿中的电话号码。RSvr会将这种请求发送给号码字典。号码字典中登记了哪些号码在互联互通联盟中哪些HSvr里注册了相应的账户的相关信息，号码字典接收到所述请求后，根据所述请求中携带的号码簿号码，获取对应电话号码的属性信息，将该属性信息通过所述RSvr回复给所述客户端。所述电话号码的属性信息中，就有该电话号码对应的HCode信息，以指示用户根据该电话号码在相应的HSvr中注册了账户。为了减少存储空间的占用，为了提高检索效率，在号码字典中，在存储相应的HCode信息时，较佳地，使用{一个32bit的DomainID来替代对应的域名}这种方式。这种情况下，返回给客户端的HCode信息都是对应的32bit的DomainID。客户端在显示查询结果时，应显示相应DomainID对应的域名，以便于用户识别和记忆。这时，客户端就要查询本地设置的域描述表。
当客户端根据查询回复信息中相应的DomainID查询本地设置的域描述表时，有可能出现{根据某个DomainID，查找不到对应记录}的情况。这时，所述客户端就会向ICMSvr发送域名查询请求，在所述请求中携带所述DomainID。
关于号码字典的更多描述，参见所述《号码字典》发明专利。
上面说过，一个HSvr中用户数量可能非常庞大，这种情况下，大量的客户端向ICMSvr发送所述是域名查询请求或者DomainID查询请求，对ICMSvr将是一种考验。
这种情况下，可以通过在一个HSvr中设置多个ICMSvr，来分担处理来自各个客户端的访问请求。这种方式比较常见，本发明不再赘述。
本发明从另外一个角度着手，提出一种分布式ICMSvr。该分布式ICMSvr包括至少一个一级互联管理服务器(FLICM，First Level InterConnection Management Server)和若干二级互联管理服务器(SLICM，Second Level InterConnection Management Server)。这里，
EICM是SLICM的下一级模块，SLICM是EICM的上一级模块；
SLICM是FLICM的下一级模块，FLICM是SLICM的上一级模块；
FLICM是RICM的下一级模块，RICM是FLICM的上一级模块。
如图4所示，为四层ICMSys示例图。在该图中，包括一个RICM，两个ICMSvr：ICMSvr-1和ICMSvr-2，六个EICM：EICM-1、EICM-2、EICM-3、EICM-4、EICM-5和EICM-6。其中，
ICMSvr-1包括一个FLICM：FLICM-1，两个SLICM：SLICM-1和SLICM-2；
ICMSvr-2包括一个FLICM：FLICM-2，两个SLICM：SLICM-3和SLICM-4。
FLICM-1和FLICM-2连接到RICM；
SLICM-1和SLICM-2连接到FLICM-1，SLICM-3和SLICM-4连接到FLICM-2；
EICM-1和EICM-2连接到SLICM-1，EICM-3连接到SLICM-2；
EICM-4和EICM-5连接到SLICM-3，EICM-6连接到SLICM-4。
在所述FLICM中，设置如表1所示的域描述表，在该表中保存相关的域名和DomainID的对应关系数据。
在所述SLICM中，也设置如表1所示的域描述表，在该表中保存相关的域名和DomainID的对应关系数据。
所述SLICM连接到相应的FLICM。
FLICM在保存的域名和DomainID的对应关系数据发生变化后，将所述相关变化信息同步到各个SLICM中。
例如，在FLICM中，可以保存各个SLICM的描述信息，例如地址信息。FLICM在保存的域名和DomainID的对应关系数据发生变化后，可以向各个SLICM发送变化通知消息。所述变化通知消息中直接携带相应的变化描述数据，各个SLICM收到所述变化通知消息后，根据所述变化描述数据，更新自己保存的域名和DomainID的对应关系数据。
还例如，FLICM在保存的域名和DomainID的对应关系数据发生变化后，更新最新数据版本号，以及生成数据变化描述。各个SLICM定期或不定期查询所述数据版本号，判断自己保存的域名和DomainID的对应关系数据是否是最新的，如果不是，则获取所述数据变化描述，根据获取的数据变化描述，更新自己保存的域名和DomainID的对应关系数据。
两个模块之间的数据同步是一个成熟技术，因此，这里不再模仿赘述。
FLICM可以向SLICM提供域名查询服务或DomainID查询服务。
FLICM接收到SLICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所述域描述表，获取相应的域名，将相应的查询结果回复给所述SLICM。
FLICM接收到SLICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所述域描述表，获取相应的DomainID，将相应的查询结果回复给所述SLICM。
在SLICM侧，所设置的域描述表的初始状态可以为空，或者，预先用一些常用的DomainID和域名对应关系数据，来初始化所述域描述表。
所述SLICM收到所述FLICM回复的查询结果后，将其保存于本地设置的域描述表中，以备下次使用。
SLICM在需要根据DomainID获取域名时，或者在需要根据域名获取DomainID时，先查找本地设置的域描述表，判断是否能够获取所需结果，如果成功，则直接结束；如果不成功，才向FLICM发送查询请求。
所述FLICM连接到所述RICM。
上面所述的，RICM在保存的域名和DomainID的对应关系数据发生变化后将相关变化信息同步到各个ICMSvr中，进一步是：RICM在保存的域名和DomainID的对应关系数据发生变化后将相关变化信息同步到各个FLICM中。
上面所述的，RICM向ICMSvr提供域名查询服务或DomainID查询服务，进一步是：RICM向FLICM提供域名查询服务或DomainID查询服务。
RICM接收到FLICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所述域描述表，获取相应的域名，将相应的查询结果回复给所述FLICM。
RICM接收到FLICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所述域描述表，获取相应的DomainID，将相应的查询结果回复给所述FLICM。
在FLICM侧，所设置的域描述表的初始状态可以为空，或者，预先用一些常用的DomainID和域名对应关系数据，来初始化所述域描述表。
所述FLICM收到RICM回复的查询结果后，将其保存于本地设置的域描述表中，以备下次使用。
FLICM在需要根据DomainID获取域名时，或者在需要根据域名获取DomainID时，先查找本地设置的域描述表，判断是否能够获取所需结果，如果成功，则直接结束；如果不成功，才向RICM发送查询请求。
上面所述的，ICMSvr向EICM提供域名查询服务或DomainID查询服务，进一步是：SLICM向EICM提供域名查询服务或DomainID查询服务。
SLICM接收到EICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所述域描述表，获取相应的域名，将相应的查询结果回复给所述EICM。
SLICM接收到EICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所述域描述表，获取相应的DomainID，将相应的查询结果回复给所述EICM。
例五、EICM根据DomainID获取域名
参见如下流程：
步骤501、所述EICM在本地获取对应的域名：根据所述DomainID，按照本地设置的域描述表，获取对应的域名；判断是否成功获取到对应的域名，如果是，则结束流程；否则，进入步骤502。
步骤502、所述EICM向SLICM发送域名查询请求，在该请求中携带所述DomainID。
步骤503、所述SLICM在收到所述EICM发送的所述域名查询请求后，在本地获取对应的域名：根据该请求中携带的所述DomainID，按照本地设置的域描述表，获取对应的域名；判断是否成功，如果是，则直接进入步骤512；否则，进入步骤504。
步骤504、所述SLICM向FLICM发送域名查询请求，在该请求中携带所述DomainID。
步骤505、所述FLICM在收到所述SLICM发送的所述域名查询请求后，在本地获取对应的域名：根据该请求中携带的所述DomainID，按照本地设置的域描述表，获取对应的域名，判断是否成功获取到对应的域名，如果是，则直接进入步骤510；否则，进入步骤506。
步骤506、所述FLICM向RICM发送域名查询请求，在该请求中携带所述DomainID。
步骤507、RICM在收到所述FLICM发送的所述域名查询请求后，在本地获取对应的域名：根据该请求中携带的所述DomainID，按照本地设置的域描述表，获取对应的域名。
步骤508、RICM将相应的查询结果回复给所述FLICM。
例如，所述查询回复消息中包括所述DomainID和对应的域名。
步骤509、所述FLICM收到所述查询结果后，保存该查询结果。
例如，将所述DomainID和对应的域名，保存在本地设置的域描述表中。
步骤510、所述FLICM将相应的查询结果回复给所述SLICM。
例如，所述查询回复消息中包括所述DomainID和对应的域名。
步骤511、所述SLICM收到所述查询结果后，保存该查询结果。
例如，将所述DomainID和对应的域名，保存在本地设置的域描述表中。
步骤512、所述SLICM将相应的查询结果回复给所述EICM。
例如，所述查询回复消息中包括所述DomainID和对应的域名。
步骤513、所述EICM收到所述查询结果后，保存该查询结果。
例如，将所述DomainID和对应的域名，保存在本地设置的域描述表中。
如图6所示，为EICM根据DomainID获取域名的流程五示例图。
例六、EICM根据域名获取DomainID
参见如下流程：
步骤601、所述EICM在本地获取对应的DomainID：根据所述域名，按照本地设置的域描述表，获取对应的DomainID；判断是否成功获取到对应的DomainID，如果是，则结束流程；否则，进入步骤602。
步骤602、所述EICM向SLICM发送DomainID查询请求，在该请求中携带所述域名。
步骤603、所述SLICM在收到所述EICM发送的所述DomainID查询请求后，在本地获取对应的DomainID：根据该请求中携带的所述域名，按照本地设置的域描述表，获取对应的DomainID；判断是否成功，如果是，则直接进入步骤612；否则，进入步骤604。
步骤604、所述SLICM向FLICM发送DomainID查询请求，在该请求中携带所述域名。
步骤605、所述FLICM在收到所述SLICM发送的所述DomainID查询请求后，在本地获取对应的DomainID：根据该请求中携带的所述域名，按照本地设置的域描述表，获取对应的DomainID，判断是否成功获取到对应的DomainID，如果是，则直接进入步骤610；否则，进入步骤606。
步骤606、所述FLICM向RICM发送DomainID查询请求，在该请求中携带所述域名。
步骤607、RICM在收到所述FLICM发送的所述DomainID查询请求后，在本地获取对应的DomainID：根据该请求中携带的所述域名，按照本地设置的域描述表，获取对应的DomainID。
步骤608、RICM将相应的查询结果回复给所述FLICM。
例如，所述查询回复消息中包括所述域名和对应的DomainID。
步骤609、所述FLICM收到所述查询结果后，保存该查询结果。
例如，将所述域名和对应的DomainID，保存在本地设置的域描述表中。
步骤610、所述FLICM将相应的查询结果回复给所述SLICM。
例如，所述查询回复消息中包括所述域名和对应的DomainID。
步骤611、所述SLICM收到所述查询结果后，保存该查询结果。
例如，将所述域名和对应的DomainID，保存在本地设置的域描述表中。
步骤612、所述SLICM将相应的查询结果回复给所述EICM。
例如，所述查询回复消息中包括所述域名和对应的DomainID。
步骤613、所述EICM收到所述查询结果后，保存该查询结果。
例如，将所述域名和对应的DomainID，保存在本地设置的域描述表中。
通过所述ICMSys，就使得所述对应关系数据能够在整个网络中各个相应模块内得到轻便(例如，各个模块只需保留能够使用到的对应关系数据即可)、有效、便捷的维护。
本发明提到的互联互通联盟，一般地，是指参与互联互通的各个HSvr及其对应运营商的总称。
一个HSvr可以同时拥有一个定长IBC类的HCode，例如一个32bit的DomainID类HCode和一个不定长IBC类的HCode。通常，所述定长的IBC被用于***内部，而不定长的IBC被用于用户接口部分，可以作为相应HSvr的名称或别名或商标来使用。
本发明所述域名替代使用方法一样可以用于所述的变长IBC的替代使用，或者产品别名的替代使用。所述产品别名可以直接是产品的商标或名称。
特别地，实际当中，一个HSvr不只是{申请并被指配一个域名，以及针对该域名指配一个DomainID}，往往还会为该HSvr赋予一个名称或别名。
例如，米聊的域名为miliao.com，为之指配的DomainID为1。对应的产品名称为米聊。
还例如，易信的域名为yixin.im，为之指配的DomainID为2。对应的产品名称为易信。
还例如，陌陌的域名为immomo.com，为之指配的DomainID为3。对应的产品名称为陌陌。
还例如，QQ的域名为qq.com，为之指配的DomainID为4。对应的产品名称为QQ。
在互联互通环境中，用户在打开好友列表时，应显示好友属于哪一个产品的用户，这种情况下，将相应产品的名称，例如米聊、易信等等，作为好友属性显示出来，将更友好。
上面提到了，通过建立相应域名和对应DomainID的对应关系，然后根据一个域名获取对应DomainID的方法，和根据一个DomainID获取对应域名的方法，以及相应的***。
仿照上述方式，通过建立域名和对应产品名称的对应关系，还可以实现，根据一个域名获取对应产品名称，以及根据一个产品名称获取对应域名，以及相应的***。
同样，仿照上述方式，通过建立产品名称和对应DomainID的对应关系，还可以实现，根据一个产品名称获取对应DomainID，以及根据一个DomainID获取对应产品名称，以及相应的***。
同样，仿照上述方式，通过建立变长IBC和对应DomainID的对应关系，还可以实现，根据一个变长IBC获取对应DomainID，以及根据一个DomainID获取对应变长IBC，以及相应的***。
同样，仿照上述方式，通过建立变长IBC和对应域名的对应关系，还可以实现，根据一个变长IBC获取对应域名，以及根据一个域名获取对应变长IBC，以及相应的***。
实际当中，在上述建立相应域名和对应DomainID的对应关系时，可以直接在该关系中加入产品名称属性，这样，在根据一个域名获取对应DomainID时，进一步获取对应的产品名称；在根据一个DomainID获取对应域名时，也进一步获取对应的产品名称。这样，还可以根据一个产品名称，按照所述对应关系，获取对应的域名和DomainID。
例如，可以在如表1所示的域描述表中加入产品名称字段，从而得到如表3所示的产品描述表：
表3
DomainID 域名 Trademark
1 miliao.com 米聊
2 yixin.im 易信
3 immomo.com 陌陌
4 qq.com QQ
这样，仿照上述方式，就可以通过一个DomainID，或一个域名，或一个产品名称，按照所述对应关系，来获取相应记录的其余信息。
这样，在***内部，在使用DomainID作为HCode，从而提高效率的同时，在用户接口部分，面向用户，显示对应的域名和/或产品名称，这样，就更加有利于用户识别好友地址，以及更加有助于通信地址的传播。
以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之类，所作的任何修改、改进、等同替换等均应包含在本发明的保护范围之内。

Claims (10)

1.一种域名替代使用方法，其特征在于，建立域名和域标识(DomainID)的对应关系；在消息中需要携带域名相关信息的地方替代为“携带对应的DomainID”，或者，在需要存储域名相关信息的地方，替代为“存储对应的DomainID”；所述方法包括以下步骤：
a、根据待输出内容中的DomainID，按照所建立的对应关系，获取对应的域名；
b、向用户侧输出所获取的域名。
2.一种域名替代使用方法，其特征在于，建立域名和DomainID的对应关系；所述方法包括以下步骤：
a、获取用户输入的域名，按照所建立的对应关系，获取对应的DomainID；
b、在消息中需要携带所述域名相关信息的地方替代为“携带所述对应的DomainID”；或者，在需要存储所述域名相关信息的地方，替代为“存储所述对应的DomainID”。
3.一种IP地址获取方法，用于获取一个DomainID对应的IP地址；其特征在于，建立域名和DomainID的对应关系；所述方法包括以下步骤：
a、根据所述DomainID，按照所建立的对应关系，获取对应的域名；
b、按照域名解析过程，得到所获取域名对应的IP地址。
4.根据权利要求3所述的方法，其特征在于，在建立的域名和DomainID的对应关系中，进一步包括所述域名对应的IP地址属性；
所述步骤a进一步是：根据所述DomainID，按照所建立的对应关系，获取对应的对应关系记录，判断该记录的IP地址是否有效，如果有效，则结束IP地址求解过程；否则，才执行步骤b；
在步骤b之后，进一步包括，将所获取的IP地址保存在所述记录中。
5.一种域名相关信息导入方法，其特征在于，建立域名和DomainID的对应关系；所述方法包括以下步骤：
a、根据要导入文件中相应的域名，按照所建立的对应关系，获取对应的DomainID；
b、在向***导入所述域名相关信息时，替代为“导入对应的DomainID”。
6.一种域名相关信息导出方法，其特征在于，建立域名和DomainID的对应关系；所述方法包括以下步骤：
a、根据要导出数据中相应的DomainID，按照所建立的对应关系，获取对应的域名；
b、在向导出文件输出所述DomainID信息时，替代为“输出对应的域名”。
7.一种互联管理***(ICMSys)，其特征在于，包括互联管理服务器(ICMSvr)和互联管理客户端(EICM)；
在ICMSvr中，建立域名和DomainID的对应关系；
ICMSvr向EICM提供域名查询服务或DomainID查询服务；
所述的ICMSvr向EICM提供的所述域名查询服务是指：ICMSvr接收到EICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述EICM；
所述的ICMSvr向EICM提供的所述DomainID查询服务是指：ICMSvr接收到EICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述EICM。
8.根据权利要求7所述的ICMSys，其特征在于，进一步设置根互联管理服务器(RICM)；
在RICM中，建立域名和DomainID的对应关系；
RICM向ICMSvr提供域名查询服务或DomainID查询服务；
所述的RICM向ICMSvr提供的所述域名查询服务是指：RICM接收到ICMSvr发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述ICMSvr；
所述的RICM向ICMSvr提供的所述DomainID查询服务是指：RICM接收到ICMSvr发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述ICMSvr。
9.根据权利要求8所述的ICMSys，其特征在于，所述ICMSvr包括至少一个一级互联管理服务器(FLICM)和若干二级互联管理服务器(SLICM)；其特征在于，
所述的在ICMSvr中建立域名和DomainID的对应关系进一步是：在所述FLICM中建立域名和DomainID的对应关系，在所述SLICM中，也建立域名和DomainID的对应关系；
FLICM向SLICM提供域名查询服务或DomainID查询服务；
所述的FLICM向SLICM提供的域名查询服务是指：FLICM接收到SLICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述SLICM；
所述的FLICM向SLICM提供的DomainID查询服务是指：FLICM接收到SLICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述SLICM；
所述的ICMSvr向EICM提供域名查询服务或DomainID查询服务进一步是：SLICM向EICM提供域名查询服务或DomainID查询服务
所述的SLICM向EICM提供的所述域名查询服务是指：SLICM接收到EICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述EICM；
所述的SLICM向EICM提供的所述DomainID查询服务是指：SLICM接收到EICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述EICM。
所述的RICM向ICMSvr提供域名查询服务或DomainID查询服务进一步是：RICM向FLICM提供域名查询服务或DomainID查询服务；
所述的RICM向FLICM提供的所述域名查询服务是指：RICM接收到FLICM发送的，携带了DomainID的，域名查询请求后，根据该请求中携带的DomainID，按照所建立的对应关系，获取相应的域名，将相应的查询结果回复给所述FLICM；
所述的RICM向FLICM提供的所述DomainID查询服务是指：RICM接收到FLICM发送的，携带了域名的，DomainID查询请求后，根据该请求中携带的域名，按照所建立的对应关系，获取相应的DomainID，将相应的查询结果回复给所述FLICM。
10.根据权利要求8或9所述的ICMSys，其特征在于，对于来自下一级模块的域名查询请求或DomainID查询请求，本级模块在本地执行域名查询服务或DomainID查询服务失败时，向相应的上一级模块发送对应的查询请求；在收到来自所述上一级模块返回的查询结果后，保存该查询结果，并将相应的查询结果回复给所述下一级模块。
CN201610237872.9A 2016-04-17 2016-04-17 域名替代使用方法 Pending CN107306296A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610237872.9A CN107306296A (zh) 2016-04-17 2016-04-17 域名替代使用方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610237872.9A CN107306296A (zh) 2016-04-17 2016-04-17 域名替代使用方法

Publications (1)

Publication Number Publication Date
CN107306296A true CN107306296A (zh) 2017-10-31

Family

ID=60151399

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610237872.9A Pending CN107306296A (zh) 2016-04-17 2016-04-17 域名替代使用方法

Country Status (1)

Country Link
CN (1) CN107306296A (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011150741A1 (zh) * 2010-06-01 2011-12-08 中兴通讯股份有限公司 P2p叠加网络及其数据资源操作方法和新节点加入方法
CN103248726A (zh) * 2013-05-23 2013-08-14 中国科学院计算机网络信息中心 一种多根对等的物联网标识解析方法
CN103685604A (zh) * 2013-12-20 2014-03-26 北京奇虎科技有限公司 一种域名预解析方法及装置
US20150127943A1 (en) * 2012-07-12 2015-05-07 Tencent Technology (Shenzhen) Company Limited Method for implementing cross-domain jump, browser, and domain name server

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011150741A1 (zh) * 2010-06-01 2011-12-08 中兴通讯股份有限公司 P2p叠加网络及其数据资源操作方法和新节点加入方法
US20150127943A1 (en) * 2012-07-12 2015-05-07 Tencent Technology (Shenzhen) Company Limited Method for implementing cross-domain jump, browser, and domain name server
CN103248726A (zh) * 2013-05-23 2013-08-14 中国科学院计算机网络信息中心 一种多根对等的物联网标识解析方法
CN103685604A (zh) * 2013-12-20 2014-03-26 北京奇虎科技有限公司 一种域名预解析方法及装置

Similar Documents

Publication Publication Date Title
CN101552801B (zh) 一种在线浏览和下载用户群组通讯录的方法和***
CN101442558B (zh) 一种为p2sp网络提供索引服务的方法和***
US20060031385A1 (en) Reverse IP method and system
CN104717314B (zh) 一种ip管理方法及***、客户端、服务器
CN105450787B (zh) 网络地址映射方法、装置和***
CN1290376A (zh) 电子邮件处理***
CN101087253A (zh) 保存域名***记录的方法、装置、域名解析方法及装置
CN103957282B (zh) 一种域内终端用户域名解析加速***及其方法
CN103929507A (zh) 一种实现可离线化dns服务的方法及装置
CN106464745B (zh) Dns的服务器、客户端及数据同步方法
CN108881354A (zh) 一种推送信息存储方法、装置、服务器和计算机存储介质
CN104580551A (zh) 一种组网数据中心***及方法
CN106790746A (zh) 一种分布式域名存储和解析方法及***
CN102739812B (zh) 一种推荐好友的方法及装置
CN112738288A (zh) Dns域名解析方法、dns服务器、gslb***及域名解析***
CN101296237A (zh) 资源批量处理***和方法
CN104125310B (zh) 基于半永久地址的消息发送方法
CN104468862A (zh) 一种ip地址绑定的方法、装置及***
US20080189248A1 (en) Multi-site common directory and method for using the multi-site common directory
CN103380607A (zh) Dns客户端地址、rr ttl更新的方法、装置及***
CN107306296A (zh) 域名替代使用方法
CN112968915B (zh) Dns域名服务器攻击的处理方法、处理***、处理装置
CN112104888B (zh) 一种直播用户分组的方法及***
CN104901870B (zh) 一种用于即时通信的用户命名方法
CN100355315C (zh) 一种电话号码到统一资源标识映射的业务实现方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20171031

WD01 Invention patent application deemed withdrawn after publication