CN101369987A - 一种建立通信通道的方法及装置 - Google Patents
一种建立通信通道的方法及装置 Download PDFInfo
- Publication number
- CN101369987A CN101369987A CNA2007101357783A CN200710135778A CN101369987A CN 101369987 A CN101369987 A CN 101369987A CN A2007101357783 A CNA2007101357783 A CN A2007101357783A CN 200710135778 A CN200710135778 A CN 200710135778A CN 101369987 A CN101369987 A CN 101369987A
- Authority
- CN
- China
- Prior art keywords
- communication
- terminal
- strategies
- strategy
- request message
- 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
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种建立通信通道的方法和装置,所述方法包括:第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;第二终端从收到的协商请求消息中获取所述第一通信策略集;以及按预置规则将所述第一通信策略集生成第二通信策略集;第二终端按照所述第二通信策略集中的通信策略并行执行握手;若握手成功,则第一终端与第二终端建立通信通道。这样一来,通过实施本发明,解决了现有技术在执行多种通信策略建立通信通道时,需要服务器多次转发协商请求消息而导致服务器负载增加,进而造成服务器性能下降,影响服务器性能的问题。
Description
技术领域
本发明涉及计算机通信领域,特别是涉及一种建立通信通道的方法及装置。
背景技术
目前,基于P2P(Peer-to-Peer,点对点)的网络通信已经在众多的领域中得到应用,例如即时通讯、点对点文件传输、点对点音视频播放、以及语音视频会议等。
为了实现P2P通信,现有技术提供了多种建立P2P通道的策略,如基于TCP(Transmission Control Protocol,传输控制协议)的P2P通道、基于UDP(User Data Protocol,用户数据报协议)的P2P通道以及基于UPNP(UniversalPlug and Play,通用即插即用)的通信通道等。但是,由于不同的通信策略是为了适应不同的应用程序及网络环境,因此,当位于网络中的两台主机需要进行P2P通信时,在不清楚对方网络环境的情况下,往往需要尝试多种通信策略。
为便于理解,首先对本说明书中可能出现的几个概念进行解释:
本说明书所述“协商”一般是指主叫方通过服务器向被叫方转发请求消息的过程,另外,该过程还可以包括被叫方通过服务器向主叫方转发应答消息;本说明书所述“握手”一般是指主叫方按指定的通信方式直接向被叫方发送请求消息,以及接收被叫方应答消息的过程。
下面,参见图1,以即时通讯系统为例说明现有技术中终端A与终端B建立通信通道的过程,在该例中,终端A首先尝试与终端B建立基于TCP的通信通道,若连接失败,则尝试建立基于UDP的通信通道,若连接仍失败,则再尝试其它方式的通信通道,其具体过程是:
首先,终端A向服务器S发送协商请求消息,该消息包括终端A的IP地址、应用程序对应的端口号以及指定的本次的通信方式,即TCP。
服务器S将收到的协商请求消息转发至终端B;终端B从收到的协商请求消息中获取A的IP地址、端口号,然后开始执与终端A的“握手”:终端B向A发送连接请求消息,该消息包括源IP地址和源端口号,以及目标IP地址和目标端口号,所述源IP地址和源端口即终端B的IP地址和端口号,所述目标IP地址和目标端口即终端A的IP地址和端口号,若终端B在指定的时间期限内在所述源端口收到终端A的应答,则“握手”成功,双方建立P2P通道,否则第一次握手失败。若失败,终端B开始尝试另一种通信策略,即建立UDP通道:首先,终端B通过服务器S向终端A转发协商请求消息,该消息包括终端B自身的IP地址,端口号以及指定的通信方式UDP;终端A根据该协商请求消息中终端B的IP地址、端口号向终端B执行握手,若握手成功,则说明终端A和终端B之间能够进行UDP通信,可以建立通信通道,否则终端A通过服务器S向终端B转发新的协商请求消息,双方尝试下一种通信策略。重复上述过程,直到双方执行了所有的通信策略。
在上述建立通信通道的过程中,每次按一种通信策略握手失败后,才会执行后继的通信策略,同时在执行后继的通信策略之前,主叫方都需要将该后继通信策略对应的端口号、IP地址和指定的通信方式作为协商请求消息通过服务器转发至被叫方。由于在建立通信通道的过程中往往需要尝试执行多种通信策略,而每执行一次通信策略都需消耗一定的时间,同时要服务器转发相应的协商请求消息,这样一来,大大增加了建立通信通道所耗时间以及服务器的负载,特别是诸如即时通讯这样的系统中,由于同时存在大量的通讯终端,因此,为建立通信通道而需要服务器转发的协商请求消息也急剧增加,不但给服务器造成了沉重的负担,而且还有可能导致系统运行的不稳定,影响正常的数据通信。
发明内容
本发明的目的在于解决现有技术在建立通信通道的过程中,当通信双方执行多种通信策略时,需要服务器多次转发协商请求消息而导致的服务器负载增加、甚至运行的不稳定,以及建立通信通道消耗大量时间的问题。
为解决上述问题,本发明公开了一种建立通信通道的方法,所述方法包括:
第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二终端从收到的协商请求消息中获取所述第一通信策略集;以及按预置规则将所述第一通信策略集生成第二通信策略集;
第二终端按照所述第二通信策略集中的通信策略并行执行握手;若握手成功,则第一终端与第二终端建立通信通道。
优选的,所述按预置规则将第一通信策略集生成第二通信策略集是根据第二终端自身支持的通信策略对所述第一通信策略集中的通信策略进行过滤生成第二通信策略集。
优选的,所述方法还包括:
第二终端通过服务器向第一终端发送协商应答消息,所述协商应答消息包括所述第二通信策略集;
第一终端获取协商应答消息;以及按照所述第二通信策略集中的通信策略并行执行握手。
优选的,所述方法还包括:
若建立的通信通道为多个,基于所述多个通信通道发送测试请求消息,以及将最先收到测试应答消息的通信通道作为第一通信通道。
优选的,所述第二通信策略集中还包括中转通信策略,第一终端和第二终端分别与该中转通信策略对应的中转服务器执行握手,若握手成功,则第一终端与第二终端通过中转服务器建立通信通道。
为解决上述问题,本发明还公开了一种建立通信通道的方法,所述方法包括:
第一终端通过服务器向第二终端发送协商请求消息,该协商应答消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二终端从收到的协商请求消息中获取所述第一通信策略集;以及按预置规则将所述第一通信策略集生成第二通信策略集;
第二终端通过服务器向第一终端发送协商应答消息,所述协商应答消息包括所述第二通信策略集;
第一终端获取协商应答消息并根据所述第二通信策略集中的通信策略并行执行握手,若握手成功,则第一终端与第二终端建立通信通道。
为解决上述问题,本发明还公开了一种数据传输方法,所述方法包括:
第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,所述第一通信策略集中包括两个或多个通信策略;
第二终端从收到的协商请求消息中获取所述第一通信策略集;以及按预置规则将所述第一通信策略集生成第二通信策略集;
第二终端按照所述第二通信策略集中的通信策略并行执行握手;若握手成功,则第一终端与第二终端建立通信通道;
第一终端和第二终端基于所述通信通道传输数据。
优选的,所述第一终端通过服务器向第二终端发送的协商请求消息中还包括与所述第一通信策略集相应的应用标识;
所述方法还包括:
第一终端或第二终端判断基于所述通信通道接收的数据中是否包括所述应用标识,若不包括,则丢弃该数据。
为解决上述问题,本发明还公开了一种建立通信通道的装置,所述装置包括:
第一通讯单元,用于通过服务器向被叫装置发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二通讯单元,用于接收协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
通信策略集转换单元,用于按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集;
握手单元,用于按照通信策略执行握手;
握手控制单元,用于控制握手单元按照通信策略集转换单元所生成的第二通信策略集中的通信策略并行执行握手。
优选的,所述通信策略集转换单元按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集是根据该装置自身支持的通信策略对所述第一通信策略集中的通信策略进行过滤生成第二通信策略集。
优选的,所述装置还包括:
第三通讯单元,用于通过服务器发送协商应答消息,所述协商应答消息包括所述第二通信策略集;
第四通讯单元,用于接收协商应答消息,该协商应答消息包括第二通信策略集。
优选的,所述装置还包括:
优选单元,用于基于多个通信通道发送测试请求消息,以及将最先收到测试应答消息的通信通道作为第一通信通道。
优选的,所述第二通信策略集中还包括中转通信策略;握手单元根据该中转通信策略与相应的中转服务器执行握手。
本发明还公开了一种建立通信通道的主叫装置,所述装置包括:第一通讯单元,用于通过服务器向被叫装置发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略。
本发明还公开了一种建立通信通道的被叫装置,所述装置包括:第二通讯单元,用于接收协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;通信策略集转换单元,用于按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集;握手单元,用于按照通信策略执行握手;握手控制单元,用于控制握手单元按照通信策略集转换单元所生成的第二通信策略集中的通信策略并行执行握手。
本发明还公开了一种数据通信系统,包括服务器和多个通信终端,所述通信终端包括:第一通讯单元,用于通过服务器发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;第二通讯单元,用于接收协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;通信策略集转换单元,用于按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集;握手单元,用于按照通信策略执行握手;握手控制单元,用于控制握手单元按照通信策略集转换单元所生成的第二通信策略集中的通信策略并行执行握手。
与现有技术相比,本发明一实施例具有以下效果:
现有技术中,通信双方在建立通信通道的过程中,每执行一种通信策略,主叫方都需要通过服务器向被叫方发送协商请求消息,由于网络环境的差异,按一种通信策略执行握手往往无法成功建立通信通道,因此,双方常常需要尝试执行多种通信策略,这样一来,造成在建立通信通道的过程中需要服务器多次转发协商请求消息,导致服务器负载增加,进而影响服务器运行的稳定性。本发明中,主叫方将多种通信策略按一定格式组织为第一通信策略集,并通过协商请求消息将该第一通信策略集发送由服务器转发至被叫方,被叫方根据第一通信策略集按预定规则生成第二通信策略集,并按照该第二通信策略集中的通信策略并行执行握手。由于本发明在建立通信通道的过程中,通信双方只需通过服务器转发一次协商请求消息,因此避免了现有技术中多次转发协商请求消息导致的服务器负载增加,甚至影响服务器运行稳定的问题。另外,由于本发明采用并行执行多个通信策略的方式,各个通信策略执行期间几乎不需要任何等待时间,因此能够在最短的时间内完成对多个通信策略的握手,极大地减少了建立通信通道所需消耗的时间。
附图说明
图1是现有技术中通信终端建立通信通道的系统结构框图;
图2是本发明所述一种建立通信通道的方法的实施例1的步骤流程图;
图3是本发明所述一种建立通信通道的方法的实施例2的步骤流程图;
图4是本发明所述一种建立通信通道的方法的实施例3的步骤流程图;
图5是根据本发明所述建立通信通道的方法的一应用实施例的系统环境框图;
图6是本发明所述的一种建立通信通道的装置一实施例的结构框图;
图7是本发明所述的一种通信系统的一实施例的系统结构框图。
具体实施方式
目前,现有技术在使用一种通信策略建立通信通道时,主叫方需要将协商消息通过服务器转发至被叫方,若建立通信通道的过程中需要尝试多种通信策略,则服务器需要多次转发协商请求消息,从而导致的服务器的负载急剧增加,造成服务器运行的不稳定。本发明将多种通信策略生成通信策略集发送至被叫方,通信双方按照通信策略集建立通信通道,由于避免了服务器多次转发协商消息,因此,很好的解决了现有技术存在的问题。
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。
参照图2,图2示出了本发明所述的一种建立通信通道的方法的实施例1的步骤流程图。下面参见图2对该实施例作进一步描述:
步骤201:第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略。
通信双方在尚未获知对方网络地址、端口等信息的情况下,无法开始建立通信通道,因此需要通过与服务器建立可靠连接,利用该服务器进行协商,以便获取主叫方或被叫方的网络地址、端口等用于建立通信通道的信息。
本发明中,通信策略指定了一种通信方式,例如TCP、UDP以及UPNP等。将多种通信策略按某种格式组织在一起即通信策略集。本发明将第一终端生成的其自身能够支持的通信策略集称为第一通信策略集。通信策略集优选的可按照数组的格式进行组织。下面给出一种通信策略集的结构示例:
策略1 | 策略2 | ... | 策略n-1 | 策略n | ... | 策略m |
优选的,通信策略集中的每一个通信策略包括以下内容:
通道类型 | 主动被动标志 | 执行时间(毫秒) | 地址索引 |
其中,
“通道类型”:即该通信策略执行的通信方式,如TCP或UDP等;
“主动被动标志”:该信息为可选信息,用于标识执行该策略时是主动发起还是被动等待,本例中,“0”表示主动,“1”表示被动,若策略中不指定主动或被动,则可以按照双方约定的方式执行;
“执行时间”:限制了该策略的执行耗时,若超出该时间,则认为该策略执行失败,该信息也是可选的;
“地址索引”:用于标识该通信策略对应的网络地址和端口,见下面的地址索引表:
地址索引 | 第一IP地址 | 第一端口号 |
其中,
“第一IP地址”:IP地址标识了终端在网络中的唯一位置信息,除此之外,也可以采用域名或其他信息表示终端的网络地址,在下文的描述中我们都以IP地址表示终端的网络地址;
“第一端口号”:在通信过程中,端口号分为源端口号和目标端口号,当然,所谓源和目标是相对的。优选的,根据不同的应用设置不同的端口号,以便在通信时请求和接收数据能够交给相应的应用程序处理。通过端口号结合IP地址,可以在全网范围内唯一标示不同地点不同的应用。因此容易理解,当终端上有多个应用程序需要与外部建立多个通信通道时,就需要开启多个不同的端口,而且,即使同一个应用程序与外部建立多个通信通道时,也需要开启多个不同的端口,例如,我们通过即时通讯终端同时与多个联系人建立通信通道,进行文件传输。为了避免可能出现的多条通信通道之间产生影响,本发明优选的,为第一通信策略集中的每一个通信策略分配不同的端口号。另外,在实施本发明时,本领域的技术人员也可选择使用同一端口执行不同的通信策略、建立不同的通信通道,但同时需要控制将不同通道上传输的数据通过该端口提交给相应的应用,但这样做,往往需要额外开发程序进行控制,不但成本较高,而且实现较为复杂。为了便于理解,在以后的描述中,均以不同策略使用不同端口,不同应用对应不同端口为例进行描述。例如,我们用数组Policy1表示第一通信策略集,用Addr表示地址索引表,该策略集中包含3个通信策略:
Policy1[0]={tcp,0,200,0}
Policy1[1]={udp,0,300,1}
Policy1[2]={upnp,0,300,2}
Addr[0]={192.168.1.2,6200}
Addr[1]={192.168.1.2,6300}
Addr[2]={10.21.123.6,6200}//为符合upnp通信方式的要求,IP地址10.21.123.6和端口6200为局域网内机器在NAT(Network Address Translation,网络地址转换)设备上影射的外网地址以及端口。需要说明的是,上述第一通信策略集的组织方式及内容是本发明优选的方法,本领域技术人员不应将其理解为对本发明的限制。
步骤202:第二终端从收到的协商请求消息中获取第一通信策略集。
步骤203:按预置规则将所述第一通信策略集生成第二通信策略集。
由于网络、软硬件环境存在差异,通信双方所支持的通信策略往往并不相同。第二终端根据其自身支持的通信策略对第一通信策略集进行过滤生成第二通信策略集,这样一来,由于第二通信策略集滤除了对第二终端无效的通信策略,保证了第二通信策略集中的通信策略为双方都支持的通信策略,因此,避免了因执行无效策略而导致的时间消耗,减少了建立通信通道的时间。同时,由于避免执行无效的通信策略,也减少了通信过程中可能出现错误或异常的概率,提高了通信系统的健壮性和稳定性。另外,由于采用了执行前对通信策略集进行过滤的机制,因此,在建立通信通道前,通信双方完全无需考虑对方能够支持的策略,而且,当通信终端需要扩展自身的通信策略时也不必受任何限制,因为新增加的通信策略若对方不支持则会被过滤掉,使得通信终端的扩展性大大提高。
当然,上述将第一通信策略集生成第二通信策略集的规则只是本发明优选的方法,本领域技术人员在实施本发明时可根据实际需要决定所述生成规则,本发明对此不做限制,例如,可直接将第一通信策略集作为第二通信策略集,即第二通信策略集保留第一通信策略集的全部内容。
仍以上述第一通信策略集Policy1为例,假设第二终端不支持upnp的通信方式,经过滤,第二通信策略集Policy2的内容如下:
Policy2[0]={tcp,0,200,0}
Policy2[1]={udp,0,300,1}
与上述通信策略集Policy2相应的地址索引表为:Addr[0]={192.168.1.2,6200},Addr[1]={192.168.1.2,6300}
步骤204:第二终端按照所述第二通信策略集中的通信策略并行执行握手;若握手成功,则第一终端与第二终端建立通信通道。
优选的,第二终端按照下面的方式并行执行握手:第二终端启动多个线程分别执行第二通信策略集中的各个通信策略。下面以线程Tn(n大于等于1,小于等于第二通信策略集中的策略数)执行第二通信策略集中的一个通信策略Pn为例对握手的过程进行说明:
线程Tn根据策略Pn指定的通信方式生成相应的连接请求消息,该连接请求消息包括:源/目标IP地址、源/目标端口。由于第二终端作为执行握手的主叫方,因此策略Pn所对应的第一终端的IP地址和端口号作为本次请求的目标IP地址和目标端口号,而第二终端的IP地址和为策略Pn开启的端口号则作为源IP地址和源端口号;
向第一终端发送连接请求消息;若在指定的时间内监听到源端口收到连接请求应答消息,则握手成功,双方建立通信通道。
其中,所述指定的时间内即上文所述的“执行时间”;所述策略指定的通信方式即上文所述的“通道类型”。对于不同的通信方式,其执行握手的机制可能有所不同,但其实质上都需要经过请求、应答这样的过程。例如,对于TCP,可通过调用操作系统提供的接口执行握手,并获得握手是否成功的结果,而对于UDP,则需要通过应用程序实施握手,并判断是否有返回结果。
以第二通信策略集Policy2为例,启动线程T1和T2,其中T1按TCP方式执行握手发送连接请求消息;同时T2按UDP方式执行握手发送连接请求消息;然后线程T1和T2分别监听是否在各自的“执行时间”内收到应答消息,若收到,双方建立通信通道。有可能出现的结果是线程T1和T2都收到了各自的应答消息,这意味着双方建立了两条通信通道,那么从中选择一条使用即可。
另外,第二终端还可以按照下面的方式并行执行握手:第二终端按照无序或有序的方式从第二通信策略集中依次选择一个未执行的策略执行握手。需要说明的是,采用这种执行方式,在按照一种通信策略发送连接请求消息后,并不需要等待其是否返回应答消息,而是立刻执行下一个通信策略,这样一来,比较理想的结果是第二终端在瞬间分别执行了所有的通信策略,发送了所有的连接请求消息,然后同时监听各策略对应的端口是否返回了应答消息,若收到应答消息,则该通信策略执行握手成功,双方建立通信通道。
以上介绍了两种并行执行握手的方式,当然,本领域的技术人员不应将此理解为对本发明的限制,在实施本发明时也可采用其它方式并行执行握手,本发明对此不做限定。采用并行执行握手,对通信策略集中的每一个通信策略而言都可以认为是在第一时间内执行了握手,几乎不需要花费任何等待时间,因此,极大地提高了建立通信通道的效率和及时性。
以上介绍了本发明所述的建立通信通道方法的实施例1。实施例2与上述实施例1的区别在于:在实施例1中,第二终端作为执行握手的主叫方,第一终端作为被叫方,而实施例2中,第一终端作为主叫方执行握手,第二终端则作为被叫方。下面结合图3对实施2做进一步描述:
步骤301:第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略。
步骤302:第二终端从收到的协商请求消息中获取第一通信策略集。
步骤303:第二终端根据自身支持的通信策略对所述第一通信策略集中的通信策略进行过滤生成第二通信策略集。
步骤304:第二终端通过服务器向第一终端发送协商应答消息,所述协商应答消息包括第二通信策略集。
优选的,所述向第一终端发送的协商应答消息中还包括与所述第二通信策略集相应的地址索引表,该地址索引表中不但包括原有的第一IP地址、第一端口号,而且还包与之相应的第二IP地址、第二端口号,所述第二IP地址为第二终端的IP地址,所述第二端口号为第二终端中与该通信策略相应的端口号,例如:
地址索引 | 第一IP地址 | 第一端口 | 第二IP地址 | 第二端口 |
步骤305:第一终从收到的协商应答消息中获取第二通信策略集。
步骤306:第一终端根据第二通信策略集中的通信策略并行执行握手,若握手成功,则第一终端与第二终端建立通信通道。
以多线程执行握手为例,各线程分别执行不同的通信策略:线程Tn根据“地址索引”取得与当前通信策略Pn相应的第一IP地址、第一端口和第二IP地址、第二端口;发送连接请求消息,该连接请求消息中,第二IP地址和第二端口为目标IP地址和目标端口号,第一IP地址和第一端口为源IP地址和源端口号;若在“执行时间内”,监听到所述源端口收到应答消息,则握手成功,双方建立通信通道。
通过实施1和实施例2可知,在建立通信通道的过程中,无论是第一终端还是第二终端都可以作为执行握手的主叫方,下面参见图4,图4示出了本发明所述建立通信通道方法的实施例3的步骤流程:
步骤401:第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略。
步骤402:第二终端从收到的协商请求消息中获取第一通信策略集。
步骤403:第二终端根据自身支持的通信策略对所述第一通信策略集中的通信策略进行过滤生成第二通信策略集。
步骤404:第二终端通过服务器向第一终端发送协商应答消息,所述协商应答消息包括第二通信策略集。
步骤405:第二终端按照第二通信策略集中的通信策略并行执行握手。
步骤406:第一终端获取协商应答消息,以及根据第二通信策略集中的通信策略并行执行握手。
第二终端通过服务器向第一终端发送协商应答消息后,随即按照第二通信策略集开始并行执行握手,此刻,对于第一终端存在2种情况:一种是尚未收到第二终端的协商应答消息,一种是已经收到了该协商应答消息。若第一终端收到协商应答消息,则按照第二通信策略集开始并行执行握手,也就是说,在这种情况下,第一终端和第二终端分别按照第二通信策略集并行执行握手。
步骤407:在步骤405和步骤406中,若握手成功,则第一终端与第二终端建立通信通道。
存在这样一种网络环境:第一终端位于局域网内,第二终端位于外网中,其中,第一终端通过NAT与外部网络相连。若第一通信策略集中的通信策略Pn对应的第一IP地址、第一端口为第一终端在内网中的IP地址和端口,在这种情况下,第二终端是无法根据第一终端位于内网的第一IP地址、第一端口向第一终端成功发送连接请求消息的,因此,当第二终端按照通信策略Pn向第一终端执行握手、发送连接请求消息时,由于无法将请求消息发送到第一终端,导致握手失败。
针对上述情况,若第二终端将自身与通信策略Pn对应的位于外网的第二IP地址、第二端口通过服务器转发给第一终端,由第一终端向第二终端执行握手、发送连接请求消息,则双方能够握手成功并建立通信通道。下面,我们假设NAT在外网的IP地址为第三IP地址,以第一终端执行通信策略Pn为例说明其具体过程,其中通信策略Pn中,第一IP地址、第一端口为第一终端在内网的IP地址和端口,第二IP地址、第二端口为第二终端在外网上的IP地址和端口:
I、第一终端向第二终端发送连接请求消息,该连接请求消息中,目标IP地址和目标端口为第二IP地址和第二端口,源IP地址和源端口为第一IP地址和第一端口为。该连接请求消息不会直接被发送到第二终端,而是先发送到第一终端所在局域网的NAT。NAT记录第一IP地址、第一端口与第二IP地址、第二端口之间的映射关系。
II、NAT为来自内网的连接请求分配端口号,我们称之为第三端口,然后将连接请求消息中的源IP地址转换为第三IP地址,将源端口转换为第三端口,最后,按照该请求消息中的目标IP地址和目标端口将该消息发送至第二终端。
III、第二终端收到请求消息后,以第三IP地址和第三端口作为目标IP地址和目标端口向NAT返回应答消息。
IV、NAT收到应答消息后,根据存储的映射关系,用对应的第一IP地址和第一端口替换该应答消息中的目标IP地址和目标端口,然后将该应答消息转发至位于内网中的第一终端。
V、第一终端收到应答消息,握手成功,双方按照通信策略Pn成功建立通信通道。
通过上面的描述可知,当第二终端作为主叫方无法与第一终端握手成功时,由第一终端作为主叫方则有可能握手成功。实施例3通过第一终端和第二终端分别按照第二通信策略集中的通信策略并行执行握手,使得对于同一通信策略,双方都能够作为主叫方执行握手,因此,极大地提高了双方握手和建立通信通道的成功率。
在本发明的实施例4中可采用上述几个实施例所述的任意一种方法建立通信通道,若双方建立了多个通信通道,基于所述多个通信通道同时发送测试请求消息,以及将最先收到测试应答消息的通信通道作为第一通信通道用于数据传输。基于多个通信通道同时发送测试请求消息,若最先返回测试应答消息,则说明该通信通道的数据传输效果最好,使用该通道传输数据消耗的时间也将最少,因此,可有效提高数据传输的及时性。
在本发明的实施例5与上述实施例的区别在于,第一终端与第二终端之间可通过中转服务器建立通信通道。
首先,第一通信策略集中包含中转通信策略,另外,协商请求消息中还包括与该中转策略对应的中转服务器地址和端口号,而且,该中转通信策略保留在生成的第二通信策略中。当执行到该中转通信策略时,第一终端和第二终端分别向所述中转服务器发送连接请求消息,若双方均收到来自中转服务器的应答消息,则第一终端和第二终端通过所述中转服务器建立通信通道。在传输数据时,首先,目标数据从第一终端按所述通信通道发送至中转服务器,再由该中转服务器转发至第二终端。优选的,只有当双方无法建立点对点的通信通道时,再通过中转服务器建立的通信通道,以便双方尽可能地基于点对点的方式传输数据,从而保证了数据传输效率的最大化。
以上描述了本发明所述建立通信通道方法的实施例,下面结合具体应用环境对所述方法做进一步描述。参见图5,图5示出了一个即时通讯系统的结构示意图,包括协商服务器S1、中转服务器S2、终端A和终端B,假设终端A需要与终端B建立通信通道以便传输数据,应用本发明所述方法描述如下:
终端A获取其自身支持的通信策略集作为第一通信策略集。
终端A申请中转服务器地址和端口。为了系统的稳定,可在系统中部署多台专用的数据中转服务器。当终端申请中转服务器时,选择当前负载最小、运行最健康的中转服务器,获得该中转服务器的IP地址及端口号。
组织第一通信策略集。为了便于解析,每一个通信策略用64bit整形数字来表示,通讯策略的内容如下:
通道类型 | 主动被动标志 | 执行时间(ms) | 地址索引 | 是否中转标志 | 保留 |
4bit 4bit 32bti 12bit 12bit 8bit
用数组Policy1表示第一通信策略集的内容如下:
Policy1[0]={tcp,0,200,0,0}
Policy1[1]={udp,0,300,1,0}
Policy1[2]={upnp,0,300,2,0}
Policy1[3]={tcp,0,300,3,1}//中转通信策略,最末位“1”表示该策略为中转通信策略
地址索引表内容如下:
Addr[0]={192.168.1.2,6200}
Addr[1]={192.168.1.2,6300}
Addr[2]={10.21.123.6,6200}//终端A在NAT设备上映射的外网IP地址和端口
Addr[3]={10.12.5.1,8000}//中转服务器的IP地址、端口号
需要指出,上述地址索引表中终端A的IP地址在实施时可能需要根据实际的网络或硬件环境进行转换,例如若终端A位于局域网内,那么该IP地址就是一个内网的IP地址,在经过网络地址转换设备时需要被转换为外网的IP地址,此部分内容可参见现有的相关文献,本发明不再赘述。
将组织好的第一通信策略集和相应的地址索引表打包成协商请求消息发送至协商服务器S1。
S1收到该协商请求消息后将其转发至终端B。
终端B从协商请求消息中获取第一通信策略集和相应的地址索引表,根据终端B支持的通信策略对第一通信策略集Policy1进行过略生成第二通信策略集,同时在第二通信策略集中补入终端B与各通信策略相应的IP地址和端口号,Policy2结果如下:
Policy2[0]={tcp,0,200,0,0}
Policy2[1]={udp,0,300,1,0}
Policy2[2]={upnp,0,300,2,0}//本例中,第二通信策略集中仍保留终端B无法支持的通信策略upnp,而是通过将该通信策略对应的终端B的IP地址、端口置空来标识该通信策略为无效策略。
Policy2[3]={tcp,0,300,3,1}
地址索引表:
Addr[0]={192.168.1.2,6200,112.11.1.3,7200}
Addr[1]={192.168.1.2,6300,112.11.1.3,7300}
Addr[2]={10.21.123.6,6200,0.0.0.0,0}//由于终端B不支持upnp,因此将返回的IP地址和端口置空
Addr[3]={10.12.5.1,8000}
需要说明的是,在本例中与第二通信策略集对应的地址索引表中,同时包括了终端A和终端B的IP地址和端口号,这样做是为了更加清楚地描述源IP地址、端口和目标IP地址和端口的对应关系。在具体实施时,在返回给终端A的地址索引表中,可以只包含终端B的IP地址和端口号,例如Addr[0]={112.11.1.3,7200},只要终端A能够根据该地址索引表获取与当前执行的通信策略相应的目标IP地址和端口即可。
终端B将第二通信策略集和相应的地址索引表打包为协商应答消息,通过协商服务器S将该协商应答消息发送至终端A。需要说明,向终端A发送的第二通信策略集中,其通信策略的“主动被动标志”与终端B本地的第二通信策略集中的“主动被动标志”具有相对或相应的关系,例如,同一通信策略,将终端A一方设置为主动,终端B为被动,另外,也可以将两端都设置为主动。在本例中,我们采用后者,即在终端A和终端B将同一通信策略都设置为主动方式,以保证尽可能大的握手成功率。
终端A从收到的协商应答消息获取第二通信策略集和相应的地址索引表,然后启动多个线程,按照第二通信策略集中的多个通信策略分别执行握手。
终端B发送完协商应答消息后也启动多个线程按照第二通信策略集中的多个通信策略分别执行握手。各线程分别监听是否在各自的“执行时间内”收到应答消息,若收到,握手成功,双方建立通信通道,否则关闭该线程。其中,在执行中转通信策略时,终端A和终端B分别与中转服务器S2执行握手,若握手成功,双方通过中转服务器S2建立通信通道。需要说明的是,中转通信策略可与其它策略同时执行握手,也可在其它策略执行握手失败后再执行。优选的,在其它通信策略握手失败后再执行中转通信策略,这样可以保证优先建立点对点通信通道,以提高数据传输的及时性。
若各通信策略执行握手的结果是双方建立了多条通信通道,基于所述多个通信通道同时发送测试请求消息,将最先收到测试应答消息的通信通道作为第一通信通道用于数据传输。
以上结合具体实施例描述了本发明所述的一种建立通信通道的方法。下面,参照以上有关本发明的介绍,对基于本发明所述的一种数据传输方法的一实施例进行描述:
第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,所述第一通信策略集中包括两个或多个通信策略;第二终端从收到的协商请求消息中获取所述第一通信策略集;以及按预置规则将所述第一通信策略集生成第二通信策略集;第二终端按照所述第二通信策略集中的通信策略并行执行握手;若握手成功,则第一终端与第二终端建立通信通道;第一终端和第二终端基于所述通信通道传输数据。
优选的,第一终端通过服务器向第二终端发送的协商请求消息中还包括与所述第一通信策略集相应的应用标识。当双方基于建立的通信通道传输数据时,第一终端或第二终端判断从该通信通道接收的数据中是否包括所述应用标识,若不包括,则丢弃该数据。
所述应用标识用于唯一标识终端上的一个应用程序,如可采用GUID(Global unique identifier,全局统一标识符)作为应用标识,以保证所有计算机每次生成的32字节字符串是唯一的。当第一终端和第二终端之间建立了通信通道后,通过判断接收的数据中是否包含双方约定的应用标识来判断数据是否有效,避免了对端上的其它应用程序利用该通信通道传输无效或非法的数据。
图6示出了本发明所述的一种建立通信通道的装置的一个实施例的结构框图。下面参见图6对该装置做进一步描述:
所述装置600包括:
第一通讯单元610,用于通过服务器向被叫装置发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二通讯单元620,用于接收协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
通信策略集转换单元630,用于按预置规则将第二通讯单元620所接收的第一通信策略集生成第二通信策略集;
握手单元640,用于按照通信策略执行握手;
握手控制单元650,用于控制握手单元640按照通信策略集转换单元所生成的第二通信策略集中的通信策略并行执行握手。
其中,通信策略集转换单元630按预置规则将第二通讯单元620所接收的第一通信策略集生成第二通信策略集是根据该装置自身支持的通信策略对所述第一通信策略集中的通信策略进行过滤生成第二通信策略集。
所述装置600还包括:第三通讯单元660,用于通过服务器发送协商应答消息,所述协商应答消息包括所述第二通信策略集;第四通讯单元670,用于接收协商应答消息,该协商应答消息包括第二通信策略集。
所述装置600还包括:
优选单元680,用于基于握手单元640所建立的多个通信通道发送测试请求消息,以及将最先收到测试应答消息的通信通道作为第一通信通道。
其中,所述第二通信策略集中还包括中转通信策略;握手单元根据该中转通信策略与相应的中转服务器执行握手。
下面对上述装置建立通信通道的一种实现方式进行描述:
若该装置用于主叫,首先,第一通讯单元610通过服务器向被叫装置发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;第四通讯单元670收到协商应答消息,该协商应答消息包括第二通信策略集;握手控制单元650按照第四通讯单元670所接收的协商应答消息中的第二通信策略集中的通信策略并行执行握手,若当前通信策略为中转通信策略,握手单元640与该中转通信策略对应的中转服务器执行握手;若握手单元执行握手后的结果是建立了多条通信通道,优选单元690基于多个通信通道发送测试请求消息,以及将最先收到测试应答消息的通信通道作为第一通信通道。
若该装置用于被叫,当第二通信单元620收到协商请求消息后,通信策略集转换单元630按照该装置自身支持的通信策略对所述协商请求消息中的第一通信策略集中的两个或多个通信策略进行过滤生成第二通信策略集;然后,第三通讯单元660通过服务器发送协商应答消息,所述协商应答消息包括第二通信策略集;之后,握手控制单元650按照策略集转换单元630所生成的第二通信策略集中的通信策略并行执行握手,其中,若当前通信策略为中转通信策略,握手单元640与该中转通信策略对应的中转服务器执行握手。
参见图7,图7示出了本发明所述的一种数据通信系统的一实施例的结构示意图,所述系统包括服务器800和多个通信终端700,所述终端700包括:
第一通讯单元710,用于通过服务器发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二通讯单元720,用于接收协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
通信策略集转换单元730,用于按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集;
握手单元740,用于按照通信策略执行握手;
握手控制单元750,用于控制握手单元按照通信策略集转换单元所生成的第二通信策略集中的通信策略并行执行握手。
对于装置、系统实施例而言,由于其基本相应于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上对本发明所提供的一种建立通信通道的方法、装置,进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。
Claims (16)
1.一种建立通信通道的方法,其特征在于,所述方法包括:
第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二终端从收到的协商请求消息中获取所述第一通信策略集;以及按预置规则将所述第一通信策略集生成第二通信策略集;
第二终端按照所述第二通信策略集中的通信策略并行执行握手;若握手成功,则第一终端与第二终端建立通信通道。
2.根据权利要求1所述的方法,其特征在于,所述按预置规则将第一通信策略集生成第二通信策略集是根据第二终端自身支持的通信策略对所述第一通信策略集中的通信策略进行过滤生成第二通信策略集。
3.根据权利要求1或2所述的方法,其特征在于,所述方法还包括:
第二终端通过服务器向第一终端发送协商应答消息,所述协商应答消息包括所述第二通信策略集;
第一终端获取协商应答消息;以及按照所述第二通信策略集中的通信策略并行执行握手。
4.根据权利要求3所述的方法,其特征在于,所述方法还包括:
若建立的通信通道为多个,基于所述多个通信通道发送测试请求消息,以及将最先收到测试应答消息的通信通道作为第一通信通道。
5.根据权利要求3所述的方法,其特征在于,所述第二通信策略集中还包括中转通信策略,第一终端和第二终端分别与该中转通信策略对应的中转服务器执行握手,若握手成功,则第一终端与第二终端通过中转服务器建立通信通道。
6.一种建立通信通道的方法,其特征在于,所述方法包括:
第一终端通过服务器向第二终端发送协商请求消息,该协商应答消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二终端从收到的协商请求消息中获取所述第一通信策略集;以及按预置规则将所述第一通信策略集生成第二通信策略集;
第二终端通过服务器向第一终端发送协商应答消息,所述协商应答消息包括所述第二通信策略集;
第一终端获取协商应答消息并根据所述第二通信策略集中的通信策略并行执行握手,若握手成功,则第一终端与第二终端建立通信通道。
7.一种数据传输方法,其特征在于,所述方法包括:
第一终端通过服务器向第二终端发送协商请求消息,该协商请求消息包括第一通信策略集,所述第一通信策略集中包括两个或多个通信策略;
第二终端从收到的协商请求消息中获取所述第一通信策略集;以及按预置规则将所述第一通信策略集生成第二通信策略集;
第二终端按照所述第二通信策略集中的通信策略并行执行握手;若握手成功,则第一终端与第二终端建立通信通道;
第一终端和第二终端基于所述通信通道传输数据。
8.根据权利要求7所述的方法,其特征在于,所述第一终端通过服务器向第二终端发送的协商请求消息中还包括与所述第一通信策略集相应的应用标识;
所述方法还包括:
第一终端或第二终端判断基于所述通信通道接收的数据中是否包括所述应用标识,若不包括,则丢弃该数据。
9.一种建立通信通道的装置,其特征在于,所述装置包括:
第一通讯单元,用于通过服务器向被叫装置发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二通讯单元,用于接收协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
通信策略集转换单元,用于按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集;
握手单元,用于按照通信策略执行握手;
握手控制单元,用于控制握手单元按照通信策略集转换单元所生成的第二通信策略集中的通信策略并行执行握手。
10.根据权利要求9所述的装置,其特征在于,所述通信策略集转换单元按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集是根据该装置自身支持的通信策略对所述第一通信策略集中的通信策略进行过滤生成第二通信策略集。
11.根据权利要求9或10所述的装置,其特征在于,所述装置还包括:
第三通讯单元,用于通过服务器发送协商应答消息,所述协商应答消息包括所述第二通信策略集;
第四通讯单元,用于接收协商应答消息,该协商应答消息包括第二通信策略集。
12.根据权利要求11所述的装置,其特征在于,所述装置还包括:
优选单元,用于基于多个通信通道发送测试请求消息,以及将最先收到测试应答消息的通信通道作为第一通信通道。
13.根据权利要求11所述的装置,其特征在于,所述第二通信策略集中还包括中转通信策略;握手单元根据该中转通信策略与相应的中转服务器执行握手。
14.一种建立通信通道的主叫装置,其特征在于,所述装置包括:
第一通讯单元,用于通过服务器向被叫装置发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略。
15.一种建立通信通道的被叫装置,其特征在于,所述装置包括:
第二通讯单元,用于接收协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
通信策略集转换单元,用于按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集;
握手单元,用于按照通信策略执行握手;
握手控制单元,用于控制握手单元按照通信策略集转换单元所生成的第二通信策略集中的通信策略并行执行握手。
16.一种数据通信系统,包括服务器和多个通信终端,其特征在于,所述通信终端包括:
第一通讯单元,用于通过服务器发送协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
第二通讯单元,用于接收协商请求消息,该协商请求消息包括第一通信策略集,该第一通信策略集中包括两个或多个通信策略;
通信策略集转换单元,用于按预置规则将第二通讯单元所接收的第一通信策略集生成第二通信策略集;
握手单元,用于按照通信策略执行握手;
握手控制单元,用于控制握手单元按照通信策略集转换单元所生成的第二通信策略集中的通信策略并行执行握手。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101357783A CN101369987B (zh) | 2007-08-16 | 2007-08-16 | 一种建立通信通道的方法及装置 |
HK09102868.6A HK1122668A1 (en) | 2007-08-16 | 2009-03-25 | Method and device for establishing communication channel |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101357783A CN101369987B (zh) | 2007-08-16 | 2007-08-16 | 一种建立通信通道的方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101369987A true CN101369987A (zh) | 2009-02-18 |
CN101369987B CN101369987B (zh) | 2011-09-28 |
Family
ID=40413615
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101357783A Expired - Fee Related CN101369987B (zh) | 2007-08-16 | 2007-08-16 | 一种建立通信通道的方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN101369987B (zh) |
HK (1) | HK1122668A1 (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102902405A (zh) * | 2012-08-07 | 2013-01-30 | 深圳市集尚科技发展有限公司 | 智能终端遥控器及其触控方法 |
CN103248679A (zh) * | 2013-04-26 | 2013-08-14 | 山东超越数控电子有限公司 | 一种网络消息传递方法 |
CN103795958A (zh) * | 2012-10-30 | 2014-05-14 | 中国电信股份有限公司 | 多媒体呼叫协商方法、系统及视频互通网关、多媒体终端 |
CN104104569A (zh) * | 2013-04-01 | 2014-10-15 | 华为技术有限公司 | 建立vpn隧道的方法及服务器 |
CN104301361A (zh) * | 2013-07-19 | 2015-01-21 | 中兴通讯股份有限公司 | 一种基于m2m系统的智能导览方法和系统 |
CN105208139A (zh) * | 2014-06-26 | 2015-12-30 | 浙江大华技术股份有限公司 | 一种终端建立连接的方法、终端和服务器 |
WO2016000138A1 (zh) * | 2014-06-30 | 2016-01-07 | 北京新媒传信科技有限公司 | 一种数据传输方法、终端和服务器 |
CN109451596A (zh) * | 2018-10-29 | 2019-03-08 | Oppo广东移动通信有限公司 | 数据传输方法及相关装置 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6539030B1 (en) * | 2000-02-07 | 2003-03-25 | Qualcomm Incorporated | Method and apparatus for providing configurable layers and protocols in a communications system |
US20030158959A1 (en) * | 2002-02-15 | 2003-08-21 | Jay Jayapalan | Establishment of communications using point to point protocols such that duplicate negotiations are avoided |
CN100539582C (zh) * | 2004-09-23 | 2009-09-09 | 华为技术有限公司 | 通信设备选择通信协议的方法 |
CN100518187C (zh) * | 2005-11-15 | 2009-07-22 | 中兴通讯股份有限公司 | 一种安全等级协商方法 |
-
2007
- 2007-08-16 CN CN2007101357783A patent/CN101369987B/zh not_active Expired - Fee Related
-
2009
- 2009-03-25 HK HK09102868.6A patent/HK1122668A1/xx not_active IP Right Cessation
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102902405A (zh) * | 2012-08-07 | 2013-01-30 | 深圳市集尚科技发展有限公司 | 智能终端遥控器及其触控方法 |
CN103795958B (zh) * | 2012-10-30 | 2017-10-13 | 中国电信股份有限公司 | 多媒体呼叫协商方法、系统及视频互通网关、多媒体终端 |
CN103795958A (zh) * | 2012-10-30 | 2014-05-14 | 中国电信股份有限公司 | 多媒体呼叫协商方法、系统及视频互通网关、多媒体终端 |
CN104104569A (zh) * | 2013-04-01 | 2014-10-15 | 华为技术有限公司 | 建立vpn隧道的方法及服务器 |
CN103248679A (zh) * | 2013-04-26 | 2013-08-14 | 山东超越数控电子有限公司 | 一种网络消息传递方法 |
CN104301361A (zh) * | 2013-07-19 | 2015-01-21 | 中兴通讯股份有限公司 | 一种基于m2m系统的智能导览方法和系统 |
CN105208139B (zh) * | 2014-06-26 | 2018-08-07 | 浙江大华技术股份有限公司 | 一种终端建立连接的方法、终端和服务器 |
CN105208139A (zh) * | 2014-06-26 | 2015-12-30 | 浙江大华技术股份有限公司 | 一种终端建立连接的方法、终端和服务器 |
CN105580334A (zh) * | 2014-06-30 | 2016-05-11 | 北京新媒传信科技有限公司 | 一种数据传输方法、终端和服务器 |
WO2016000138A1 (zh) * | 2014-06-30 | 2016-01-07 | 北京新媒传信科技有限公司 | 一种数据传输方法、终端和服务器 |
CN105580334B (zh) * | 2014-06-30 | 2018-10-26 | 北京新媒传信科技有限公司 | 一种数据传输方法、终端和服务器 |
CN109451596A (zh) * | 2018-10-29 | 2019-03-08 | Oppo广东移动通信有限公司 | 数据传输方法及相关装置 |
CN109451596B (zh) * | 2018-10-29 | 2021-03-09 | Oppo广东移动通信有限公司 | 数据传输方法及相关装置 |
Also Published As
Publication number | Publication date |
---|---|
CN101369987B (zh) | 2011-09-28 |
HK1122668A1 (en) | 2009-05-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101364976B (zh) | 一种建立通信通道的方法、装置及数据通信系统 | |
CN101369987B (zh) | 一种建立通信通道的方法及装置 | |
CN103856440B (zh) | 一种基于分布式总线的消息处理方法、服务器和系统 | |
CN110121902B (zh) | 一种通信建立的方法及终端 | |
CN105049495B (zh) | 设备发现方法、装置及系统 | |
CN106210049B (zh) | 一种基于消息队列的集群通信方法及系统 | |
CN100558109C (zh) | 基于会话初始协议的负载均衡实现方法及系统 | |
CN105553977A (zh) | 请求消息的处理、发送方法及装置 | |
CN111200805B (zh) | 基于蓝牙设备的蓝牙组网方法及其系统 | |
CN108650482B (zh) | 一种视频通话服务的响应方法及设备 | |
US7280492B2 (en) | Videoconferencing system | |
CN108055140A (zh) | 组网中跨设备通信方法、装置、存储介质及其计算机设备 | |
CN111953925A (zh) | 媒体流的处理方法及装置、系统 | |
CN101222437A (zh) | 在二层交换网络中透传bpdu报文的方法和系统 | |
JP2006148418A (ja) | サーバおよび通信制御方法 | |
JP5188160B2 (ja) | 会議装置及び接続制御方法 | |
EP2701358B1 (en) | Method, device, and system for implementing multimedia data recording | |
JP2003069640A (ja) | イーサネット(登録商標)上における明示的マルチキャストサービス方法及び装置 | |
US20080101564A1 (en) | Communication system | |
CN101632259A (zh) | 网络中的第2层管理实体消息收发框架 | |
CN110474781B (zh) | 一种组播数据转发的方法及装置 | |
CN111338747A (zh) | 一种数据通信方法、装置、终端设备和存储介质 | |
CN111901689A (zh) | 流媒体数据的传输方法、装置、终端设备和存储介质 | |
JP2004129159A (ja) | パケット変換方法、パケット通信システム、パケット変換装置、パケット変換プログラムおよび記録媒体 | |
CN108270756B (zh) | 一种设备间通信的方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1122668 Country of ref document: HK |
|
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: GR Ref document number: 1122668 Country of ref document: HK |
|
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110928 |
|
CF01 | Termination of patent right due to non-payment of annual fee |