发明内容
本申请的一个实施例的目的在于提供一种用于建立实时通信连接的方法、装置、设备和介质,本申请实施例可以提高建立连接的效率。
第一方面,本申请实施例提供了一种用于建立实时通信连接的方法,包括:在获取到会话描述协议SDP提议信息后,创建用于处理网络地址转化NAT会话遍历实用工具STUN请求消息的系统资源;接收客户端发送的所述STUN请求消息;根据所述系统资源的创建完成情况,进行请求处理,所述进行请求处理包括保存所述STUN请求消息或查找所述STUN请求消息。
在一种实施方式中,所述根据所述系统资源的创建完成情况,进行请求处理,包括:在确定所述系统资源未创建完成的情况下,保存所述STUN请求消息。
在一种实施方式中,根据所述系统资源的创建完成情况,进行请求处理,还包括:在所述系统资源的创建完成之后,查找获得所述客户端发送的STUN请求消息;直接使用所述系统资源根据查找到的所述STUN请求消息生成STUN响应消息。
在一种实施方式中,所述方法还包括,在查找所述客户端发送的STUN请求消息之后,清空已经保存的所述STUN请求消息。
在一种实施方式中,所述SDP提议信息包括提议请求标识,所述STUN请求消息包括请求标识,所述查找获得所述客户端发送的STUN请求消息,包括:将接收到的提议请求标识和已保存的请求消息中的请求标识进行匹配,根据匹配结果查找获得所述STUN请求消息。
在一种实施方式中,在获取到会话描述协议SDP提议信息后,所述方法还包括:保存所述提议请求标识,所述提议请求标识包括客户端标识和信令服务器标识,所述客户端标识和所述信令服务器标识为预设固定长度的随机字符串。
在一种实施方式中,所述接收客户端发送的所述STUN请求消息,包括:在所述系统资源的创建完成之后,接收到所述客户端发送的STUN请求消息;所述根据所述系统资源的创建完成情况,进行请求处理,包括:直接根据所述客户端发送的STUN请求消息生成STUN响应消息。
第二方面,本申请实施例提供了一种用于建立实时通信连接的装置,该装置包括:创建单元,用于在获取到会话描述协议SDP提议信息后,创建用于处理网络地址转化NAT会话遍历实用工具STUN请求消息的系统资源;接收单元,用于接收客户端发送的所述STUN请求消息;处理单元,用于根据所述系统资源的创建完成情况,进行请求处理,所述进行请求处理包括保存所述STUN请求消息或查找所述STUN请求消息。
在一种实施方式中,所述处理单元在根据所述系统资源的创建完成情况,进行请求处理时,具体用于在确定所述系统资源未创建完成的情况下,保存所述STUN请求消息。
在一种实施方式中,处理单元在根据所述系统资源的创建完成情况,进行请求处理时,还具体用于:在所述系统资源的创建完成之后,查找获得所述客户端发送的STUN请求消息;直接使用所述系统资源根据查找到的所述STUN请求消息生成STUN响应消息。
在一种实施方式中,所述处理单元还用于在查找所述客户端发送的STUN请求消息之后,清空已经保存的所述STUN请求消息。
在一种实施方式中,所述SDP提议信息包括提议请求标识,所述STUN请求消息包括请求标识,所述处理单元在查找获得所述客户端发送的STUN请求消息时,具体用于将接收到的提议请求标识和已保存的请求消息中的请求标识进行匹配,根据匹配结果查找获得所述STUN请求消息。
在一种实施方式中,在获取到会话描述协议SDP提议信息后,处理单元还用于,保存所述提议请求标识,所述提议请求标识包括客户端标识和信令服务器标识,所述客户端标识和所述信令服务器标识为预设固定长度的随机字符串。
在一种实施方式中,所述接收单元在接收客户端发送的所述STUN请求消息时,具体用于在所述系统资源的创建完成之后,接收到所述客户端发送的STUN请求消息;
所述处理单元在根据所述系统资源的创建完成情况,进行请求处理时,具体用于直接根据所述客户端发送的STUN请求消息生成STUN响应消息。
第三方面,本申请的一个实施例提供一种电子设备,包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序,其中,所述处理器执行所述程序时可实现如第一方面及第一方面的任一实施方式所述的方法。
第四方面,本申请的一个实施例提供一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时可实现如第一方面及第一方面的任一实施方式所述的方法。
第五方面,本申请的一个实施例提供一种计算机程序产品,所述的计算机程序产品包括计算机程序,其中,所述的计算机程序被处理器执行时可实现如第一方面及第一方面的任一实施方式所述的方法。
本申请实施例通过在接收到客户端发送的STUN请求消息后,根据系统资源的创建完成情况来保存或者查找STUN请求消息,能够便于后面在系统资源创建完成后,直接查找并处理该STUN请求消息,无需等待客户端的重传时间,与现有技术相比,能够节省等待重传的时间,提高连接建立的效率。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。
以下,为了便于理解和说明,作为示例而非限定,以将本申请的实时通信的方法在实时通信系统中的执行过程和动作进行说明。
基于WebRTC的多对多实时通信多方通信架构主要包括以下三种架构:网格(Mesh)架构,即多个终端之间两两进行连接,形成一个网状结构,与其他所有的终端都能互联通信;多点会议单元(Multipoint Conferencing Unit,MCU)架构,由一个服务器和多个客户端组成,各个终端将自己的音视频发送给服务器,服务器将同一个房间中的所有终端进行混合编码,并将混合后的音视频发给各个终端;选择性转发单元(Selective ForwardingUnit,SFU)架构,该方案也是由一个服务器和多个终端组成,但与MCU不同的是,SFU不对音视频进行混流,收到某个终端共享的音视频流后,就直接将该音视频流转发给房间内的其他终端。SFU服务器相当于是一个音视频路由转发器。由于SFU架构具有网数结构简单、据包直接转发,不需要编码,具有硬件资源消耗小、延迟低实时性高灵活性强等优点,在WebRTC通信中被广泛采用。下文以SFU架构下为例来描述本申请实施例的方案。
下面结合附图1示例性阐述本申请的一个实施例提供的实时通信的系统的整体组成结构。
如图1所示,本申请的一个实施例提供了实时通信系统包括:多个客户端,信令服务器和数据流转发服务器。
在本申请实施例中,信令服务器也可以称为管理端也可以称为控制端,信令服务器用于与客户端和数据流转发服务器之间进行信令交互来传递客户端之间连接的建立所需要的必要信息。本申请实施例中信令服务器的作用是作为一个中间人帮助通信的双方在尽可能少的暴露隐私的情况下建立连接。信令服务器与客户端和数据流转发服务器间的通信方式可以使用任何方式,例如,WebSocket或者XMLHttpRequest等来交换彼此的令牌信息本申请实施例并不限于此。
本申请实施例中,数据流转发服务器可以是Mediasoup、Janus、Jitsi、Kurento或Medooze等,本申请实施例并不限于此,应理解,数据流转发服务器也可以叫做SFU或者转发服务器或者媒体转发服务器或者媒体服务器,下文中如果没有特殊说明,数据流转发服务器的几种叫法可以替换,本申请实施例对此不做限定。应理解,本申请中,信令服务器和数据流转发服务器可以是独立的两个设备,也可以是集成在一个设备上,本申请实施例并不对此做限定。
本申请实施例中的客户端也可以称为用户端或者用户设备或者终端设备,本申请实时例中,终端设备可以安装有浏览器,可以通过浏览器进行实时通信,或者安装有APP或者小程序,通过APP或者小程序进行实时通信。本申请中终端设备可以包括智能手机、平板电脑、(personal digital assistant,PDA个人数字助理)、计算机、游戏机、可穿戴设备、平板电脑(portable android device,PAD)等,本申请实施例并不限于此。
应理解,该电子设备上运行的操作系统可以是移动版的安卓(Android)、乌班图(Ubuntu)移动版、泰泽(Tizen)等基于Linux内核的操作系统以及Windows、Mac OS、Linux等桌面操作系统,但本发明并不限于此。
本申请实施例中,终端设备可以指接入终端、用户设备(User Equipment,UE)、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。接入终端可以是蜂窝电话、无绳电话、会话启动协议(SessionInitia tion Protocol,SIP)电话、无线本地环路(Wireless Local Loop,WLL)站、个人数字处理(Personal Digital Assistant,PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备、5G网络中的终端设备或者未来演进的公共陆地移动网络(Public Land Mobile Network,PLMN)中的终端设备等。
应理解,图1中所示的通信系统场景中,仅示意出了一个客户端的情况下,但本申请实施例并不限于此,在实际的实时通信场景中,客户端的数量为多个,多个客户端之间通过数据流转发服务器进行数据流的转发来时间彼此之间的通信,在实际应用中客户端的数量可以包括任意多个,具体数量可以根据实际参与会议的人员数量情况来定,例如可以是10个,50个,500个,5000个等。
现有SFU架构的WebRTC通信中,在信令服务器接收到客户端发送的会话描述协议SDP提议(SDP offer)信息后,会同时进行两件事情。一是会分离出有关媒体相关的参数,比如:音频还是视频,编码类型,采样率等媒体参数发送给数据流转发服务器去创建与客户端对应的系统资源(比如mediasoup媒体服务器Transport资源)(此处,可以是将客户端发送的sdp offer原样转发,也可以按照私有格式,整理提取以后再转发出去),以便于数据流转发服务器等待客户端收到SDP应答(SDP Answer)以后,发起网络地址转化NAT会话遍历实用工具STUN请求消息(STUN request)。二是会同时会生成与之对应的SDP应答(SDP Answer)信息返回给客户端。
客户端在收到信令服务器的SDP Answer以后,向媒体服务器发起STUN请求消息(STUN request)。一般情况下,媒体服务器已经创建与之匹配的相关资源,收到STUNrequest以后,检验合法正确以后,向客户端返回STUN响应消息(STUN response)。之后就可以传输媒体数据了。
然而,由于信令服务器在收到客户端发送的SDP Offer以后,回复客户端的SDPAnswer,和向数据流转发服务器转发SDP Offer可能会同时进行。当客户端(client)接收和处理Answer的速度比数据流转发服务器接收和处理Offer的速度快,客户端(client)发送的STUN request到达数据流转发服务器时,数据流转发服务器还未分配创建相关的Transport资源,此时数据流转发服务器是无法处理STUN request的。客户端(client)会以超时重传机制(Retransmission Time Out,RTO)为间隔重新发送STUN request。每次重传加倍。其中,RTO的指是根据连接往返时间(Round Trip Time,RTT)进行估算的。假设RTO为500ms,请求将在0ms、500ms、1500ms、3500ms、7500ms、15500ms和31500ms时发送。直到客户端收到服务端的STUN response或者达到最大尝试次数,或者超过最大尝试连接时间。也就是说这种情况下,在数据流转发服务器创建完系统资源后,需要等待重传的时间才可以处理STUN request。因此,现有WebRTC通信中,存在建立STUN连接的时间长的问题,因此,如何提供一种能够减少建立STUN连接的时间的通信方式,成为亟需解决的技术问题。
鉴于以上问题,本申请提供一种用于建立实时通信连接的方法,数据流转发服务器能够在接收到客户端发送的STUN请求消息后,确定不存在所述系统资源的情况下,保存所述STUN请求消息。即在接收到客户端发送的STUN请求消息后,先判断是否存在处理STUN请求消息的系统资源,在确定不存在的情况下,保存所述STUN请求消息。即在系统资源创建完成之前,收到STUN请求消息时,不丢弃该STUN请求消息,而是保存起来。便于后面在系统资源创建完成后,直接查找并处理该STUN请求消息,无需等待客户端的重传时间,与现有技术相比,能够节省等待重传的时间,提高连接建立的效率。
下面结合附图2示例性阐述本申请的一个实施例提供的用于建立实时通信连接的方法。
如图2所示的方法应用于如图1所示的实时通信系统中,图2所示的方法包括:
210,数据流转发服务器在获取到会话描述协议SDP提议信息后,创建用于处理STUN请求消息的系统资源。
具体而言,如图2所示,在210之前,首先客户端先向信令服务器发送SDP提议(SDPoffer)消息,一方面,信令服务器向客户端反馈SDP应答消息,另一方面,信令服务器将收到的SDP提议和发送给客户的SDP应答消息转发给媒体服务器。应理解,信令服务器向媒体服务器转发SDP提议和SDP应答是在信令服务器生成SDP应答消息后执行的,可以与信令服务器向客户端发送SDP应答消息同时进行,也可以在信令服务器向客户端发送SDP应答消息之前或之后进行,本申请实施例并不限于此。
应理解,本申请实施例中的SDP提议中包括有客户端的用户标识,SDP应答消息包括有信令服务器为数据流转发服务器生成的用户标识,具体客户端的用户标识和数据流转发服务器的用户标识可以用于数据流转发服务器判断客户端发送的STUN请求消息是否是发给自己的,以及用于后续STUN请求消息的匹配查找,具体用户标识的用处可以参照下文关于步骤230的描述。另外,本申请实施例中SDP提议和SDP应答消息中还可以包括其他用于媒体协商的字段内容,具体可以参见现有技术的描述,此处,本申请实施例并不对此做限定。
应理解,信令服务器获取到客户端发送的SDP offer信息后,向数据流转发服务器发送的SDP提议信息,可以是在信令服务器接收到客户端发送的会话描述协议提(SDPoffer)信息后,信令服务器分离出有关媒体相关的参数,比如:音频还是视频,编码类型,采样率等媒体参数之后,生成一个新的SDP提议信息发送给数据流转发服务器,也可以是信令服务器将客户端发送的sdp offer原样转发给数据流转发服务器。本申请实施例并不限于此。应理解,信令服务器转发SDP提议和SDP应答消息可以是通过一条消息发送给数据流转发服务器也可以是通过两个消息分别发送给数据流转发服务器的,本申请实施例并不对此做限定。
在数据流转发服务器获取到SDP提议信息后,会去创建与客户端对应的系统资源,即用于处理网络地址转化NAT会话遍历实用工具STUN请求消息的系统资源,以便于数据流转发服务器等待客户端收到SDP Answer以后,发起网络地址转化NAT会话遍历实用工具请求STUN request消息。
应理解,本申请实施例中系统资源可以包括传输通道Transport,以及其下的生产者Producers和消费者Consumers等对象。具体而言,Transport主要维护了生产者和消费者的订阅关系。用于接收客户端的实时传输协议(Real-time Transport Protocol,RTP)和/或RTP控制协议(RTP Control Protocol,RTCP)数据包,转发RTP数据给consumer对象;还用于处理收到的RTCP数据包,并发送RTCP的反馈消息给客户端;Transport用RtpStreamRecv管理接收流,用RtpStreamSend管理发送流,如果启用RTX重传,还会生成RTXStream。一般在Transport下的RtpStreamRecv还会生成带有NackGenerator对象,负责NACK重传消息的生成。另外,Transport下还包括处理stun请求的ice server等对象。应理解,本申请中的系统资源可以包括但不限于此处描述的Transport以及其下对应的上述各种对象。
220,发送STUN请求消息;
即客户端向数据流转发服务器发送所述STUN请求消息。相对应的,数据流转发服务器接收客户端发送的所述STUN请求消息。
客户端在收到信令服务器的SDP Answer以后,向数据流转发服务器发起STUNrequest。
230,数据流转发服务器根据所述系统资源的创建完成情况,进行请求处理,所述进行请求处理包括保存所述STUN请求消息或查找所述STUN请求消息。
本申请实施例通过在接收到客户端发送的STUN请求消息后,根据系统资源的创建完成情况来保存或者查找STUN请求消息,能够便于后面在系统资源创建完成后,直接查找并处理该STUN请求消息,无需等待客户端的重传时间,与现有技术相比,能够节省等待重传的时间,提高连接建立的效率。
具体而言,本申请实施例中,数据流转发服务器会根据系统资源创建完成情况和接收STUN请求消息的时间先后会进行灵活的请求处理。包括以下几种情况:
第一种情况:在系统资源未创建完成的情况下,接收到客户端发送的STUN请求消息。
对应的,作为一种可选的实施例,所述根据所述系统资源的创建完成情况,进行请求处理,包括:
在确定所述系统资源未创建完成的情况下,保存所述STUN请求消息。
可选的,作为另一实施例,在数据流转发服务器已经保存STUN请求消息之后,到达超时重传机制(Retransmission TimeOut,RTO)后,客户端会再次发送STUN请求消息,如果此时,数据流转发服务器还是没有完成系统资源创建,由于已经保存了相同的STUN请求消息,数据流转发服务器会对后续的相同的STUN请求消息不再保存,做丢弃或者忽略处理。可选的,数据流转发服务器也可以保存两份或少量的几分相同的STUN请求消息,也就是说本申请实施例在系统资源未创建完成之前,对于同一STUN请求消息,仅保存首次或者前几次收到的STUN请求消息,对于后续的相同的请求消息不再保存。
进一步的,作为另一实施例,在所述系统资源的创建完成之后,数据流转发服务器查找获得所述客户端发送的STUN请求消息;
直接使用所述系统资源根据查找到的所述STUN请求消息生成STUN响应消息。
具体而言,本申请实施例中,数据流转发服务器在收到STUN request以后,没有找到对应的系统资源(例如,Transport)处理它,先把STUN request请求保存起来,当数据流转发服务器收到SDP Offer创建完并初始化完新的系统资源以后,会去STUN_request_存储列表中查找自己的STUN请求,如果找到了,则进行处理,向客户端返回STUN response。
本申请实施例中,由于数据流转发服务器在未创建完成系统资源前保存了STUN请求消息,因此,在系统资源创建完成后,可以直接查找获得保存的STUN请求消息,直接进行STUN响应,而无需等待客户端的重传时间,能够减少客户端等待STUN response的时间。因为STUN request重传的RTO时间是加倍的。如果RTO是500ms,如果数据流转发服务器第一次收到了STUN request,此时还没有或者正在创建系统资源,还不能处理STUN请求,现有技术中只能丢弃请求。要想接到新的STUN的请求,需要再等500ms。如果采用上述本申请的方案,在接收STUN请求消息后,到完成创建又花费了5ms,与现有技术丢弃请求,再次等待重传请求消息相比(再假设忽略查找保存的STUN请求消息的时间情况下),会节省495ms的时间。
因此,本申请实施例在系统资源创建完成之前,收到STUN请求消息时,不丢弃该STUN请求消息,而是保存起来。便于后面在系统资源创建完成后,直接查找并处理该STUN请求消息,无需等待客户端的重传时间,与现有技术相比,能够节省等待重传的时间,提高连接建立的效率。
可选的,作为另一实施例,在本申请实施例中,在系统资源创建完成之后,查找已保存的STUN请求消息过程中,如果收到了客户端重传发送的STUN请求消息,此处,数据流转发服务器还没有查找到STUN请求消息,则停止消息的查找,直接使用系统资源处理新接收到的STUN请求消息。通过这种方式,能够节省查找时间,提升连接建立效率。
可选的,作为另一实施例,所述SDP提议信息包括提议请求标识,所述STUN请求消息包括请求标识,所述查找获得所述客户端发送的STUN请求消息,包括:将接收到的提议请求标识和已保存的请求消息中的请求标识进行匹配,根据匹配结果查找获得所述STUN请求消息。
可选的,作为另一实施例,在获取到会话描述协议SDP提议信息后,图2所述的方法还可以包括:保存所述提议请求标识,所述提议请求标识包括客户端标识和信令服务器标识,所述客户端标识和所述信令服务器标识为预设固定长度的随机字符串。
具体而言,在本申请实施例中,数据流转发服务器可以依据STUN请求消息中的用户名(username)来识别请求是否属于己方。username包括远端用户名(RemoteUsername)和本地用户名(localUsername),例如,信令服务器为数据流转发服务器生成的ice-ufrag(远端用户名)和客户端的ice-ufrag(本地用户名)。其中ice-ufrag携带在信令服务器与客户端的SDP Offer/Answer中。
具体而言,客户端在发送SDP offer时携带有客户端的ice-ufrag,信令服务器在回复客户的SDP Answer时携带有信令服务器为数据流转发服务器生成的ice-ufrag,在信令服务器向数据流转发服务器发送SDP offer时携带有客户端的ice-ufrag和数据流转发服务器的ice-ufrag。数据流转发服务器将接收到的客户端的ice-ufrag和数据流转发服务器的ice-ufrag进行保存,以用于后续STUN请求消息的查找。在客户端接收到SDP answer以后,解析出对端(即数据流转发服务器)的ice-urfrag,在客户端发起STUN request的时候会使用客户端的ice-ufrag和数据流转发服务器的ice-ufrag拼凑出username。
应理解,本申请实施例中ice-urfrag的长度根据需要在统一规定。可以是4位、8位或16位等,本申请实施例并不限于此。
可选的,作为另一实施例,在查找所述客户端发送的STUN请求消息之后,清空已经保存的所述STUN请求消息。
具体而言,在系统资源创建完成后,且数据流转发服务器查找到保存的STUN请求消息且客户端发送STUN响应消息后,情况本地已存储的STUN请求消息。这样,能够节省存储资源。
第二种情况:在系统资源创建完成之后的情况下,接收到客户端发送的STUN请求消息。
可选的,作为一个实施例,在所述系统资源的创建完成之后,接收到所述客户端发送的STUN请求消息;
所述根据所述系统资源的创建完成情况,进行请求处理,包括:
直接根据所述客户端发送的STUN请求消息生成STUN响应消息。
由于系统资源已经创建完成,因此,本申请实施例中在收到STUN请求消息后,直接处理该消息,而不在保存,这样能够避免占用存储资源。
下面结合图3站在数据流转发服务器的角度,对本申请又一实施例提供的用于建立实时通信连接的方法流程图进行详细描述。如图3所示的方法由数据流转发服务器执行,所示方法包括:
310,创建系统资源。
即在接收到SDP提议之后,数据流转发服务器创建系统资源。
320,在系统资源创建完成前接收到STUN请求消息,保存该STUN请求消息。
321,在系统资源创建完成后,查找STUN请求消息。
330,在资源创建完成前未接收到STUN请求消息,在资源创建完成后,查找STUN请求消息。
331,等待接收STUN请求消息。
即在未查找到STUN请求消息后,等待接收客户端发送的STUN请求消息。
340,发送STUN反馈消息。
即数据流转发服务器向客户端发送STUN反馈消息。
请参考图4,图4示出了本申请的用于建立实时通信连接的装置的组成框图。图4所示的装置400可以为数据流转发服务器,应理解,该装置400与上述方法实施例中的数据流转发服务器对应,能够执行上述方法实施例涉及的数据流转发服务器执行的各个步骤,该装置400的具体功能可以参见上文中的描述,为避免重复,此处适当省略详细描述。
图4所示的装置400包括至少一个能以软件或固件的形式存储于存储器中或固化在该装置中的软件功能模块,图4所示的装置400包括:创建单元410,用于在获取到会话描述协议SDP提议信息后,创建用于处理网络地址转化NAT会话遍历实用工具STUN请求消息的系统资源;接收单元420,用于接收客户端发送的所述STUN请求消息;处理单元430,用于根据所述系统资源的创建完成情况,进行请求处理,所述进行请求处理包括保存所述STUN请求消息或查找所述STUN请求消息。
在一种实施方式中,所述处理单元在根据所述系统资源的创建完成情况,进行请求处理时,具体用于在确定所述系统资源未创建完成的情况下,保存所述STUN请求消息。
在一种实施方式中,处理单元在根据所述系统资源的创建完成情况,进行请求处理时,还具体用于:在所述系统资源的创建完成之后,查找获得所述客户端发送的STUN请求消息;直接使用所述系统资源根据查找到的所述STUN请求消息生成STUN响应消息。
在一种实施方式中,所述处理单元还用于在查找所述客户端发送的STUN请求消息之后,清空已经保存的所述STUN请求消息。
在一种实施方式中,所述SDP提议信息包括提议请求标识,所述STUN请求消息包括请求标识,所述处理单元在查找获得所述客户端发送的STUN请求消息时,具体用于将接收到的提议请求标识和已保存的请求消息中的请求标识进行匹配,根据匹配结果查找获得所述STUN请求消息。
在一种实施方式中,在获取到会话描述协议SDP提议信息后,处理单元还用于,保存所述提议请求标识,所述提议请求标识包括客户端标识和信令服务器标识,所述客户端标识和所述信令服务器标识为预设固定长度的随机字符串。
在一种实施方式中,所述接收单元在接收客户端发送的所述STUN请求消息时,具体用于在所述系统资源的创建完成之后,接收到所述客户端发送的STUN请求消息;
所述处理单元在根据所述系统资源的创建完成情况,进行请求处理时,具体用于直接根据所述客户端发送的STUN请求消息生成STUN响应消息。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置的具体工作过程,可以参考前述方法中由数据转发服务器执行的对应过程,在此不再过多赘述。
如图5所示,本申请的一个实施例提供一种电子设备500,该电子设备500包括:存储器510、处理器520以及存储在存储器510上并可在处理器520上运行的计算机程序,其中,处理器520通过总线530从存储器510读取程序并执行所述程序时可实现如上述任意实施例中由数据流转发服务器执行的方法。可选的,图5所示的设备还可以包括收发器,该收发器可以用于数据流的发送和/或接收。
处理器520可以处理数字信号,可以包括各种计算结构。例如复杂指令集计算机结构、结构精简指令集计算机结构或者一种实行多种指令集组合的结构。在一些示例中,处理器520可以是微处理器。
存储器510可以用于存储由处理器520执行的指令或指令执行过程中相关的数据。这些指令和/或数据可以包括代码,用于实现本申请实施例描述的一个或多个模块的一些功能或者全部功能。本公开实施例的处理器520可以用于执行存储器510中的指令以实现上述所示的由数据流转发服务器执行的方法。存储器510包括动态随机存取存储器、静态随机存取存储器、闪存、光存储器或其它本领域技术人员所熟知的存储器。
本申请的一个实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时可实现如上述实施例提供的上述方法中的任意实施例中由数据流转发服务器执行的方法。
本申请的一个实施例还提供了一种计算机程序产品,所述的计算机程序产品包括计算机程序,其中,所述的计算机程序被处理器执行时可实现如上述实施例提供的上述方法中的任意实施例中由数据流转发服务器执行的方法。
应注意,本发明实施例中的处理器(例如,图5中的处理器)可以是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(digital signal processor,DSP)、专用集成电路(application specificintegrated crcuit,ASIC)、现成可编程门阵列(field programmable gate array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
可以理解,本发明实施例中的存储器(例如,图5中的存储器)可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(read-only memory,ROM)、可编程只读存储器(programmable ROM,PROM)、可擦除可编程只读存储器(erasable PROM,EPROM)、电可擦除可编程只读存储器(electricallyEPROM,EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(dynamic RAM,DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(doubledata rate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhancedSDRAM,ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM,SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM,DR RAM)。应注意,本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本申请实施例涉及到的应用程序包括安装在请求端上的任何应用,包括但不限于浏览器、电子邮件、即时消息服务、文字处理、键盘虚拟、窗口小部件(Widget)、加密、数字版权管理、语音识别、语音复制、定位(例如由全球定位系统提供的功能)、音乐播放等等。
应理解,本发明实施例中的收发单元或收发器也可以称为通信单元。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时,全部或部分地产生按照本发明实施例该的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digitalsubscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,高密度数字视频光盘(digitalvideo disc,DVD))、或者半导体介质(例如,固态硬盘(solid state disk,SSD))等。
在本说明书中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如,部件可以是但不限于,在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示,在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中,部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外,这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据,例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
应理解,说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此,在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外,这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解,在本发明的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
另外,本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
应理解,在本发明实施例中,“与A相应的B”表示B与A相关联,根据A可以确定B。但还应理解,根据A确定B并不意味着仅仅根据A确定B,还可以根据A和/或其它信息确定B。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接,也可以是电的,机械的或其它的形式连接。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
总之,以上所述仅为本发明技术方案的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。