CN103368934A - 转向处理方法 - Google Patents
转向处理方法 Download PDFInfo
- Publication number
- CN103368934A CN103368934A CN2013100702809A CN201310070280A CN103368934A CN 103368934 A CN103368934 A CN 103368934A CN 2013100702809 A CN2013100702809 A CN 2013100702809A CN 201310070280 A CN201310070280 A CN 201310070280A CN 103368934 A CN103368934 A CN 103368934A
- Authority
- CN
- China
- Prior art keywords
- message
- hsvr
- addressing
- guid
- turn
- 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
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明公开了一种转向处理方法，根据设置的转向目的，实现基于互联互通的IMN网络中IMS内或IMS间的消息转移，能够帮助用户汇集发送给自己的不同身份的消息，从而极大地方便了IMN网络中的用户。本发明还公开一种HSvr转向处理方法，通过该方法，HSvr处理归属于自己的消息的转向设置。本发明还公开了一种基于软跳线的消息处理方法，通过该方法，在消息的最终寻址目的与原始寻址目的归属于同一个HSvr时，可以实现转向消息的快速交换。
Description
技术领域
本发明涉及互联网通信，更确切地说涉及GUID转向处理方法。
背景技术
一个电信网用户（TNUsr，Telecommunication Network User）可以申请一个与其手机号码相似的影码，即一个特殊的GUID（全球统一身份，Global Unified Identity），从而方便了其自己和他人的使用。
实际当中，一些用户针对不同的生活圈子，例如家人、同学、同事，有不同的GUID，在某些情况下，该用户希望某一GUID对应的账户，能够收到发送给自己的其它GUID的消息；一些用户会觉得自己的手机号码不美观，而自己却拥有一个很漂亮的QQ号码，这时，该用户希望自己的QQ账户能够接收到发送给自己影码的消息。同样，一个拥有QQ靓号的用户希望他人解析自己的影码时，能够解析到这个QQ靓号上。这样，该用户只需用QQ靓号登录到QQ的IMS（即时通信系统，InstantMessenger System）中即可。
所述GUID包括两部分：归属码（HCode，Home Code）和用户码（UCode，User Code）。其中，HCode指示该GUID，也即该GUID对应的互联网用户（IUsr，Internet User）归属于即时通信网络（IMN，Instant Messenger Network）中哪一个IMS，也即归属于哪一个IMS的归属服务器（HSvr，Home Server），UCode用于指示一个HCode下不同的IUsr。
关于GUID的更多信息，参见申请号为201210041577.8或201310037232X的《通讯方法和系统》发明专利；关于影码的更多信息，参见申请号为的201210041677.0或201310049772.X的《影码寻址方法》发明专利；关于身份解析的更多信息，参见申请号为的201210041369.8《身份解析方法和装置》发明专利。为避免浪费技术人员阅读时间，本发明后面对这三个文件中相关内容的引用一般不再重复说明。
发明内容
有鉴于此，本发明提供了一种转向处理方法，通过该方法实现基于互联互通的IMN网络中IMS内或IMS间的消息转移，能够帮助用户汇集发送给自己的不同身份的消息，从而极大地方便了IMN网络中的用户。
一种转向处理方法，其特征在于，所述方法包括以下步骤：
a、执行消息归属化处理流程：判断消息的寻址目的GUID是否归属于自己，如果不是，则将该消息发送给寻址目的GUID归属的HSvr；
b、执行归属消息转向处理流程：判断寻址目的GUID是否设置了转向，如果是，则根据转向目的执行转向操作：将消息的寻址目的GUID设置为转向目的，转步骤a；否则，执行无转向归属消息处理。
在步骤b中，在所述转步骤a之前，进一步执行：
判断源地址是否归属于自己，如果不是，则将该消息发送给该源地址归属的HSvr；
或者，判断该消息是否来自于对端HSvr，如果是，则将该消息发送给所述对端HSvr。
所述消息中进一步设置目标追踪信元，用原始寻址目的初始化目标追踪信元，以目标追踪信元替代原始寻址目的来用于消息的寻址，以保持消息的原始寻址目的不变。
所述消息中进一步包括允许转向次数，所述根据转向目的执行转向操作之前，进一步包括进行转向许可验证，判断验证是否通过，如果不通过，则结束；如果通过，则执行后续操作。
本发明还公开一种HSvr转向处理方法，通过该方法，HSvr处理归属于自己的消息的转向设置。
一种HSvr转向处理方法，其特征在于，所述方法包括以下步骤：
a、判断消息的寻址目的GUID是否归属于自己，如果不是，则将该消息发送给寻址目的GUID归属的HSvr，结束；否则，执行步骤b；
b、判断寻址目的GUID是否设置了转向，如果是，则根据转向目的执行转向操作；否则，执行无转向归属消息处理。
所述根据转向目的执行转向操作进一步是：
将消息的寻址目的GUID设置为转向目的，转步骤a；
或者，则将消息的寻址目的GUID设置为转向目的，判断源地址是否归属于自己，如果是，转步骤a；否则，将该消息发送给该源地址归属的HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断该消息是否来自于对端HSvr，如果不是，转步骤a；否则，将该消息发送给所述对端HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断所述转向目的，即当前消息的寻址目的，是否归属于自己，如果是，则针对该消息重新执行步骤b；否则，进一步执行步骤c：判断源地址是否归属于自己，如果是，则，将该消息转发给当前消息的寻址目的归属的HSvr；否则，将该消息转发给源地址归属的HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断所述转向目的，即当前消息的寻址目的，是否归属于自己，如果是，则针对该消息重新执行步骤b；否则，进一步执行步骤c：判断该消息是否来自于对端HSvr，如果不是，则，将该消息转发给当前消息的寻址目的归属的HSvr；否则，将该消息转发给所述对端HSvr。
在消息码指示为发送消息时，所述执行无转向归属消息处理是：将该消息发送给寻址目的GUID相应的客户端。
或者，在消息码指示为解析请求时，所述执行无转向归属消息处理是：根据寻址目的相应的IP地址，构造回复消息，将解析请求者作为该回复消息的寻址目的，直接执行步骤a；
或者，在消息码指示为解析请求时，所述执行无转向归属消息处理是：根据寻址目的相应的IP地址，构造回复消息，将解析请求者作为该回复消息的寻址目的，判断解析请求者是否归属于自己，如果是，则将该回复消息直接发送给该解析请求者相应的客户端，否则，将该回复消息发送给该解析请求者归属的HSvr。
本发明还公开了一种基于软跳线的消息处理方法，通过该方法，在消息的最终寻址目的与原始寻址目的归属于同一个HSvr时，可以实现转向消息的快速交换。
一种基于软跳线的消息处理方法，其特征在于，所述方法包括以下步骤：
a、判断消息的寻址目的GUID是否归属于自己，如果不是，则将该消息发送给寻址目的GUID归属的HSvr，结束；否则，执行步骤b；
b、判断寻址目的是否与相应的客户端建立了对应关系，如果是，则执行无转向归属消息处理和跳线设置操作；否则，执行步骤c。
c、判断寻址目的是否设置了转向，如果是，则根据转向目的执行转向操作；否则，结束。
所述根据转向目的执行转向操作进一步是：
将消息的寻址目的GUID设置为转向目的，转步骤a；
或者，则将消息的寻址目的GUID设置为转向目的，判断源地址是否归属于自己，如果是，转步骤a；否则，将该消息发送给该源地址归属的HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断消息是否来自于对端HSvr，如果不是，转步骤a；否则，将该消息发送给所述对端HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断所述转向目的，即当前消息的寻址目的，是否归属于自己，如果是，则针对该消息重新执行步骤b；否则，进一步执行步骤c：判断源地址是否归属于自己，如果是，则，将该消息转发给当前消息的寻址目的归属的HSvr；否则，将该消息转发给源地址归属的HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断所述转向目的，即当前消息的寻址目的，是否归属于自己，如果是，则针对该消息重新执行步骤b；否则，进一步执行步骤c：判断消息是否来自于对端HSvr，如果不是，则，将该消息转发给当前消息的寻址目的归属的HSvr；否则，将该消息转发给所述对端HSvr。
所述跳线设置操作是指：
判断是否原始寻址目的与最终寻址目的不同且原始寻址目的归属于自己，如果是，则建立原始寻址目的与最终寻址目的相应的客户端的对应关系，否则，结束。
在消息码指示为发送消息时，所述执行无转向归属消息处理是：将该消息发送给寻址目的GUID相应的客户端；
在消息码指示为解析请求时，所述执行无转向归属消息处理是：根据寻址目的相应的IP地址，构造回复消息，将解析请求者作为该回复消息的寻址目的；执行步骤a。
尤其是本发明通过设置目标追踪信元，以目标追踪信元替代原始寻址目的来用于消息的寻址，从而保持消息的原始寻址目的在寻址过程中不变。这样，接收消息的客户端就可以根据所述原始寻址目的进行个性化处理，例如，按照所述原始寻址目的将消息分别发送到不同的窗口或页面来进行显示，从而达到通过一个客户端实现多个虚拟接收机的效果。并且在所述原始寻址目的为面具时，可以进一步达到通过一个客户端实现多个虚拟电话机的效果。从而为互联网与电信网的整合，提供技术基础。
关于变脸通信和面具的更多信息，参见同时提交的《变脸方法》发明专利。
附图说明
图1所示，为IMN转向处理流程。
图2所示，为消息归属化处理流程。
图3所示，为归属消息转向处理流程。
图4所示，为基于转向许可的归属消息处理流程。
图5所示，为基于跳线的归属消息处理流程。
图6所示，为基于转向许可和跳线的归属消息处理流程。
图7所示，为RPFlow-1的处理流程。
图8所示，为RPFlow-3的处理流程。
图9所示，为RPFlow-4的处理流程。
图10所示，为IMN组网图。
具体实施方式
特别说明，和背景中所提专利一样，为了便于阅读，本发明中所提到的GUID或HCode或UCode的值，在以字符串形式出现时，并不象实际的编程中那样将该值用引号引起来。例如，说UsrA的GUID是sunquan#qq，而不说UsrA的GUID是“sunquan#qq”。
如图10所示，为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）。
为便于理解，后面的描述中，我们以，SP-A是腾讯、SP-B是网易、SP-C是微软，为例。
例如，本发明中，域名类HCode和HSvr的对应关系，以及国际商码（IBC，International Business Code）类HCode和HSvr的对应关系，可以如表1所示：
表1
| HCode | HSvr主机IP地址 | Remark |
| 163 | HSvr-B的主机IP地址 | HSvr-B |
| 163.com | HSvr-B的主机IP地址 | HSvr-B |
| 352 | HSvr-C的主机IP地址 | HSvr-C |
| 99 | HSvr-A的主机IP地址 | HSvr-A |
| Hotmail.com | HSvr-C的主机IP地址 | HSvr-C |
| live.com | HSvr-C的主机IP地址 | HSvr-C |
| MSN | HSvr-C的主机IP地址 | HSvr-C |
| HSvr-A的主机IP地址 | HSvr-A | |
| qq.com | HSvr-A的主机IP地址 | HSvr-A |
| WY | HSvr-B的主机IP地址 | HSvr-B |
| yeah.net | HSvr-B的主机IP地址 | HSvr-B |
HSvr根据一个IUsr的HCode，按照所述HCode和HSvr的对应关系确定该IUsr归属的HSvr。本发明里，一个IUsr的HCode是指该IUsr的GUID对应的HCode。
关于归属二元组（H2T，Home Two-Tuple）与HSvr的对应关系参见《影码寻址方法》发明专利，例如，可以如该专利中表1所示。
统一约定各个HSvr面向其它HSvr用于建立SS连接的TCP服务器端口号，例如，约定统一的端口号为1868。
关于GUID对应的客户端与HSvr如何进行信息交互，以及两个HSvr之间如何进行信息交互，例如，如何将一个消息发送给一个HCode归属的HSvr，以及如何将一个消息发送给一个GUID，也即如何将一个消息发送给一个GUID相应的客户端，等等，更多信息可以参见《通信方法和系统》发明专利，《影码寻址方法》发明专利，以及《身份解析方法和装置》发明专利。本发明不转摘。
有两种典型的转向需求：用户甲希望对自己的GUID设置转向（Redirect），使自己的GUID指向另外一个GUID，即转向目的GUID（简称RdGUID），从而使他人发送给自己的消息，能够由用户乙来接收；或者使他人解析自己的GUID时，能够解析到用户乙，等等转向需求。如表1所示的转向信息表，登记了用户的转向需求：
表2
| GUID | Redirect | Remark |
| UsrB的GUID | zhangliao163.com | UsrB转向zhangliao163.com |
| UsrY的GUID | liubei#352 | UsrY转向liubei#352 |
登记用户转向需求的方式有很多，例如，可以在在线用户信息表中增加Redirect字段来保存一个GUID的转向信息。
表3
| GUID | Redirect | IP地址 | Port |
| UsrB的GUID | zhangliao163.com | 0 | 0 |
| UsrY的GUID | liubei#352 | 0 | 0 |
| zhangliao163.com | null | zhangliao163.com的IP地址 | 相应端口号 |
在表3中，IP地址和Port用于标识IUsr相应的客户端。因为UsrB和UsrY设置转向，不需要登录，相应的IP地址和Port为0。zhangliao163.com的转向目的为空值null，即没有设置转向，因此，在线信息表中保存了在zhangliao163.com登录时获取的相应客户端的IP地址和端口号。
也可以在账户信息表中增加Redirect字段来保存一个GUID的转向信息，如表4所示：
表4
| GUID | Password | Redirect | Remark |
| UsrB的GUID | ******** | zhangliao163.com | UsrB的帐户记录 |
| UsrY的GUID | ******** | liubei#352 | UsrY的帐户记录 |
实际当中，可以通过如表4所示的帐户信息表登记IUsr的转向需求，并据该帐户信息表初始化如表3所示的在线用户信息表。这样，在发送消息时，只需要检索在线用户信息表即可。
关于帐户信息表或在线用户信息表，更多的信息，参见《通讯方法和系统》发明专利，这里不再赘述。
针对上述登记的用户的转向需求，本发明提出了消息转向处理方法。
《通信方法和系统》发明专利中，如果不考虑转向需求，例如在《通信方法和系统》发明专利中，HSvr在收到一个请求消息时，执行无转向消息处理：判断该消息的寻址目的GUID是否归属于自己，如果是，将该消息发送给寻址目的GUID相应的客户端；否则，将该消息发送给寻址目的GUID归属的HSvr，由所述寻址目的GUID归属的HSvr将收到的该消息发送给所述寻址目的GUID相应的客户端。
其中，对于一个请求消息来说，寻址目的为消息的目的用户，源地址为消息的源用户，即请求者；对于一个回复消息来说，寻址目的为该回复消息的源用户，也即对应请求消息的源用户，源地址为该回复消息的目的用户，也即对应请求消息的目的用户。这样约定，可以方便回复消息的构造。具体可参见《通信方法和系统》发明专利中UsrA向UsrB发送消息内容为“坚决支持丞相讨伐乱贼刘备”的过程。
特别说明，与背景技术所提三个发明不同的是，在本发明中，为了便于技术人员理解本发明的流程，对于回复消息，寻址目的也用该回复消息的目的用户，该目的用户实际是对应的请求消息的源用户，即请求消息的源地址。也即：对于一个请求消息的回复消息来说，所述回复消息的寻址目的，是该回复消息的目的用户，也即，为对应请求消息的源用户；所述回复消息的源地址，是该回复消息的源用户，也即，为对应请求消息的目的用户。
如果考虑转向需求，可以在所述将该消息发送给寻址目的GUID相应的客户端之前先判断针对该寻址目的GUID是否设置了转向，如果没有，才执行将该消息发送给寻址目的GUID相应的客户端的操作，否则，执行转向处理流程（RPFlow，Redirection Processing Flow）。
本发明称寻址目的归属于一个HSvr的消息为该HSvr的归属消息。
实际当中，由于转向目的也有可能设置了转向情况，因此，转向处理过程在整个IMN网络中将是一个递归的过程。例如，该过程可以如下：
步骤1101、针对对一个消息执行消息归属化处理操作：判断消息的寻址目的GUID是否归属于自己，如果不是，则将该消息发送给寻址目的GUID归属的HSvr。
步骤1102、执行归属消息转向处理操作：判断寻址目的GUID是否设置了转向，如果是，则根据转向目的执行转向操作：将消息的寻址目的GUID设置为转向目的，转步骤1101；否则，执行无转向归属消息处理。
参见图1所示的IMN转向处理流程。
这里，步骤1101保证了步骤1102所处理的消息是相应HSvr的归属消息，以便获得该消息的转向设置信息。
当步骤1101中，HSvr在判断消息的寻址目的GUID不归属于自己时，由于要将该消息发送给寻址目的GUID归属的HSvr，因此，这种情况下，在步骤1102中，执行归属消息转向处理流程的HSvr将不再是步骤1101中的HSvr，而是所述寻址目的GUID归属的HSvr，这种情况下，在转步骤1101后，在该步骤中执行消息归属化处理流程的HSvr就是所述寻址目的GUID归属的HSvr。
为了让技术人员便于实施本发明，下面就各个HSvr在整个IMN转向处理流程中各自所执行的处理流程或操作进行阐述。
参见图2所示的HSvr消息归属化处理流程：
首先，在步骤1201、判断该消息的寻址目的GUID是否归属于自己，如果不是，则执行步骤1202；否则，进入归属消息转向处理流程。
步骤1202、将该消息发送给寻址目的GUID归属的HSvr。这样，该寻址目的GUID归属的HSvr收到该消息后就可以执行消息归属化处理流程，或直接执行归属消息转向处理流程。
参见图3所示的HSvr归属消息转向处理流程：
首先，在步骤1301、判断寻址目的GUID是否设置了转向，如果没有，则执行步骤1302、否则，进入RPFlow流程。
步骤1302、执行无转向归属消息处理。
在步骤1302中，当所述消息为一个发送请求消息时，例如，发送一个短信息，或者是发送一个解析请求回复消息，则所述无转向归属消息处理是指：将该消息发送给寻址目的GUID相应的客户端。
本发明提供如下五种RPFlow供技术人员选择：
RPFlow-1：
步骤1001、将消息的寻址目的GUID设置为RdGUID。
步骤1002、判断源地址是否归属于自己，如果是，则，进入消息归属化处理流程，否则，执行步骤1003。
步骤1003、将该消息发送给该源地址归属的HSvr。这样，该源地址归属的HSvr收到该消息后就可以执行消息归属化处理流程。
参见图7所示，为RPFlow-1的处理流程。
当然，在步骤1002中，HSvr在判断源地址归属于自己时，也可以将该消息发送给源地址相应的客户端，源地址相应的客户端接收到返回的消息时，可以将该消息重新发送给自己归属的HSvr，由自己归属的HSvr重新执行上述消息归属化处理流程。
RPFlow-2：
步骤2001、将消息的寻址目的GUID设置为RdGUID。
步骤2002、判断消息是否来自于对端HSvr，如果不是，则，进入消息归属化处理流程，否则，执行步骤2003。
步骤2003、将该消息发送给所述对端HSvr。这样，所述对端HSvr收到该消息后就可以执行消息归属化处理流程。
RPFlow-2流程图类似RPFlow-1，不再提供。
参见RPFlow-1，如果消息的源地址不是面具，则RPFlow-2和RPFlow-1等价。
对于接收到对端HSvr的消息，可以进一步建立该消息与所述对端HSvr的对应关系，例如，针对所述对端HSvr建立消息队列，将接收自该HSvr的消息放入该消息队列，这样，在步骤2002中，处理来自于对端HSvr的消息时，可以直接执行步骤2003所述的将该消息发送给所述对端HSvr的操作。由于一个HSvr可能与多个对端HSvr进行消息交互，因此，这种情况下，该HSvr可能需要建立多个消息队列。
RPFlow-3：
步骤3001、将消息的寻址目的GUID设置为RdGUID；进入消息归属化处理流程。
见图8所示，为RPFlow-3的处理流程。
RPFlow-4：
步骤4001、将消息的寻址目的GUID设置为RdGUID。
步骤4002、判断RdGUID是否归属于自己，如果是，则，进入归属消息转向处理流程，否则，执行步骤4003。
步骤4003、判断源地址是否归属于自己，如果是，则，执行步骤4004，否则，执行步骤4005。
步骤4004、将该消息转发给RdGUID归属的HSvr。这样，该RdGUID归属的HSvr收到该消息后就可以执行消息归属化处理流程，或直接执行归属消息转向处理流程。
步骤4005、将该消息转发给源地址归属的HSvr。这样，该源地址归属的HSvr收到该消息后就可以执行消息归属化处理流程。
见图9所示，为RPFlow-4的处理流程。
RPFlow-5：
步骤5001、将消息的寻址目的GUID设置为RdGUID。
步骤5002、判断RdGUID是否归属于自己，如果是，则，进入归属消息转向处理流程，否则，执行步骤5003。
步骤5003、判断消息是否来自于对端HSvr，如果不是，则，执行步骤5004，否则，执行步骤5005。
步骤5004、将该消息转发给RdGUID归属的HSvr。这样，所述RdGUID归属的HSvr收到该消息后就可以执行消息归属化处理流程，或直接执行归属消息转向处理流程。
步骤5005、将该消息转发给所述对端HSvr。这样，所述对端HSvr收到该消息后就可以执行消息归属化处理流程。
RPFlow-5流程图类似RPFlow-4，不再提供。
参见RPFlow-4，如果消息的源地址不是面具，则RPFlow-5和RPFlow-4等价。
关于变脸通信和面具的更多信息，参见同时提交的《变脸方法》发明专利。
需要说明的是，如果HSvr将来自客户端的消息放入接收客户端消息队列（MsgQueueFromClient），将来自对端HSvr的消息放入对端HSvr消息队列（MsgQueueFromPeerHSvr），那么，在处理MsgQueueFromClient中的消息转向时，RPFlow-2和RPFlow-5等效于RPFlow-3。
为了避免转向死循环，还可以在消息中插入一个转向次数（TTR，Times To Redirect）消息元来限制允许最多转向次数，当HSvr确定针对一个寻址目的设置了转向时，判断TTR值是否大于0，如果是，则进入RPFlow；否则，结束。相应地，各个RPFlow中，还进一步将TTR值减1。当TTR值不大于0时，对于一个请求消息来说，也可以直接向消息的源地址返回消息发送失败信息。
这样，在进入RPFlow之前，先进行转向许可验证（RPV，RedirectionPermit Verification）：判断TTR是否大于0，如果TTR大于0，则进入RPFlow；否则，结束。
这样，归属消息转向处理流程进一步是如图4所示的基于转向许可的归属消息处理流程。在基于转向许可的归属消息处理流程中：
首先，在步骤1401、判断寻址目的GUID是否设置了转向，如果没有，则执行步骤1402、否则，执行步骤1403。
步骤1402、执行无转向归属消息处理，结束。
步骤1403、判断TTR是否大于0，如果TTR大于0，则进入RPFlow，否则，结束。
在步骤1402中，当所述消息为一个发送请求消息时，例如，发送一个短信息，或者是发送一个解析请求回复消息，则所述无转向归属消息处理是指：将该消息发送给寻址目的GUID相应的客户端。
相应地，在各个RPFlow中，在将消息的寻址目的设置为RdGUID时，还进一步将消息的TTR值减1。
对于一个请求消息来说，在步骤1403中，在所述结束之前，还可以进一步向源地址返回消息发送失败的回复消息。所述回复消息中MsgCode值设置为对应的回复消息码，例如ShortMsg的回复消息码为ResShortMsg；在MsgContent中写入表示“转向次数过多”的原因值。所述回复消息的寻址目的为该请求消息的源地址，所述回复消息的源地址为该请求消息的寻址目的。
为了避免回复消息再回复的情况发生，在处理回复消息时，如果发生异常，例如RPV失败，一般地，不再针对该回复消息再产生回复消息的回复消息，即，发生异常或者回复消息送达最终的接收者之后，不再对该回复消息进行再回复。
实际当中，至少有如下两种情形，用户希望知道收到的消息的原始目的用户，即原始寻址目的：
情形一、zhugeliang拥有一个形似移动电话的影码，例如86*139*23568901，形似固定电话的影码，例如86*755*82881689，一个QQ号码123987#99，zhugeliang将86*139*23568901和86*755*82881689转向目的都设置为123987#99，以便发送给86*139*23568901和86*755*82881689的消息都被123987#99所接收。按照上述转向处理方式，123987#99所收到的消息的寻址目的GUID都是123987#99，因此，zhugeliang就无法区分消息的源用户是通过自己的哪个GUID给自己发送消息的，这样，zhugeliang在回复消息时，就不知道该选择自己的哪个号码作为源地址进行回复。
情形二、在三网融合的情况下，有时，人们希望将他人发送给自己的短信息转移到电视机上，比如，一家人都将自己的GUID转向到电视机上，这样，在除夕之夜，一家人看《春晚》时，就可以直接从电视上看到这些短信息。但是，最终接收短信息的是电视机对应的用户，例如，是一个形似固定电话号码的影码，该影码用户无法区分短信息是发送给这个家庭的哪一个成员的。
本发明为了让消息的最终接收者知道最初的寻址目的GUID，实际当中，可以在消息中增加一个目标追踪信元（TTIE，Target TrackingInformation Element），替代目的用户来用于消息的寻址。TTIE的初始值为消息的目的用户，在发生转向时，用RdGUID更新TTIE的值，而不再用RdGUID更新消息的目的用户，从而保持了原始寻址目的的值不变。
这样，最终接收消息的客户端就可以根据接收到的消息的原始寻址目的进行个性化提示。
为了便于描述本发明，这里定义如下消息格式一，但不用于限定本发明：
TTIE：目标追踪信元，用于消息的寻址，初始值为ToUsr，在转向发生时发生变化；
ToUsr：用于指定消息的目的用户，是消息的原始寻址目的；
FromUsr：用于指定消息的源用户，即源地址；
TTR：表示允许的转向次数；
MsgCode：消息码：例如，ShortMsg，表示这是一个短消息；
MsgContent：消息内容。
一般地，通过MsgCode来区分一个消息是请求消息（RequestMsg，Request Message）还是回复消息（ResponseMsg，Response Message）。实际当中，可以用奇数表示请求消息码，用偶数表示回复消息码。例如，请求消息码ShortMsg = 31，对应的回复消息码ResShortMsg= 32；请求消息码GetIP = 21，对应的回复消息码ResGetIP =22。
作为一种特殊情况，在消息弹回发生时，在寻址时，不根据TTIE进行寻址，而是：在消息的源用户不归属于自己时，将该消息发送给该源用户归属的HSvr，即弹回源HSvr，例如RPFlow-1的步骤1003，以及RPFlow-4的步骤4005；或者，在消息来自于对端HSvr时，将该消息发送给所述对端HSvr，即弹回对端HSvr，例如RPFlow-2的步骤2003，以及RPFlow-5的步骤5005。本发明称消息的源用户归属的HSvr为该消息的源HSvr。
实际当中，所述消息弹回也可以是将消息弹回到IUsr。例如，在步骤1002中，在判断源地址归属于自己时，不进入消息归属化处理流程，而是将该消息发送给源地址对应的客户端。
基于上述消息格式一：
对于消息归属化处理流程，HSvr提供的相应操作为：
消息处理（MsgProcessing，Message Processing）：判断消息的TTIE是否归属于自己，如果是，则执行下面提到的HomeMsgProcessing操作；否则，将该消息发送给TTIE归属的HSvr。
对于基于转向许可的归属消息处理流程，HSvr提供的相应操作为：
归属消息处理（HomeMsgProcessing，Home Message Processing）：判断消息的TTIE是否设置了转向，如果没有，则，执行无转向归属消息处理。如果设置了转向，则执行RPV操作，即判断TTR是否大于0，如果TTR大于0，则执行下面提到的RP操作。如果TTR不大于0，则结束。
这里，当所述消息为发送一个短信息，或者是发送一个解析请求回复消息，则所述无转向归属消息处理是指：将该消息发送给TTIE相应的客户端。
对于一个RequestMsg，在HomeMsgProcessing中，在所述结束之前，还可以进一步产生回复消息，将所述回复消息的MsgCode值设置为对应的回复消息码，例如ShortMsg的回复消息码为ResShortMsg；在MsgContent中写入表示“转向次数过多”的原因值；将回复消息的TTIE和ToUsr设置为相应请求消息的FromUsr值，将回复消息的FromUsr设置为相应请求消息的ToUsr值，或将回复消息的FromUsr设置为相应请求消息的TTIE值。发送该回复消息。
实际当中，将回复消息的FromUsr设置为所述请求消息的TTIE值时，收到回复消息的请求者可能无法辨别回复消息的来源。另外，如果进一步考虑用户的隐私保护，也有必要对TTIE值进行隐藏。因此，较佳地，将回复消息FromUsr值设置为相应请求消息的ToUsr值，而不是TTIE值，这样，有利于隐藏所述请求消息的ToUsr相应的转向信息。
后面提到的回复消息，以将回复消息的FromUsr设置为相应请求消息的ToUsr值为例。
关于回复消息的发送，一般有两种方式：
方式一、无视转向设置发送：判断消息的TTIE是否归属于自己，如果是，则将该消息发送给TTIE相应的客户端；否则，将该消息发送给TTIE归属的HSvr，由TTIE归属的HSvr将该消息发送给TTIE相应的客户端。
虽然，对于回复消息来说，一般地，不需要考虑目的用户，也即回复消息的TTIE，设置转向的情况，但是，在变脸通信的应用当中，回复消息的原始寻址目的ToUsr，也即相应请求消息的源用户，可能是一个面具，这种情况下，一般地，应将回复消息发送给该面具后面的IUsr，即该面具的属主。因此，在考虑到变脸通信的情况下，在发送回复消息时，进一步考虑消息的TTIE的转向设置。这样，回复消息的发送流程将和上述请求消息的发送流程一致，即基于转向设置发送。
方式二、基于转向设置发送：重新设置TTR初始值，例如设置为5，而后直接执行MsgProcessing操作。
关于变脸通信和面具的更多信息，参见同时提交的《变脸方法》发明专利。
后面在发送回复消息时，将以基于转向设置发送的方式为例来进一步说明。
针对消息的转向操作（RP，Redirection Processing）有五种：
针对RPFlow-1，对应的RP为：
RP1：用转向目的RdGUID更新消息的TTIE，将消息的TTR值减1；判断消息的FromUsr是否归属于自己，如果是，则执行MsgProcessing操作；否则，将消息弹回源HSvr，即，将该消息发送给FromUsr归属的HSvr。
针对RPFlow-2，对应的RP为：
RP2：用转向目的RdGUID更新消息的TTIE，将消息的TTR值减1；判断消息是否来自于对端HSvr，如果不是，则执行MsgProcessing操作；否则，将消息弹回对端HSvr，即，将该消息发送给所述对端HSvr。
针对RPFlow-3，对应的RP为：
RP3：用转向目的RdGUID更新消息的TTIE，将消息的TTR值减1；执行MsgProcessing操作。
针对RPFlow-4，对应的RP为：
RP4：用转向目的RdGUID更新消息的TTIE，将消息的TTR值减1。判断RdGUID是否归属于自己，如果是，则执行HomeMsgProcessing。如果RdGUID不归属于自己，则判断消息的FromUsr是否归属于自己，如果是，则，将该消息发送给RdGUID归属的HSvr，否则，将该消息弹回源HSvr，即，将该消息发送给FromUsr归属的HSvr。
针对RPFlow-5，对应的RP为：
RP5：用转向目的RdGUID更新消息的TTIE，将消息的TTR值减1。判断RdGUID是否归属于自己，如果是，则执行HomeMsgProcessing。如果RdGUID不归属于自己，则判断消息是否来自于对端HSvr，如果不是，则，将该消息发送给RdGUID归属的HSvr，否则，将该消息弹回对端HSvr，即，将该消息发送给所述对端HSvr。
RP2便于消息跟踪，有利于系统测试。RP1、RP2、RP4、RP5等，会导致消息折返多，降低消息传送的效率。RP3的效率最高，并且较好地保护了消息的目的用户的转向设置信息等隐私。因此，本发明向技术人员特别推荐采用RP3。
对于请求消息弹回源HSvr的情况，也可以采用回复消息处理方式，即，将消息码更改为相应的回复消息码，例如ShortMsg的回复消息码为ResShortMsg，将回复消息的TTIE和ToUsr设置为所述请求消息的FromUsr，将回复消息的FromUsr设置为相应请求消息的ToUsr，而后在回复消息的MsgContent中插入表示发生转向的原因值，或者专门增加一个用于指示处理结果的消息元Result，通过Result指示发生转向的原因，而后将该回复消息发送给相应的源HSvr。所述源HSvr在收到回复消息后，如果判断消息的原因值指示“发生转向”，则可以根据该回复消息重新构造相应的请求消息。可以看到，这个过程没有直接将消息弹回源HSvr的处理机制效率高。
当然，也可以将回复消息码与Result组合成一个新的回复消息码，所述新的回复消息码在指示一个消息是某一回复消息的同时，还指示了相应的原因值，例如，回复消息码A对应三个原因值，回复消息码B对应两个原因值，消息码和原有值组合后，成为5个回复消息码，分别对应A的三个原因值和B的两个原因值。
同样对于请求消息弹回对端HSvr的情况，也可以采用回复消息处理方式，即，将消息码更改为相应的回复消息码，例如ShortMsg的回复消息码为ResShortMsg，将回复消息的TTIE和ToUsr设置为所述请求消息的FromUsr，将回复消息的FromUsr设置为相应请求消息的ToUsr，而后在回复消息的MsgContent中插入表示发生转向的原因值，或者专门增加一个用于指示处理结果的消息元Result，通过Result指示发生转向的原因，而后将该回复消息发送给所述对端HSvr。所述对端HSvr在收到回复消息后，如果判断消息的原因值指示“发生转向”，则可以根据该回复消息重新构造相应的请求消息。可以看到，这个过程没有直接将消息弹回对端HSvr的处理机制效率高。
本发明提出的消息弹回机制在于提供一种快速简约的转向处理方法，让收到该弹回消息的HSvr可以直接将该消息作为一个新的请求消息（只是TTIE发生了变化，以及TTR减1）来处理。
为帮助理解本发明，下面以RP采用RP3为例，举详细例子进行说明。
例一：UsrA的GUID为sunquan#QQ，UsrX的GUID为zhouyu#99。UsrX设置了转向，对应的RdGUID没有再设置转向。UsrA向UsrX发送消息的处理过程如下：
UsrA向HSvr-A发送消息如下：
TTIE = zhouyu#99，
ToUsr = zhouyu#99，
FromUsr = sunquan#QQ，
TTR = 5，表示最多允许5次转向，
MsgCode = ShortMsg，
MsgContent = “请注意关、张二部动向”
这里，TTIE值由UsrA客户端直接填写。
对于来自客户端的请求消息，HSvr-A执行MsgProcessing操作：
根据TTIE中的HCode值99，按照所述HCode与HSvr的对应关系，确定zhouyu#99归属于自己，于是，HSvr-A执行HomeMsgProcessing操作：
判断针对TTIE是否设置了转向，由于UsrX设置了的转向，因此，执行RPV操作，由于TTR大于0，因此执行RP3操作：
以UsrX的转向目的是chengpu#99为例：
用RdGUID值chengpu#99更新消息的TTIE，将消息的TTR值减1，得到如下消息：
TTIE = chengpu#99，
ToUsr = zhouyu#99，
FromUsr = sunquan#QQ，
TTR = 4，表示最多允许4次转向，
MsgCode = ShortMsg，
MsgContent = “请注意关、张二部动向”
HSvr-A执行MsgProcessing操作：
根据TTIE中的HCode值99，按照所述HCode与HSvr的对应关系，确定chengpu#99归属于自己，于是，HSvr-A执行HomeMsgProcessing操作：
由于chengpu#99没有设置转向，因此，直接将该消息发送给chengpu#99。
实际当中，在将所述消息发送给chengpu#99之后，还可以进一步构造一个回复消息，例如，将回复消息的MsgCode值设置为对应的回复消息码，例如ShortMsg的回复消息码为ResShortMsg，在回复消息的MsgContent中写入表示“消息发送成功”的原因值，将回复消息的TTIE和ToUsr设置为所述请求消息的FromUsr值sunquan#QQ，将回复消息的FromUsr设置为所述请求消息的ToUsr值zhouyu#99，将回复消息的TTR设置为5，而后执行MsgProcessing操作：
由于TTIE值sunquan#QQ归属于自己，因此，HSvr-A执行HomeMsgProcessing操作：
由于sunquan#QQ没有设置转向，因此，直接将该回复消息发送给sunquan#QQ。这样HSvr-A向UsrA发送的回复消息如下：
TTIE = sunquan#QQ，
ToUsr = sunquan#QQ，
FromUsr = zhouyu#99，
TTR = 5，表示最多允许5次转向，
MsgCode = ResShortMsg，
MsgContent = 表示“消息发送成功”原因值
如果不考虑隐私保护，或者就是要将请求消息的真实接收者信息回复给该请求消息的请求者，那么，可以将回复消息的FromUsr设置为所述请求消息的TTIE值chengpu#99。
由于回复消息的发送与请求消息的发送流程一致，因此，后面叙述中不再就回复消息的发送进行特别地阐述。
上面执行RP3操作时，如果以UsrX的转向目的是chengpu#msn为例，则：
用RdGUID值chengpu#msn更新消息的TTIE，将消息的TTR值减1，得到如下消息：
TTIE = chengpu#msn，
ToUsr = zhouyu#99，
FromUsr = sunquan#QQ，
TTR = 4，表示最多允许4次转向，
MsgCode = ShortMsg，
MsgContent = “请注意关、张二部动向”
HSvr-A执行MsgProcessing操作：
根据TTIE中的HCode值msn，按照所述HCode与HSvr的对应关系，确定chengpu#msn归属于HSvr-C，于是，HSvr-A将该消息发送给HSvr-C。
HSvr-C收到所述消息后，执行MsgProcessing操作：
判断chengpu#msn归属于自己，于是，执行HomeMsgProcessing操作：
由于chengpu#msn没有设置转向，因此，直接将该消息发送给chengpu#msn。
这里，HSvr-C收到所述消息后，也可以直接执行HomeMsgProcessing操作。
例二：UsrA的GUID为sunquan#QQ，UsrY的GUID为guanyunchang163.com，并且UsrY设置了转向，对应的RdGUID没有再设置转向。该例子中，HSvr-A按照如表3所示的在线用户信息表建立了客户端与GUID的对应关系。UsrA向UsrY发送消息的处理过程如下：
UsrA向HSvr-A发送消息如下：
TTIE = null，
ToUsr = guanyunchang163.com，
FromUsr = null，
TTR = 5，表示最多允许5次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
这里，TTIE值由HSvr-A初始化。
收到UsrA的消息后，HSvr-A先根据UsrA的客户端，即该客户端的IP和端口号获取对应的GUID，将FromUsr设置为该GUID。接收客户端的消息时，获取客户端的IP地址和端口号是成熟技术，本发明不再就此赘述。将TTIE值初始化为ToUsr。得到如下消息：
TTIE = guanyunchang163.com，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 5，表示最多允许5次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
FromUsr由HSvr-A填写，可以防止欺诈。
HSvr-A在对所述消息进行完善后，执行MsgProcessing操作：
根据TTIE中的HCode值163.com，按照所述HCode与HSvr的对应关系，确定guanyunchang163.com归属于HSvr-B，于是，HSvr-A将该消息发送给HSvr-B。
HSvr-B收到所述消息后，执行MsgProcessing操作（说明：HSvr-B收到所述消息后，也可以直接执行HomeMsgProcessing操作，但这样做，系统扩展性不好！）：
判断guanyunchang163.com归属于自己，于是，执行HomeMsgProcessing操作：
判断针对TTIE是否设置了转向，由于UsrY设置了转向，因此，执行RPV操作，由于TTR大于0，因此执行RP3操作：
以UsrY的转向目的是liubei#352为例：
用RdGUID值liubei#352更新消息的TTIE，将消息的TTR值减1，得到如下消息：
TTIE = liubei#352，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 4，表示最多允许4次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
执行MsgProcessing操作：
根据TTIE中的HCode值352，按照所述HCode与HSvr的对应关系，确定liubei#352归属于HSvr-C，于是，HSvr-B将该消息发送给HSvr-C。
HSvr-C收到所述消息后，执行MsgProcessing操作：
判断liubei#352归属于自己，于是，执行HomeMsgProcessing操作：
由于liubei#352没有设置转向，因此，直接将该消息发送给liubei#352。
再将所述消息发送给liubei#352之后，还可以进一步构造一个回复消息，例如，将回复消息的MsgCode值设置为对应的回复消息码，例如ShortMsg的回复消息码为ResShortMsg，在回复消息的MsgContent中写入表示“消息发送成功”的原因值，将回复消息的TTIE和ToUsr设置为所述请求消息的FromUsr值sunquan#QQ，将回复消息的FromUsr设置为所述请求消息的ToUsr值guanyunchang163.com，将回复消息的TTR设置为5，而后执行MsgProcessing操作。
上面执行RP3操作时，如果以UsrY的转向目的是liubei#qq为例，则：
用RdGUID值liubei#qq更新消息的TTIE，将消息的TTR值减1，得到如下消息：
TTIE = liubei#qq，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 4，表示最多允许4次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
执行MsgProcessing操作：
根据TTIE中的HCode值qq，按照所述HCode与HSvr的对应关系，确定liubei#qq归属于HSvr-A，于是，HSvr-B将该消息发送给HSvr-A。
HSvr-A收到所述消息后，执行MsgProcessing操作：
判断liubei#qq归属于自己，于是，执行HomeMsgProcessing操作：
由于liubei#qq没有设置转向，因此，直接将该消息发送给liubei#qq。
上面执行RP3操作时，如果以UsrY的转向目的是liubei#163.com为例，则：
用RdGUID值liubei#163.com更新消息的TTIE，将消息的TTR值减1，得到如下消息：
TTIE = liubei#163.com，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 4，表示最多允许4次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
执行MsgProcessing操作：
根据TTIE中的HCode值163.com，确定liubei#163.com归属于自己，于是，HSvr-B执行HomeMsgProcessing操作：
由于liubei#163.com没有设置转向，因此，直接将该消息发送给liubei#163.com。
实际当中，由于解析请求消息不必直接传送到最终的解析目标，即没有设置转向的TTIE，相应的客户端，而仅需传送到最终解析目标所归属的HSvr，因此，在处理解析请求时，上述无转向归属消息处理是指：根据最终用户客户端的IP地址产生回复消息，并发送该回复消息。也即：
所述步骤1402进一步是：
判断消息的MsgCode是ShortMsg或ResGetIP时，将该消息发送给TTIE相应的客户端。判断消息的MsgCode是GetIP时，构造回复消息，该回复消息中：对应的MsgCode设置为与解析请求消息码GetIP对应的回复消息码ResGetIP，对应的TTIE和ToUsr设置为所述解析请求消息的FromUsr值，对应FromUsr设置为所述解析请求消息的ToUsr值，对应的MsgContent被设置为TTIE相应的客户端的IP地址，对应的TTR值被初始化，例如，设置为5。而后进入MsgProcessing流程。
也即HomeMsgProcessing可以进一步是：判断消息的TTIE是否设置了转向，如果没有，则，在消息的MsgCode是ShortMsg或ResGetIP时，执行HomeMsgProcessingForSending操作；在消息的MsgCode是GetIP时，执行HomeMsgProcessingForGetIP操作。如果设置了转向，则执行RPV操作，即判断TTR是否大于0，如果TTR大于0，则执行RP操作，否则，结束。
HomeMsgProcessingForSending操作是：将该消息发送给TTIE相应的客户端。
HomeMsgProcessingForGetIP操作是：构造回复消息，该回复消息中：对应的MsgCode为与GetIP对应的回复消息码ResGetIP，对应的TTIE和ToUsr为所述解析请求消息的FromUsr，对应FromUsr为所述解析请求消息的ToUsr，对应的MsgContent被设置为TTIE相应的客户端的IP地址，对应的TTR值被初始化，例如，设置为5；而后进入MsgProcessing流程。
当然，实际当中，在构造解析回复消息时，还可以在所述回复消息中插入一个表示“解析成功标志”的原因值，例如通过增加一个单独的信元来表示所述原因值，或将该原因值插入到消息的MsgContent中。
例三：UsrA的GUID为sunquan#QQ，UsrY的GUID为guanyunchang163.com，并且UsrY设置了转向，对应的RdGUID为liubei#352，liubei#352没有再设置转向。该例子中，HSvr-A按照如表3所示的在线用户信息表建立了客户端与GUID的对应关系。UsrA请求解析UsrY的处理过程如下：
UsrA向HSvr-A发送消息如下：
TTIE = null，
ToUsr = guanyunchang163.com，
FromUsr = null，
TTR = 5，表示最多允许5次转向，
MsgCode = GetIP，
MsgContent = null
收到UsrA的消息后，HSvr-A先根据UsrA的客户端，即该客户端的IP和端口号获取对应的GUID，将FromUsr设置为该GUID。接收客户端的消息时，获取客户端的IP地址和端口号是成熟技术，本发明不再就此赘述。将TTIE值初始化为ToUsr。得到如下消息：
TTIE = guanyunchang163.com，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 5，表示最多允许5次转向，
MsgCode = GetIP，
MsgContent = null
HSvr-A在对所述消息进行完善后，执行MsgProcessing操作：
根据TTIE中的HCode值163.com，按照所述HCode与HSvr的对应关系，确定guanyunchang163.com归属于HSvr-B，于是，HSvr-A将该消息发送给HSvr-B。
HSvr-B收到所述消息后，执行MsgProcessing操作：
判断guanyunchang163.com归属于自己，于是，执行HomeMsgProcessing操作：
判断针对TTIE是否设置了转向，由于UsrY设置了转向，因此，执行RPV操作，由于TTR大于0，因此执行RP3操作：
用RdGUID值liubei#352更新消息的TTIE，将消息的TTR值减1，得到如下消息：
TTIE = liubei#352，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 4，表示最多允许4次转向，
MsgCode = GetIP，
MsgContent = null
执行MsgProcessing操作：
根据TTIE中的HCode值352，按照所述HCode与HSvr的对应关系，确定liubei#352归属于HSvr-C，于是，HSvr-B将该消息发送给HSvr-C。
HSvr-C收到所述消息后，执行MsgProcessing操作：
判断liubei#352归属于自己，于是，执行HomeMsgProcessing操作：
由于liubei#352没有设置转向，并且判断MsgCode为GetIP，因此，执行HomeMsgProcessingForGetIP操作：
构造回复消息，将回复消息的MsgCode值设置为对应的回复消息码，例如GetIP的回复消息码为ResGetIP，在回复消息的MsgContent中写入liubei#352的IP地址，将回复消息的TTIE和ToUsr设置为所述请求消息的FromUsr值sunquan#QQ，将回复消息的FromUsr设置为所述请求消息的ToUsr值guanyunchang163.com，将回复消息的TTR设置为5。所述回复消息如下：
TTIE = sunquan#QQ，
ToUsr = sunquan#QQ，
FromUsr = guanyunchang163.com，
TTR = 5，表示最多允许5次转向，
MsgCode = ResGetIP，
MsgContent = liubei#352的IP地址
这里，liubei#352预先登记了自己的IP地址。如果liubei#352没有登记自己的IP地址，则将0作为其IP地址填写在回复消息的MsgContent中，这样，回复消息的最终接收者可以根据MsgContent中对应的IP地址为0，判断解析失败。
HSvr-C在构造了上述回复消息后，执行MsgProcessing操作：
由于TTIE值sunquan#QQ归属于HSvr-A，因此，HSvr-C将该回复消息发送给HSvr-A。
HSvr-A收到来自HSvr-C的回复消息后，执行MsgProcessing操作：
由于TTIE值sunquan#QQ归属于自己，因此，HSvr-A执行HomeMsgProcessing操作：
由于sunquan#QQ没有设置转向，且消息的MsgCode为ResGetIP，因此，HSvr-A执行HomeMsgProcessingForSending操作：将该回复消息发送给sunquan#QQ。
这里，如果不考虑回复消息转向的情况，则HSvr-A收到来自HSvr-C的回复消息后，可以直接执行HomeMsgProcessing操作。
根据上述转向处理方法，对于请求消息或回复消息，都可以根据转向设置信息，将消息发送给最终的目的用户所归属的HSvr，从而实现了人们期望的消息转向需求。
本发明还提出一种软跳线方法，用于实现快速转向处理，从而提高HSvr的交换效率。
所述软跳线方法是指，在ToUsr与最终接收消息的GUID归属于同一个HSvr时，直接将消息的ToUsr跳接到所述最终接收消息的GUID相应的客户端，而不管中间究竟转向了多少次，以及如何转向。具体地讲，就是在步骤1402中，进一步判断ToUsr是否归属于自己，如果是，则建立ToUsr与TTIE相应的客户端的对应关系，也即跳线关系。相应地，在步骤1401之前，进一步判断TTIE是否与相应的客户端建立了对应关系，如果是，就直接将消息发送给该客户端，而不再考虑TTIE是否设置了转向。
在设置跳线之前，一般地，进一步判断ToUsr和TTIE是否相同，如果相同，则不设置所述跳线，否则，才执行设置所述跳线的操作。
在采用软跳线方法时，当一个GUID登出时，HSvr进一步查找跳接到该GUID相应的客户端的其它GUID，删除所述其它GUID与该客户端的对应关系。
实际当中，可以通过在线用户信息表来保存上述的跳线关系。如表3-6所示：
表3-6
| GUID | Redirect | IP地址 | Port |
| UsrB的GUID | zhangliao163.com | zhangliao163.com的IP地址 | 相应端口号 |
| UsrY的GUID | liubei#352 | 0 | 0 |
| zhangliao163.com | null | zhangliao163.com的IP地址 | 相应端口号 |
在根据表3-6中，UsrY相应的IP地址为0，说明UsrY尚没有与相应的客户端建立对应关系。
在根据表3-6中，UsrB直接跳接到zhangliao163.com相应的客户端，该客户端由UsrB的在线记录中相应的IP地址和端口号所标识，也即，UsrB的在线记录和zhangliao163.com在线记录具有相同的IP地址和端口号。这样，在将消息发送给UsrB时，可以直接将该消息发送给UsrB的在线记录中相应的客户端，即zhangliao163.com的客户端，而不需要再去查找转向目的zhangliao163.com。这样，就节省了一次检索操作。
相应地，在执行无转向归属消息处理时，例如在步骤1302中，或在执行无转向归属消息处理之后，还进一步执行跳线设置操作：判断是否原始寻址目的与最终寻址目的不同且原始寻址目的归属于自己，如果是，则建立原始寻址目的与最终寻址目的相应的客户端的对应关系。
根据表3-6，所述归属消息处理流程进一步是如图5所示的基于跳线的归属消息处理流程。在基于跳线的归属消息处理流程中：
首先，在步骤1501、判断TTIE是否与相应的客户端建立了对应关系，例如，其在线记录的IP地址是否有效，即是一个非0值，如果是，则执行步骤1502，否则，执行步骤1505。
步骤1502、执行无转向归属消息处理。
在步骤1502中，当所述消息为一个发送请求消息时，例如，该消息的MsgCode为ShortMsg或ResGetIP时，则所述无转向归属消息处理是指：将该消息发送给TTIE相应的客户端。当所述消息为一个解析请求消息时，例如，该消息的MsgCode为GetIP，则所述无转向归属消息处理是指：构造回复消息，该回复消息中：对应的MsgCode设置为与解析请求消息码GetIP对应的回复消息码ResGetIP，对应的TTIE和ToUsr设置为所述解析请求消息的FromUsr值，对应FromUsr设置为所述解析请求消息的ToUsr值，对应的MsgContent被设置为TTIE相应的客户端的IP地址。而后进入MsgProcessing流程。
步骤1503、判断是否ToUsr和TTIE不同且ToUsr归属于自己，如果是，则执行步骤1504，否则，即ToUsr和TTIE相同，或者ToUsr不归属于自己，则结束。
步骤1504、建立ToUsr与TTIE相应的客户端的对应关系，结束。
步骤1505、判断TTIE是否设置了转向，如果是，则进入RPFlow；否则，结束。
根据表3-6，所述基于转向许可的归属消息处理流程进一步是如图6所示的基于转向许可和跳线的归属消息处理流程。在基于转向许可和跳线的归属消息处理流程中：
首先，在步骤1601、判断TTIE是否与相应的客户端建立了对应关系，例如，其在线记录的IP地址是否有效，即是一个非0值，如果是，则执行步骤1602，否则，执行步骤1605。
步骤1602、执行无转向归属消息处理。
在步骤1602中，当所述消息为一个发送请求消息时，例如，该消息的MsgCode为ShortMsg或ResGetIP时，则所述无转向归属消息处理是指：将该消息发送给TTIE相应的客户端。当所述消息为一个解析请求消息时，例如，该消息的MsgCode为GetIP，则所述无转向归属消息处理是指：构造回复消息，该回复消息中：对应的MsgCode设置为与解析请求消息码GetIP对应的回复消息码ResGetIP，对应的TTIE和ToUsr设置为所述解析请求消息的FromUsr值，对应FromUsr设置为所述解析请求消息的ToUsr值，对应的MsgContent被设置为TTIE相应的客户端的IP地址，对应的TTR值被初始化，例如，设置为5。而后进入MsgProcessing流程。
步骤1603、判断是否ToUsr和TTIE不同且ToUsr归属于自己，如果是，则执行步骤1604，否则，即ToUsr和TTIE相同，或者ToUsr不归属于自己，则结束。
步骤1604、建立ToUsr与TTIE相应的客户端的对应关系，结束。
步骤1605、判断TTIE是否设置了转向，如果是，则执行步骤1606，否则，结束。
步骤1606、判断TTR是否大于0，如果TTR大于0，则进入RPFlow，否则，结束。
在步骤1505中，或步骤1605中，如果TTIE没有设置转向，又没有登记相应的客户端，即TTIE也没有登入，因此，结束流程。当然，在TTIE没有登入时，TTIE归属的HSvr还可以进一步保存所述消息，并在以后TTIE登入时，发送给TTIE相应的客户端。
上述软跳线方法这在转向次数过多时，尤其是，先转向到其它HSvr的IUsr，而后再转回本HSvr的某个IUsr的情况，所述软跳线方法还节省了消息兜转的消耗。例如，如果liubei#352设置的转向目的RdGUID为liuxie#163.com，并且liuxie#163.com没有再设置转向，则UsrY可以跳接到liuxie#163.com相应的客户端。如表3-7所示：
表3-7
| GUID | Redirect | IP地址 | Port |
| UsrB的GUID | zhangliao163.com | zhangliao163.com的IP地址 | 相应端口号 |
| UsrY的GUID | liubei#352 | liuxie163.com的IP地址 | 相应端口号 |
| zhangliao163.com | null | zhangliao163.com的IP地址 | 相应端口号 |
| liuxie163.com | null | liuxie163.com的IP地址 | 相应端口号 |
在表3-7中，UsrY的在线记录中，相应的客户端由liuxie163.com 的IP地址和端口号标识，即UsrY直接指向或跳接到liuxie163.com的客户端。
例四：UsrA的GUID为sunquan#QQ，UsrY的GUID为guanyunchang163.com，UsrY设置的RdGUID为liubei#352，liubei#352设置的RdGUID为liuxie163.com。liuxie163.com没有再设置转向。该例子中，HSvr-A按照如表3所示的在线用户信息表建立了客户端与GUID的对应关系。
在UsrY没有设置跳线的情况下，例如，第一次UsrA向UsrY发送消息“诚邀关将军来吴共商国是”，相应的处理过程如下：
UsrA向HSvr-A发送消息如下：
TTIE = null，
ToUsr = guanyunchang163.com，
FromUsr = null，
TTR = 5，表示最多允许5次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
这里，TTIE值由HSvr-A初始化。
收到UsrA的消息后，HSvr-A先根据UsrA的客户端，即该客户端的IP和端口号获取对应的GUID，将FromUsr设置为该GUID。将TTIE值初始化为ToUsr。得到如下消息：
TTIE = guanyunchang163.com，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 5，表示最多允许5次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
FromUsr由HSvr-A填写，可以防止欺诈。
HSvr-A在对所述消息进行完善后，执行MsgProcessing操作：
根据TTIE中的HCode值163.com，按照所述HCode与HSvr的对应关系，确定guanyunchang163.com归属于HSvr-B，于是，HSvr-A将该消息发送给HSvr-B。
HSvr-B收到所述消息后，执行MsgProcessing操作：
判断guanyunchang163.com归属于自己，于是，执行HomeMsgProcessing操作：
判断guanyunchang163.com的在线记录中相应的IP地址是否为0，由于是第一次UsrA向UsrY发送消息，因此，相应的IP地址为0，于是：
判断针对TTIE是否设置了转向，由于UsrY设置了转向，因此，执行RPV操作，由于TTR大于0，因此执行RP3操作：
用RdGUID值liubei#352更新消息的TTIE，将消息的TTR值减1，得到如下消息：
TTIE = liubei#352，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 4，表示最多允许4次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
执行MsgProcessing操作：
根据TTIE中的HCode值352，按照所述HCode与HSvr的对应关系，确定liubei#352归属于HSvr-C，于是，HSvr-B将该消息发送给HSvr-C。
HSvr-C收到所述消息后，执行MsgProcessing操作：
判断liubei#352归属于自己，于是，执行HomeMsgProcessing操作：
判断liubei#352的在线记录中相应的IP地址是否为0，由于liubei#352设置转向到liuxie163.com，没有登入到HSvr-C，因此，相应的IP地址为0，于是：
判断针对TTIE是否设置了转向，由于liubei#352设置了转向，因此，执行RPV操作，由于TTR大于0，因此执行RP3操作：
用RdGUID值liuxie163.com更新消息的TTIE，将消息的TTR值减1，得到如下消息：
TTIE = liuxie163.com，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 3，表示最多允许3次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
执行MsgProcessing操作：
根据TTIE中的HCode值163.com，按照所述HCode与HSvr的对应关系，确定liuxie163.com归属于HSvr-B，于是，HSvr-C将该消息发送给HSvr-B。
HSvr-B收到所述消息后，执行MsgProcessing操作：
判断liuxie163.com归属于自己，于是，执行HomeMsgProcessing操作：
由于liuxie163.com的在线记录中相应的IP地址不为0，即，liuxie163.com登入了HSvr-B，因此，直接将该消息发送给liuxie#163.com相应的客户端。而后判断是否ToUsr和TTIE不同且ToUsr归属于自己，由于guanyunchang163.com与liuxie#163.com不同，且guanyunchang163.com 归属于自己，因此，建立guanyunchang163.com与liuxie#163.com相应的客户端的对应关系，也即，将guanyunchang163.com在线记录中相应的IP地址和端口号字段设置为liuxie#163.com相应的客户端的IP地址和端口号。
在UsrY设置了跳线的情况下，例如，第二次UsrA向UsrY发送消息“诚邀关将军来吴共商国是”，相应的处理过程如下：
UsrA向HSvr-A发送消息如下：
TTIE = null，
ToUsr = guanyunchang163.com，
FromUsr = null，
TTR = 5，表示最多允许5次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
这里，TTIE值由HSvr-A初始化。
收到UsrA的消息后，HSvr-A先根据UsrA的客户端，即该客户端的IP和端口号获取对应的GUID，将FromUsr设置为该GUID。将TTIE值初始化为ToUsr。得到如下消息：
TTIE = guanyunchang163.com，
ToUsr = guanyunchang163.com，
FromUsr = sunquan#QQ，
TTR = 5，表示最多允许5次转向，
MsgCode = ShortMsg，
MsgContent = “诚邀关将军来吴共商国是”
FromUsr由HSvr-A填写，可以防止欺诈。
HSvr-A在对所述消息进行完善后，执行MsgProcessing操作：
根据TTIE中的HCode值163.com，按照所述HCode与HSvr的对应关系，确定guanyunchang163.com归属于HSvr-B，于是，HSvr-A将该消息发送给HSvr-B。
HSvr-B收到所述消息后，执行MsgProcessing操作：
判断guanyunchang163.com归属于自己，于是，执行HomeMsgProcessing操作：
由于TTIE对应的IP地址不为0，因此，直接将该消息发送给相应的客户端，即liuxie#163.com的客户端。而后判断是否ToUsr和TTIE不同且ToUsr归属于自己，由于ToUsr和TTIE都是guanyunchang163.com，因此，直接结束。
由上可见，在消息的最终目的GUID与其原始目的GUID归属于同一个HSvr且不相同时，通过软跳线方法将可以大大节省消息传送的时间。
同样，软跳线方法也可以用于GUID解析。在考虑GUID解析时，所述步骤1602进一步是：
判断消息的MsgCode是ShortMsg或ResGetIP时，将该消息发送给TTIE相应的客户端。判断消息的MsgCode是GetIP时，构造回复消息，该回复消息中：对应的MsgCode设置为与解析请求消息码GetIP对应的回复消息码ResGetIP，对应的TTIE和ToUsr设置为所述解析请求消息的FromUsr值，对应FromUsr设置为所述解析请求消息的ToUsr值，对应的MsgContent被设置为TTIE相应的客户端的IP地址，对应的TTR值被初始化，例如，设置为5。而后执行MsgProcessing流程和步骤1603。参见上述解析请求消息转向处理过程，这里不再举详细例。
实际当中，一个用户针对自己的GUID设置的转向目的也可以是一个URL。这里，将作为转向目的URL称为RdURL。如表2-1所示的转向信息表。
表2-1
| GUID | Redirect | Remark |
| UsrB的GUID | 转向目的URL | UsrB的转向记录 |
| UsrY的GUID | 转向目的URL | UsrY的转向记录 |
所述URL可以直接是一个IP地址。
当一个GUID的转向目的为一个RdURL时，该GUID归属的HSvr在收到解析该GUID的解析请求消息时,则直接将该RdURL回复给解析请求者。
当一个GUID的转向目的为一个RdURL时，该GUID归属的HSvr在收到发送给该GUID的消息时,可以作异常处理。
即，在步骤1403之前进一步判断寻址目的GUID设置的转向目的是否为一个RdURL，如果不是，则执行步骤1403，否则，进入转向RdURL处理流程：
判断消息的MsgCode是否是GetIP，如果不是，则作异常处理，或直接结束。如果消息的MsgCode是GetIP，则：构造回复消息，该回复消息中：对应的MsgCode为与GetIP对应的回复消息码ResGetIP，对应的TTIE和ToUsr为所述解析请求消息的FromUsr，对应FromUsr为所述解析请求消息的ToUsr，对应的MsgContent被设置为TTIE相应的RdURL，对应的TTR值被初始化，例如，设置为5；而后进入MsgProcessing流程。
参见前述GetIP消息以及ResGetIP消息的处理流程，这里不再举详细例。
以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之类，所作的任何修改、改进、等同替换等均应包含在本发明的保护范围之内。
Claims (10)
1.一种转向处理方法，其特征在于，所述方法包括以下步骤：
a、执行消息归属化处理流程：判断消息的寻址目的GUID是否归属于自己，如果不是，则将该消息发送给寻址目的GUID归属的HSvr；
b、执行归属消息转向处理流程：判断寻址目的GUID是否设置了转向，如果是，则根据转向目的执行转向操作：将消息的寻址目的GUID设置为转向目的，转步骤a；否则，执行无转向归属消息处理。
2.根据权利要求1所述的方法，其特征在于，在步骤b中，在所述转步骤a之前，进一步执行：
判断源地址是否归属于自己，如果不是，则将该消息发送给该源地址归属的HSvr；
或者，判断该消息是否来自于对端HSvr，如果是，则将该消息发送给所述对端HSvr。
3.根据权利要求1所述的方法，其特征在于，所述消息中进一步设置目标追踪信元，用原始寻址目的初始化目标追踪信元，以目标追踪信元替代原始寻址目的来用于消息的寻址，以保持消息的原始寻址目的不变。
4.根据权利要求1所述的方法，其特征在于，所述消息中进一步包括允许转向次数，所述根据转向目的执行转向操作之前，进一步包括进行转向许可验证，判断验证是否通过，如果不通过，则结束；如果通过，则执行后续操作。
5.一种HSvr转向处理方法，其特征在于，所述方法包括以下步骤：
a、判断消息的寻址目的GUID是否归属于自己，如果不是，则将该消息发送给寻址目的GUID归属的HSvr，结束；否则，执行步骤b；
b、判断寻址目的GUID是否设置了转向，如果是，则根据转向目的执行转向操作；否则，执行无转向归属消息处理。
6.根据权利要求5所述的方法，其特征在于，所述根据转向目的执行转向操作进一步是：
将消息的寻址目的GUID设置为转向目的，转步骤a；
或者，则将消息的寻址目的GUID设置为转向目的，判断源地址是否归属于自己，如果是，转步骤a；否则，将该消息发送给该源地址归属的HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断该消息是否来自于对端HSvr，如果不是，转步骤a；否则，将该消息发送给所述对端HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断所述转向目的，即当前消息的寻址目的，是否归属于自己，如果是，则针对该消息重新执行步骤b；否则，进一步执行步骤c：判断源地址是否归属于自己，如果是，则，将该消息转发给当前消息的寻址目的归属的HSvr；否则，将该消息转发给源地址归属的HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断所述转向目的，即当前消息的寻址目的，是否归属于自己，如果是，则针对该消息重新执行步骤b；否则，进一步执行步骤c：判断该消息是否来自于对端HSvr，如果不是，则，将该消息转发给当前消息的寻址目的归属的HSvr；否则，将该消息转发给所述对端HSvr。
7.根据权利要求5所述的方法，其特征在于，
在消息码指示为发送消息时，所述执行无转向归属消息处理是：将该消息发送给寻址目的GUID相应的客户端。
或者，在消息码指示为解析请求时，所述执行无转向归属消息处理是：根据寻址目的相应的IP地址，构造回复消息，将解析请求者作为该回复消息的寻址目的，直接执行步骤a；
或者，在消息码指示为解析请求时，所述执行无转向归属消息处理是：根据寻址目的相应的IP地址，构造回复消息，将解析请求者作为该回复消息的寻址目的，判断解析请求者是否归属于自己，如果是，则将该回复消息直接发送给该解析请求者相应的客户端，否则，将该回复消息发送给该解析请求者归属的HSvr。
8.一种基于软跳线的消息处理方法，其特征在于，所述方法包括以下步骤：
a、判断消息的寻址目的GUID是否归属于自己，如果不是，则将该消息发送给寻址目的GUID归属的HSvr，结束；否则，执行步骤b；
b、判断寻址目的是否与相应的客户端建立了对应关系，如果是，则执行无转向归属消息处理和跳线设置操作；否则，执行步骤c。
c、判断寻址目的是否设置了转向，如果是，则根据转向目的执行转向操作；否则，结束。
9.根据权利要求8所述的方法，其特征在于，所述根据转向目的执行转向操作进一步是：
将消息的寻址目的GUID设置为转向目的，转步骤a；
或者，则将消息的寻址目的GUID设置为转向目的，判断源地址是否归属于自己，如果是，转步骤a；否则，将该消息发送给该源地址归属的HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断消息是否来自于对端HSvr，如果不是，转步骤a；否则，将该消息发送给所述对端HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断所述转向目的，即当前消息的寻址目的，是否归属于自己，如果是，则针对该消息重新执行步骤b；否则，进一步执行步骤c：判断源地址是否归属于自己，如果是，则，将该消息转发给当前消息的寻址目的归属的HSvr；否则，将该消息转发给源地址归属的HSvr；
或者，则将消息的寻址目的GUID设置为转向目的，判断所述转向目的，即当前消息的寻址目的，是否归属于自己，如果是，则针对该消息重新执行步骤b；否则，进一步执行步骤c：判断消息是否来自于对端HSvr，如果不是，则，将该消息转发给当前消息的寻址目的归属的HSvr；否则，将该消息转发给所述对端HSvr。
10.根据权利要求8所述的方法，其特征在于，
在消息码指示为发送消息时，所述执行无转向归属消息处理是：将该消息发送给寻址目的GUID相应的客户端；
在消息码指示为解析请求时，所述执行无转向归属消息处理是：根据寻址目的相应的IP地址，构造回复消息，将解析请求者作为该回复消息的寻址目的；执行步骤a。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2013100702809A CN103368934A (zh) | 2012-04-09 | 2013-03-06 | 转向处理方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210100091.7 | 2012-04-09 | ||
| CN201210100091 | 2012-04-09 | ||
| CN2013100702809A CN103368934A (zh) | 2012-04-09 | 2013-03-06 | 转向处理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN103368934A true CN103368934A (zh) | 2013-10-23 |
Family
ID=49369479
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2013100702809A Pending CN103368934A (zh) | 2012-04-09 | 2013-03-06 | 转向处理方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103368934A (zh) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1386001A (zh) * | 2002-07-05 | 2002-12-18 | 王正伟 | 一种移动电话呼叫智能转移的实现方法 |
| US6567929B1 (en) * | 1999-07-13 | 2003-05-20 | At&T Corp. | Network-based service for recipient-initiated automatic repair of IP multicast sessions |
| CN1946104A (zh) * | 2006-03-01 | 2007-04-11 | 华为技术有限公司 | 一卡多号业务的实现方法 |
| AU2006207853B2 (en) * | 1999-10-22 | 2007-11-08 | Nomadix, Inc. | Systems and methods for redirecting users attempting to access a network site |
| CN101080083A (zh) * | 2006-05-26 | 2007-11-28 | 华为技术有限公司 | 一种呼叫转向方法及系统 |
| CN101431697A (zh) * | 2007-11-05 | 2009-05-13 | 华为技术有限公司 | 一种呼叫自动转移方法、系统和业务控制点 |
| CN102333105A (zh) * | 2010-07-14 | 2012-01-25 | 华为技术有限公司 | 业务通信的方法、系统、推送客户端和用户设备 |
-
2013
- 2013-03-06 CN CN2013100702809A patent/CN103368934A/zh active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6567929B1 (en) * | 1999-07-13 | 2003-05-20 | At&T Corp. | Network-based service for recipient-initiated automatic repair of IP multicast sessions |
| AU2006207853B2 (en) * | 1999-10-22 | 2007-11-08 | Nomadix, Inc. | Systems and methods for redirecting users attempting to access a network site |
| CN1386001A (zh) * | 2002-07-05 | 2002-12-18 | 王正伟 | 一种移动电话呼叫智能转移的实现方法 |
| CN1946104A (zh) * | 2006-03-01 | 2007-04-11 | 华为技术有限公司 | 一卡多号业务的实现方法 |
| CN101080083A (zh) * | 2006-05-26 | 2007-11-28 | 华为技术有限公司 | 一种呼叫转向方法及系统 |
| CN101431697A (zh) * | 2007-11-05 | 2009-05-13 | 华为技术有限公司 | 一种呼叫自动转移方法、系统和业务控制点 |
| CN102333105A (zh) * | 2010-07-14 | 2012-01-25 | 华为技术有限公司 | 业务通信的方法、系统、推送客户端和用户设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9083680B2 (en) | Systems, methods, and computer readable media for application-level authentication of messages in a telecommunications network | |
| JP5548256B2 (ja) | 電子メール通信のための方法及び装置 | |
| CN101582886B (zh) | 基于动态口令进行身份认证的方法和系统 | |
| US8055558B2 (en) | Method and system for authentication via communication terminal using short message | |
| CN101355532B (zh) | 电子邮件业务实现方法和邮件服务器 | |
| US9712515B2 (en) | Verifying an identity of a message sender | |
| CN101072103B (zh) | 一种多账号登录即时通讯软件的方法及系统 | |
| CN101771532B (zh) | 实现资源共享的方法、装置及系统 | |
| US20090241175A1 (en) | Methods and systems for user authentication | |
| CN102244845B (zh) | 访问im业务系统存储服务器的方法和im业务系统 | |
| CN105610810A (zh) | 一种数据处理方法、客户端和服务器 | |
| WO2006013403A2 (en) | Method and system for instant message using http url technology | |
| CN101582762A (zh) | 基于动态口令进行身份认证的方法和系统 | |
| CN102843357A (zh) | 访问网络的方法、应用服务器及系统 | |
| CN105323308A (zh) | 一种基于地理位置信息的社群互联方法和系统 | |
| CN102484649A (zh) | 定位多租户网络中的预订数据 | |
| CN110519240A (zh) | 一种单点登录方法、装置及系统 | |
| CN103023933A (zh) | 一种登录信息集成处理系统及方法 | |
| WO2011015017A1 (zh) | 一种防止短信诈骗的方法及系统 | |
| CN104660409A (zh) | 集群环境下系统登录的方法和认证服务器集群 | |
| CN101925020A (zh) | 一种电子邮箱地址与移动电话号码绑定应用的方法和系统 | |
| CN106169995B (zh) | 一种直播网站手机绑定短信验证防刷方法及系统 | |
| CN102143131A (zh) | 用户注销方法及认证服务器 | |
| CN102026115A (zh) | 电子名片信息交换方法及其系统 | |
| US8189466B2 (en) | Messaging interchange system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C53 | Correction of patent of invention or patent application | ||
| CB02 | Change of applicant information |
Address after: Wuhou District Shaoling road Chengdu city Sichuan province 610000 No. 29 2-2-3 Li Huaijiang Applicant after: Wang Zhengwei Address before: 610000 Sichuan city in Chengdu province Wuhou Temple Street No. 87 (empty Jiashuyuan) 1 Building 1 unit 3 Applicant before: Wang Zhengwei |
|
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20131023 |
|
| WD01 | Invention patent application deemed withdrawn after publication |