异构数据流的通用传输架构的制作方法

阅读：评论：0

异构数据流的通用传输架构
相关申请的交叉引用
1.本技术要求申请号为17/319,738，申请日为申请日为2021年5月13日的美国专利申请；和申请号为17/354,657，申请日为2021年6月22日的美国专利申请的优先权。
技术领域
2.本发明涉及网络通信技术，更具体而言，本发明涉及一种异构数据流的通用传输架构技术。

背景技术：

3.在网络通信中，传输层可以向应用层提供服务。根据不同的网络协议，服务可以包括面向连接的通信、可靠传输、避免拥塞、纠错、流量控制等服务。应用层可能根据应用场景不同而有不同的传输层要求，例如控制命令的可靠传输、多媒体流的不可靠传输等。传统的解决方案是使用现有协议或设计特定协议以满足特定场景的需要。因此，针对各种应用场景的复杂系统通常必须使用多个协议来满足完整的通信需求，从而导致系统架构和网络管理更加复杂。

技术实现要素：

4.本发明提供了一种用于实施异构数据流传输的通用架构的方法、设备和系统。
5.一方面本发明提供了一种用于在接收设备的发送应用程序和接收应用程序之间进行通信的设备。该设备包括处理器，所述处理器在发送应用程序和接收应用程序之间建立用于传输数据的流；从发送应用程序接收第一请求，将元数据传输到接收应用程序；从发送应用程序接收第二请求，将应用程序数据传输到接收应用程序；确定一个包括应用数据和元数据的帧小于或等于最大帧容量后，则构建该帧时将包括应用数据和元数据；并将该帧以数据包的形式发送至接收设备。
6.第二方面，本发明提供了一种用于在接收设备的发送应用程序和接收应用程序之间进行通信的方法。该方法包括构建一个流，用于在发送应用程序和接收应用程序之间传输数据；从发送应用程序处接收第一请求，将元数据传输到接收应用程序；从发送应用程序处接收第二请求，将应用程序数据传输到接收应用程序；确定一个包括应用数据和元数据的帧小于或等于最大帧容量后，则构建该帧时将包括应用数据和元数据；并将该帧以数据包的形式发送至接收设备。
7.第三方面，本发明提供了一种包含可执行指令的非暂时性计算机可读存储介质，当处理器运行所述可执行指令时，将执行的操作为，搭建接收设备的发送应用程序和接收应用程序之间进行通信的传输架构。这些操作包括：建立一个流，用于在发送应用程序和接收应用程序之间传输数据；从发送应用程序处接收第一请求，将元数据传输到接收应用程序；从发送应用程序处接收第二请求，将应用程序数据传输到接收应用程序；确定一个包括应用数据和元数据的帧小于或等于最大帧容量后，则在构建该帧时将包括应用数据和元数
据；并将该帧以数据包的形式发送至接收设备。
附图说明
8.在阅读以下详细描述时参考附图将有助于更好地理解本发明的内容。需要强调的是，根据惯例图示中各个部分并不是按比例绘制的。相反，为了清楚起见，附图中对各个不同部分的尺寸做了任意扩大或缩小。
9.图1是根据本发明实施方案所绘制的可搭建异构数据流的通用传输架构的环境示例图。
10.图2是根据本发明实施方案所绘制的用于描述异构数据流的通用传输架构的系统示例图，以系统200表示。
11.图3是一个数据包的结构示例图。
12.图4是一个初始数据包的结构示例图。
13.图5是一个数据包的结构示例图。
14.图6是一个帧的结构示例图。
15.图7是一个数据流帧的结构示例图。
16.图8是一个确认帧的结构示例图。
17.图9是一个关闭帧的结构示例图。
18.图10是一个反馈帧的结构示例图。
19.图11是用于传输元数据的技术的一个示例流程图。
20.图12是一个捎带确认的示例图。
21.图13是使用异构数据流通用传输架构的程序代码的示例图。
具体实施方式
22.现有的技术中已实现了通过网络进行通信的几种模型。以两个模型为例，一个是开放系统互连(osi)模型，一个是传输控制协议/互联网协议(tcp/ip)模型。除此之外还存在其他的模型。本文不对这些模型再做赘述，因为其无助于理解本发明所述的异构数据流的通用传输架构。但是仍会提供这些模型的高级描述，以便于理解上下文。
23.osi模型是众所周知的七层参考模型，它描述了其中的系统或应用可以通过网络进行通信的各项功能。该模型包括物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。物理层是最低层，指将设备连接到传输介质的电气或物理接口。数据链路层从物理层处接收原始数据并将它们打包成帧。网络层负责将数据组织成数据包，并在多个网络之间传输数据包。传输层处理应用程序的端到端传输。会话层是管理设备之间通信会话的软件层。表示层用于管理数据格式和呈现，例如通过在应用程序之间转换数据格式。应用层用于允许应用程序之间的通信。
24.tcp/ip也是一种通过网络在设备之间进行端到端通信的模型。tcp/ip模型包括链路层、网络层、传输层和应用层。链路层的作用可以被视作是类似于osi模型中的物理层和数据链路层相结合所提供的服务。网络层的作用可以被视作类似于osi模型中网络层所提供的服务。传输层的作用可被视作类似于osi模型中传输层所提供的服务。应用层的作用可被视作类似于osi模型中会话层、表示层和应用层相结合所提供的服务。
25.上述任何一种模型(或其他模型)中的传输层可以实现用于错误控制、网络拥塞控制、数据重传(如丢失数据重传)、接收数据的确认、重复数据的删除(如丢弃接收到的重复数据)等的的机制。传输层可以为应用程序的通信需求提供数据通道。
26.应用程序的通信需求(如服务质量)可以因任务而异或因数据类型而异。数据类型可以包括但不限于文件、、web内容、实时音频/视频数据流、控制命令等等。例如，在实时通信(rtc)会话中，用户可以向另一个用户发送文本消息或传输文件。例如，在rtc会话中通信的用户可能可以看到(如通过视频数据)和听到(如通过音频数据)彼此。因此，rtc会话可进行数据传输的数据类型包括：必须完全无损地接收的数据类型(文本消息和文件)；可以允许被丢失的数据类型；以及，相比其他数据类型可具有更高优先级的数据类型。如果文本消息的一部分或文件的一部分丢失(即接收方未收到)，则接收方可能无法重构或查看数据。另一方面，视频和音频解码可以允许数据丢失。此外，音频数据可以比视频数据具有更高的传输优先级。
27.传输层可提供适合于不同数据类型或应用需要的传输层协议。例如，可使用传输控制协议(tcp)和用户数据报协议(udp)。tcp协议可用于需要可靠、有序和错误检查的数据传输(如数据交付)；在不需要保证交付、不需要保证有序或不需要避免重复的情况下，则可以使用udp协议。例如，对于文件、、web内容、控制命令等的传输，由于其可靠性要求，则tcp可能是更合适的。另一方面，对于时间敏感的实时音频/视频数据流的传输，则可以使用udp。除此之外也可以使用其他协议，例如appletalk交易协议(atp)、数据包拥塞控制协议(dccp)、光纤通道协议(fcp)、流控制传输协议(sctp)、结构化流传输(sst)，特定应用程序的自定义协议，等等。
28.为适应应用程序(如通信模型的应用层)的不同通信需求或任务，应用开发者可能必须从一个或多个可用协议中进行选择和/或设计特定协议以满足特定的应用程序的用例或任务。一个应用程序可以使用多个协议来满足完整的通信需求。
29.如果必须同时使用多个协议，会使应用程序的开发复杂化，并且会导致系统(如应用程序)架构和网络管理的进一步复杂化。本领域技术人员应该了解，由于不同协议之间的实现原理不同，例如在tcp和udp之间的竞争和冲突情况下，应用程序可能无法在特定的网络场景中实现最佳的整体传输效率。
30.本发明所述的用于异构数据流的通用传输架构(utf)可以满足各种传输要求(例如可靠和不可靠的数据流传输)，从而可以解决上述问题。下文也将阐述如何通过灵活的配置和自适应方法来满足各种传输要求。utf定义了一种协议，可用于传输可靠和不可靠的数据。即使utf使用的底层协议是不可靠协议(如udp)，也可以对丢失或可能丢失的数据进行重传。
31.utf可以是包括两层的分层协议：会话层和连接层，详见下文所述。会话层可管理所有应用程序流，并且可以将流实际数据封装到流帧中。会话层为可靠传输流和不可靠传输流的抽象(如透明等)管理提供接口。会话层还可用于管理帧重传。连接层可以处理(如管理、确定等)网络状况。连接层可将丢失(或可能丢失)的帧通知给会话层。会话层又可以将丢失的帧通知给应用层。
32.utf可用于传输具有不同要求(例如要求不同的可靠性、优先级或其他要求)的多个数据流。utf可以提供将传输控制与可靠性管理分离的分层模型，从而提供可以复用多个
流以满足异构应用流需求的通用传输协议。应用程序(如应用程序开发人员)可以通过应用程序编程接口(api)使用utf。例如，可以通过调用(例如，请求等)api来创建不同的流。例如，一个api可用于创建可靠流。又如，另一个api可用于创建不可靠流。在一个实施方案中，不可靠流可用于实时应用程序(如传输等)，例如在视频、音频或即时消息通信等场景中。在另一实施方案中，为满足实时传输的要求，不可靠流可执行(如采用、支持、使用等)一种或多种技术或策略来减少延迟，例如前向纠错、在预定时间内重传丢失的数据包，或丢失数据包预定的重传超时等。为满足实时传输要求而配置的不可靠流在本发明中被称为部分可靠流。其他api可使用所创建的流传输或接收数据。
33.通过使用本发明所述的utf，对于创建的流和/或对于使用流传输的实际数据，应用程序不需要管理拥塞控制，比如必须确定时间发送数据包以免网络拥塞等；并且也不需要管理丢包或潜在的丢包情况。
34.utf采用了新的技术和结构来实现下列操作：确认接收方接收到数据包和帧；在发送方确认接收方发出的确认；元数据的传输和确认；以及拥塞控制。这些技术和结构可以简化应用程序的开发并减少网络流量，从而减少对处理、内存、存储资源或网络带宽的投资，从而实现减排，详见下文所述。
35.图1是可使用异构数据流的通用传输架构的环境示例图，以环境100表示。如图1所示，环境100可以包括多个设备和网络，如设备102、设备104和网络106。所述设备可以由一台或多台计算机的任何配置来实现，如微型计算机、大型计算机、超级计算机、通用计算机、专用/特别用途计算机、集成计算机、数据库计算机、远程服务器计算机、个人计算机、笔记本电脑、平板电脑、手机、个人数据助理(pda)、可穿戴计算设备或计算服务提供商(如网络主机或云服务提供商)提供的计算服务。
36.在一些实施方案中，可以采用多组计算机的形式，并且各个计算设备可以放置于不同的地理位置并可以通过网络彼此通信。虽然某些操作可以由多台计算机共享，但在一些实施方案中，可以为不同的计算机分配不同的操作。在一些实施方案中，环境100可以使用具有计算机程序的通用计算机来实施，运行该计算机程序时可执行本发明所述的相应的方法、算法和/或指令。此外，也可以使用包含专用硬件的专用计算机/处理器来运行本发明所述的任何方法、算法或指令。
37.设备102可以包括处理器108和存储器110。处理器108可以是能够管理或处理数据的任何类型的设备。术语“信号”、“数据”和“信息”可互换使用。处理器108可以包括，中央处理器(如中央处理单元，即cpu)、图形处理器(如图形处理单元，即gpu)、知识产权(ip)内核、应用程序-特定集成电路(asic)、可编程逻辑阵列(如现场可编程门阵列，即fpga)、光学处理器、可编程逻辑控制器、微控制器、微处理器、数字信号处理器或任何其他合适的电路中任意数量的组合。处理器108还可以分布在可以直接适配或经由网络连接的多台机器上(如每台机器或设备配有一个或多个处理器)。
38.存储器110可以是能够存储代码和数据的任何暂时或非暂时性的设备，这些代码和数据可由处理器访问(通过诸如总线)。本发明所述的存储器110可以包括，随机存取存储器设备(ram)、只读存储器设备(rom)、固件、光盘、磁盘、硬盘驱动器、固态驱动器，闪存驱动器、安全数字(sd)卡、记忆棒、紧凑型闪存(cf)卡或任何合适类型的存储设备的任意组合。存储器110也可以分布在多个机器或设备上，诸如基于网络的存储器或基于云的存储器。存
储器110可以包括数据、操作系统和一个或多个应用程序。所述数据可以是用于处理的任何数据(如音频流、视频流或多媒体流)，应用程序可以包括由处理器108执行的指令，以生成控制信号，这些控制信号可用于执行本发明所述方法或过程中的各项功能。
39.在一些实施方案中，设备102还可以包括辅助存储设备(如外接存储设备)。在高处理需求时，所述辅助存储设备可提供额外的存储空间。辅助存储设备可以是任何合适的非暂时性计算机可读介质形式的存储设备，如只读存储器设备(rom)、光盘、磁盘、硬盘驱动器、固态驱动器，闪存驱动器、安全数字(sd)卡、记忆棒，或紧凑型闪存(cf)卡等。此外，辅助存储设备既可以是设备102的组件，也可以是多个设备通过网络访问的共享设备。在一些实施方案中，存储器110中的应用程序可以全部或部分地存储在辅助存储设备中，并根据处理需要加载到存储器110中。
40.设备102还可以包括输入/输出(i/o)设备(即，i/o设备112)。i/o设备112可以是任何类型的输入设备，如键盘、数字按键、鼠标、轨迹球、麦克风、触敏设备(如触摸屏幕)、传感器或手势感应输入设备。i/o设备112也可以是向用户传输视觉、听觉或触觉信号的任何输出设备，如显示器、触敏设备(例如触摸屏)、扬声器、耳机、发光二极管(led)指示灯或振动电机等。例如，i/o设备112可以是用于呈现图形数据的显示器，如液晶显示器(lcd)、阴极射线管(crt)、led显示器或有机发光二极管(oled)显示器。在一些情况下，输出设备也可以作为输入设备，如触摸屏。
41.设备102还可以包含通信设备114，从而可以通过网络106来与另一个设备进行通信。网络106可以是任何类型的通信网络的任意组合，如无线网络或有线网络。无线网络可包括例如wi-fi网络、蓝牙网络、红外通信网络、近场通信(nfc)网络、蜂窝数据网络等。有线网络可包括，例如以太网(ethernet network)。网络106可以是局域网(lan)、广域网(wan)、虚拟专用网络(vpn)或互联网。网络106可包括多台服务器计算机(简称“服务器”)。服务器可以相互连接，一个或多个服务器也可以连接到终端用户设备，例如设备102和设备104。通信设备114可以包括用于发送和接收数据的任何数量设备的任意组合，所述设备如应答器或收发器设备、调制解调器、路由器、网关、有线网络适配器、无线网络适配器、蓝牙适配器、红外适配器、nfc适配器、蜂窝数据天线等。
42.与设备102类似，设备104配备了处理器116、存储器118、i/o设备120和通信设备122。设备104的元件116-122的运行可类似于设备102中的108-114。例如，设备102可以包括(或者说，例如，执行，运行等)向设备104发送数据的发送应用程序，且设备104可以包括从设备102接收数据的接收应用程序，反之亦然。因此，设备设备102和104均可以同时作为发送方和接收方。设备102可通过网络106与设备104通信。设备102和104还可与连接到网络106的其他设备(未示出)进行通信。设备102和设备104可以包括(或者说发送应用程序可以使用/或者说接收应用程序可以使用)utf通过网络进行通信。应注意的是，设备102和104的部分功能并不必以相同的方式来运行。
43.还应注意的是，设备102、设备104以及系统100的部件或组件并不局限于图1中所示的元件。在不脱离本发明的范围的情况下，设备102和104以及环境100可以包括更多或更少的部件、组件，以及硬件或软件模块，以用于使用utf执行与网络通信相关或之外的其他各种功能。
44.图2是用于说明异构数据流的通用传输架构的系统200的示例图。系统200包括用
户设备204和网络206。用户设备(如设备中的应用程序)在本发明中也称为发送方，可以通过网络206使用utf 202向另一个用户设备(未示出)传输数据。所述的另一个设备在本发明中被称为接收方。用户设备204(即发送方)可以是图1中的设备102或设备104，则接收方可以是设备102或设备104中的另一个。网络206可以是图1中的网络106。发送方(如用户设备204)也可以是数据的接收方。因此，用户设备204可以同时是发送方和接收方。
45.utf 202可以包含在用户设备204中。例如，utf 202可以是用户设备204的一个模块。网络206的服务器也可以包含utf 202模块。需要注意的是，接收方也可以包括其自己的utf 202，并且使用相同的数字序号来指代接收方的utf 202模块。例如，可将utf 202作为可由计算设备执行的软件程序(如软件模块、库等)，所述计算设备例如用户设备204，或图1中的设备102或设备104。所述软件程序可包含机器可读指令，该指令可存储在存储器(如存储器110)中，并且当处理器(如图1的处理器108)运行该指令时，可以使计算设备执行本发明所述的操作。utf 202也可以使用专门的硬件或固件来实施，或者也可以使用多个处理器、存储器或两者兼而有之。
46.utf 202可包括会话管理模块208和连接管理模块210。会话管理模块208可包括流工厂212、流管理模块214和调度模块216。连接管理模块210可以包括丢包检测模块220、数据包管理模块218、网络拥塞控制管理模块224和确认管理模块222。在一些实施方案中，还可以添加附加模块，进行模块组合，和/或去掉模块。
47.会话管理模块208可用于管理流。应用程序可使用会话管理模块208的api来创建(和销毁)和管理流。流可以被定义为，应用程序(如在用户设备204上执行的应用程序)通过网络206向/从另一个计算设备上执行的另一个应用程序发送/接收(根据时间的进程)的数据元素序列。流可以表示(如实现、用于等)可靠的或不可靠的传输。重传控制功能封装在每个流本身中(或者更准确地说，封装在流管理本身中)。
48.会话管理模块208可以将流的实际数据(如要发送的数据)封装到流帧中。流帧可以是具有特定(如确定性、已知、可预测等)结构和语义的数据容器，使得接收方可以明确地解析(如使用、读取等)接收到的流帧的内容。根据本发明所述，除了流帧之外，也可以采用其他形式的帧。
49.客户端应用程序可以在执行客户端应用程序的客户端设备与另一设备(如服务器或另一客户端设备)之间建立连接。在建立连接之后，客户端应用程序可以使用流工厂212的api来创建一个或多个流。创建流可以包括为数据流分配优先级。元数据(本发明也称为定制元数据、应用元数据或流元数据)可以与所述流相关联。元数据可以在创建流时或在使用流发送应用程序数据之前，与流相关联。创建流可以包括指定自定义的元数据。在一个实施例中，元数据可以是不变的。也就是说，在发送方和接收方相互连接期间，当流处于打开状态时，发送到接收方的流元数据不会在后期被更改。
50.在不失一般性原则下进一步阐述，在多媒体通信系统中，可以创建三个流。信号信道可通过具有最高优先级的可靠流进行通信。音频或视频流则可使用不可靠流，其中音频流的优先级可以比视频流更高。通过信令信道传输的自定义元数据可以携带音频或视频流的描述。例如，元数据可以包括标准(如h.264、h.265、av1等)，在使用视频流传输之前根据该标准对视频数据进行编码。如果没有这样的元数据，接收方可能无法正确解码视频数据。在另一个实施例中，元数据可以被包含在音频或视频流的数据包中。
51.流管理模块214可以为发送的流中的每一帧维护与该流相关联的相应记录。相关的记录可以包括帧的当前状态等。所述的当前状态可用于表明帧是成功传输还是丢失，详见下述。
52.调度模块216对用于传输的帧进行优先级排序。调度模块216可以使用自定义的配置对帧进行优先级排序。调度模块216可以根据帧的优先级将帧传送到底层连接管理模块210，如箭头226所示。例如，如上文所述，音频帧可以在视频帧之前传输，因为音频流在创建时就具有比视频流更高的优先级。音频帧也可以比视频帧进行更有效地传输，视频帧可能需要比音频数据多得多(如10倍或20倍)的带宽来传输。因此，在网络连接状况不佳或低带宽网络条件下，通过优先传输音频帧，即使无法(使用视频数据)立即看到发送方用户，接收方用户实际上也可以立即听到发送方用户的声音。
53.调度模块216可以基于相应流的配置优先级来确定帧的优先级。调度模块216向连接管理模块210传送(如提供、切换、传送等)帧，如箭头226所示，其表明对连接管理模块210发送通过网络206传输帧的请求。调度模块216可以安排何时发送相应的下一帧。调度模块216可以在将流帧传送到连接管理模块210之前对其进行优先级的排序。
54.在一个实施方案中，调度模块216可以使用最大-最小公平策略，根据每个流的优先级来调度流帧。在另一个实施方案中，调度模块216可以使用不同的策略，来使用数据包管理模块218、拥塞控制管理模块224收集的统计数据、其他统计数据或其组合来调度流帧，从而实现最佳的整体传输。
55.连接管理模块210可以将帧(如流帧或其他帧)封装到连接数据包中并且使用底层协议将数据包发送出去。也就是说，连接管理模块210可以将多个流帧组合成一个数据包以供在网络上传输。底层协议可以是不可靠协议(例如udp)，也可以是可靠协议(例如tcp)或某些其他协议。当底层协议为不可靠协议(如udp)时，重传控制可由utf 202进行。当底层协议为可靠协议(如tcp)时，重传可由可靠协议本身进行处理，而此时utf 202可能无法控制重传。
56.数据包管理模块218可将数据包序列化(在发送到接收方时)和反向序列化(从发送方处接收时)。如图3-5所示，数据包可以具有预定义格式(如结构)，该格式用于描述数据包中所包含的内容。例如，数据包可以包括流帧、确认帧(或简称为ack帧)、一些其他帧或以上形式的组合。
57.数据包管理模块218可以管理缓存策略。数据包管理模块218可以将发送到网络206的数据包进行缓存。数据包管理模块218可以维护由连接管理模块210发送(如通过网络206传输)的数据包的记录。当从接收方接收到对数据包的确认时，数据包管理模块218可以更新对应于确认数据包的记录。当一个数据包被确认时，该数据包即可从缓存中删除。如果数据包未被确认，则连接管理模块210可以通知会话管理模块208告知包含在数据包中的帧已丢失。会话管理模块208即可将该帧标记为丢失。在一个实施方案中，会话管理模块208可以通知该帧所属的流(或其应用程序)告知该帧已丢失。
58.数据包可以包括零个或多个流帧和零个或多个确认帧，如下文所述。由于确认是在数据包级别，因此当接收到确认时，缓存可用于确定哪些流帧已被确认和/或哪些确认帧已被接收方接收。在接收到确认后，连接管理模块210随即可将该确认信息告知会话管理模块208，如箭头228所示。将数据包的确认信息告知会话管理模块208，则意味着通知会话管
理模块208对数据包中封装(如包括等)的流帧的确认。在接收到该通知后，流管理模块214随即更新流帧的记录，记录表明该帧已被成功送达。
59.丢失检测模块220可用于检测丢失的数据包。传输的每个数据包都包含一个数据包序号。所述确认可以包含在接收方处接收到的数据包序号。在所述确认中包含数据包序号则意味着该确认可以包含该数据包序号所属的一个序号范围，详见图8所述。在一些情况下，丢失检测模块220可以确定未被确认的数据包即为丢失的数据包(即未被接收方处接收到)。根据已确认的数据包可得知已丢失的数据包。例如，如果带有数据包序号10、11、12和13的数据包被发送，但只有数据包序号范围11-13中的数据包被确认，则丢失检测模块220可以确定序号为10的数据包已丢失(即未被接收方接收)。
60.在一个实施方案中，可将未确认的数据包重新传送。当丢失检测模块220检测到已丢失的数据包后，则丢失检测模块220将封装在丢失的数据包中的流帧通知流管理模块214，如箭头230所示。数据包管理模块218中所述的缓存可用于确定哪些流帧包含在丢失的数据包中。在一个实施方案中，流管理模块214可以将丢失的帧依次通知给流(或其应用程序)。
61.在一个实施方案中，流管理模块214可以根据流的类型、自定义要求、其他标准或以上的组合来确定如何对丢失帧做进一步处理。例如，如果丢失的流帧属于可靠流，则流管理模块214可以继续重传流帧，直到成功接收到流帧(即被确认)。又如，如果丢失的流帧属于不可靠的流，则流管理模块214可以丢弃该流帧。在另一实施方案中，流管理模块214可以根据流配置设置或utf配置设置将属于不可靠流的丢失流帧重传，重传的次数为预定的次数。在另一个实施方案中，api可用于向流管理模块214提供(如由应用程序开发者)指令(如以回调函数的形式)，用于对丢失帧采取自定义化的、针对特定应用程序的处理方式。在另一个实施方案中，重传的决定不是由流管理模块214来控制，而是由流管理模块214将丢失的帧通知流，并且使用该流的应用程序可基于应用需求来决定是否对丢失的帧进行重传。
62.在一些情况下，接收方可能已经接收到数据包，但确认本身可能会被丢失。按照上述逻辑，丢失检测模块220可能错误地推断出该数据包被丢失。因此，确认的丢失可能会导致不准确的丢失检测，进而可能导致不必要的重传。为了防止不准确的丢失检测，下文及图8中阐述了一种更为有效的确认机制。
63.对于发送到接收方(即流内容的接收方)的每个数据包，数据包管理模块218可维护相应的记录，该记录包括数据包被发送的时间和数据包的状态。所述状态可以是传输中状态(即数据包已发送但尚未被接收方确认)、已确认状态(即数据包已被接收方确认接收)、丢失状态(即丢失检测模块220认为数据包已丢失)、伪丢失状态(即数据包被认为丢失但实际上已被接收方确认)，以及其他形式的状态，可以具有一个或多个状态，也可以是这些状态的组合。在接收方的连接管理模块210处，当从底层网络协议接收到数据包时，可以首先在接收方的连接管理模块210中处理这些数据包。由接收方的确认管理模块222所生成的确认帧中可包含接收到的数据包序号。可将确认帧发送回发送方。在一个实施方案中，接收方可以根据网络情况来确定何时发送确认帧。因此，也可以动态调整确认帧的传输。
64.接收方的连接管理模块210从接收的数据包中提取流帧并将提取的数据包传送到接收方的会话管理模块208。接收方的流管理模块214可以从流帧中去除应用程序的实际数据。如果传输的是可靠流，则接收方的流管理模块214可以立即向应用层提供应用程序的实
际数据。如果传输的是可靠流，接收方的流管理模块214可以对应用程序的实际数据进行缓存以便重新排序。
65.拥塞控制管理模块224可以确定何时传输数据包以避免网络206发生拥塞。当传输速率高于网络的带宽时就有可能导致拥塞。在一个实施方案中，未确认数据包的重复重传也可能导致网络拥塞。拥塞控制管理模块224可以收集或计算网络统计数据(例如数据包级别的统计)，从而计算带宽估值并控制何时传输数据包。所述数据包级别的统计可以包括，往返时间、单向延迟和抖动、延迟梯度、丢包率、丢包范围分布、可用带宽估值、其他统计数据或以上统计数据的组合。拥塞控制管理模块224可基于统计来设置(如更新、确定、计算、设置、选择等)拥塞控制参数。所述拥塞控制参数可包括拥塞窗口、发包速率、其他参数或以上参数的组合。
66.因此，在一个实施方案中，连接管理模块210可以使用拥塞控制管理模块224(如由拥塞控制管理模块224接收、收集、聚合等的数据)来确定发送数据包的时间。丢失检测模块220可用于确定传输中的数据包是在何时丢失的。丢失检测模块220可以向会话管理模块208提供丢失信息。会话管理模块208可以依次通知发送的流告知数据已丢失。然后发送的流(或使用该流的应用程序)可以确定(如基于特定的应用程序需要)是否要重新传输数据。
67.图3是数据包的结构示例图，以结构300表示。除此之外utf也可以采取其他的数据包结构。数据包可由发送方发送，例如由图2中发送方的连接管理模块210通过网络206发送至接收方。接收方可以接收数据包，例如由图2中接收方的连接管理模块210通过网络206接收来自发送方的数据。数据包不能包含超过最大数据包大小的数据。换句话说，数据包的大小具有最大限度(例如以字节为单位)。需注意的是，一个数据包可以包含来自多个流的帧。
68.字段302可以用于表示数据包的类型。在一实施方案中，字段302可以具有第一值或第二值。所述第一值表示该数据包是在建立连接时并且在传输任何应用数据之前传输的初始数据包。所述第二值表示该数据包是一个数据包。参照图4和图5所述，第一值和第二值可以是常数值kinitial和kdata。
69.字段304表示数据包的序号。流中每个发送数据包可以具有(如由发送方的数据包管理模块218分配的)唯一序号。数据包序号依次递增。字段306表示要包含在数据包中的实际数据。
70.图4是初始数据包的结构示例图，以结构400表示。utf也可以具有其他初始数据包的结构形式。结构400在图3的数据包的结构的基础上做了进一步阐述，其中图3中的初始数据包类型为kinitial。初始数据包可用于初始化连接。如下文所述，建立连接的握手可以类似于tcp的三次握手，可在一个往返时间(rtt)内完成。
71.字段402表示数据包类型的值是kiinitial。字段404可以与图3中的字段304相同。图3中的字段306可进一步细化为字段406-430。字段406可表示用于生成数据包的utf协议的版本。例如，接收方可以使用版本信息来确定数据包的结构(如内容)和语义。例如，该版本可用于向后兼容。
72.字段408包括一组控制位(s、a、r、o、e、t)，每一个可以具有布尔值0或1。控制位s、a和r对应于两个tcp堆栈之间的三次握手。如果utf使用的底层协议是tcp协议，则可以使用控制位s、a和r。控制位s、a和r分别对应于三次tcp握手的值syn(同步序列号)、ack(确认)和rst(重置连接)。
73.控制位o表示“option”(选项)字段是否稍后出现在数据包的实际数据中。utf可以使用“option”字段。也就是说，“option”字段可以包含utf专用数据，但不包含应用程序的专用数据。例如，utf可以使用“option”字段来传输会话的配置信息。控制位e表示“early_data”(早期数据)字段是否稍后出现在数据包的实际数据中。在一个实施方案中，应用程序可以使用早期数据在握手的第一次往返中发送一些应用程序数据，而无需等待握手完成(即在握手完成之前)。除此之外“early_data”也可以具有其他用途。控制位t表示标签是否稍后出现在数据包的实际数据中。在一个实施方案中，utf可以使用标签来表示握手协议的配置(例如在握手期间是否使用加密)。除此之外标签也可以具有其他用途。
74.字段410包含acked_pkt_no，其为该初始数据包将要确认的数据包序号。acked_pkt_no从接收方发送到发送方。另一方面，largest_acked表示发送方从接收方接收的已确认的最大的数据包序号。也就是说，largest_acked是从发送方发送到接收方。
75.如果设置了控制位o(如具有布尔值1)，则字段412表示包括选项的字段414的长度(比如可以字节为单位)。如果设置了控制位e，则字段416表示包括早期数据的字段418的长度(比如可以字节为单位)。如果设置了控制位t，则字段420表示实际数据中存在的标签数量。在数据包大小保持小于或等于最大数据包的大小范围之内，可以采用任何数量的标签。图4中展示了两个标签的情况。但是，当设置了t控制位时，一个数据包可以包含一个或两个以上的标签。字段422a表示包含第一标签的数据的字段424a的长度。字段424a中包含了第一标签的数据。字段422b表示包含第二标签的数据的字段424b的长度。字段424b中包含了第二标签的数据。
76.图5是数据包的结构示例图，以结构500表示。除此之外utf也可以具有其他数据包结构。结构500在图3的基础上对数据包的结构做了进一步阐述，图3中数据包的类型为kdata。一个数据包可以封装不同类型和数量的帧。每个数据包可以包含一个或多个帧。
77.字段502表示数据包的类型的值为kdata。字段504可以与图3中的字段304相同。字段506包含接收方确认的最大数据包序号。换句话说，字段506包含值maximum_acked，也就是从接收方接收的已确认的最大数据包序号的值。根据从接收方接收到的确认帧可以确定从接收方接收到的已确认的最大数据包序号。接收方接收到的每个数据流包都包含已确认的最大(largest_acked)数据包序号。发送方可以使用largest_acked向接收方指示发送方收到来自接收方所确认的最大数据包序号。在数据包中包含largest_acked(所确认的最大的)数据包序号称为ack-ack机制(即对确认的确认)。ack-ack机制可以由确认管理模块222实现。
78.ack-ack机制可以解决由于反馈链路故障，如丢包、网络抖动、网络拥塞或其他链路故障导致的错误重传。在发送方，ack-ack机制可以将已确认的最大序号嵌入到每一个从发送方发送到接收方的数据包中。在接收到来自发送方的最大已确认序号后，接收方可以将当前确认序号和最大已确认序号之间的分布信息携带到接收方发送回发送方的确认包中。然后发送方可更新最大已确认序号并验证未确认的数据包以避免错误的重传。ack-ack机制可以根据不同的网络情况动态自适应地生效。也就是说，ack-ack机制可以根据网络情况动态地启用和禁用。如果网络状况良好(如没有连接状况不佳等情况)并且确认(ack)帧没有丢失(即被发送方接收到)，则不需要启用ack-ack机制。在不必要时启用ack-ack机制会导致字节浪费。如果发送方或接收方检测到确认反馈链路连接状况不佳或许多确认数据
包丢失，则可以自动启用ack-ack机制。
79.在一个实施方案中，接收方可以使用largest_acked数据包序号继续发送(和重新发送)确认，该确认是针对已接收到的但发送方还没有接收到确认的数据包。此外，根据largest_acked数据包序号，接收方不再对小于或等于已确认的最大数据包序号的数据包进行确认。
80.举例说明，发送方发送序号为1至100的数据包，而接收方接收到序号为1-70、75-90、93-96的数据包。接收方向发送方发送所有接收到的数据包的确认帧。确认帧如图8所示。但是，一些发送出的确认帧可能没有到达发送方。假设发送方收到了序号为1-70和76-78的数据包的确认帧。因此，发送方确定已确认的最大数据包序号为78。如果采用的是可靠流，则发送方继续发送序号为71-75的数据包直到它们被确认。如果采用的是不可靠流，则发送方不会重新传输序号为71-75的数据包。在另一实施方案中，utf可以将不可靠流(或部分可靠流)的序号为71-75的数据包进行重传，重传的次数为预定的次数(如，2、3、5或其他次数)。对小于或等于已确认最大数据包序号的数据包，接收方将不再进行确认。另外，在这种情况下，确认帧的字段810(即largest_observed_packet_number)将包含值96，详见图8所述。如图8所示，发送方可以使用确认帧中所空缺的数据包序号来确定要重传哪些数据包。如上所述，在一个实施方案中，是否重传帧是由应用层根据应用需求而定的。
81.继续上述实施方案，接收方接收包含largest_acked＝79的数据包。在接收到largest_acked＝79的数据包后，即使接收方已经发送了确认信息，接收方仍继续发送数据包80-90和93-96的确认帧。如图8所述，可以对数据包序号的范围进行确认。
82.字段508表示包括在数据包中的帧的数目。对于每个帧，相应的类型字段(如字段510)、相应的帧长度字段(如字段512)和相应的帧数据字段(如字段514)都被包含在数据包中。省略号518表示可以根据包含在数据包中的帧的数目(即字段508的值)重复字段510-514。只要数据包的总大小保持小于或等于最大数据包大小并且在拥塞控制管理模块224允许的范围内，数据包中可包含多数量的帧。
83.帧可以是流帧(即kstream类型值)、确认帧(即kackframe类型值)、关闭帧(即kclose类型值)或拥塞反馈帧(即kfeedback类型值)。除此之外也可以是其他帧的类型。流帧的结构详见图7所述。确认帧的结构详见图8所述。关闭帧的结构详见图9所述。拥塞反馈帧的结构详见图10所述。
84.图6是帧的结构示例图。utf也可以具有其他的帧结构。帧可以由utf的会话管理模块208创建，例如由图2中的流管理模块214创建，或者也可以由连接管理模块210中的模块创建。流管理模块214创建的帧被传输到连接管理模块210，如箭头226所示。连接管理模块210中的数据包管理模块218可以包括所述帧，或者可以将多个帧组合成数据包并通过网络206传输，如发送/接收箭头234所示。如上所述，对于接收到的数据包，数据包管理模块218可以提取接收到的数据包中所包含的帧，并将其中至少一些帧传输至会话管理模块208。
85.字段602可用于表示帧的类型。接收方可以使用该类型来确定帧的其余部分(如其余内容)的语义。除此之外也可以有其他不同的的帧类型。例如，帧类型可以包括流帧类型(则字段602可以具有常数值kstream)、确认帧类型(则字段602可以具有常数值kackframe)、关闭帧类型(则字段602可以是常数值kclose)和拥塞反馈帧类型(则字段602可以是常数值kfeedback)。
86.字段604和606的示例见图5中字段512和514。如图7-10所示，字段606可以包括不同的实际数据和数据结构，并且根据帧类型值(即字段602的值)的不同而具有不同的语义。帧不能大于最大帧的大小。
87.图7是流帧的结构示例图，以结构700表示。除此之外utf也可具有其他流帧结构。结构700在图6基础上对帧结构做了进一步阐述，其中图6的帧类型为kstream。流帧是包含应用程序数据的帧，也就是说，流帧可用于将应用程序数据传输到接收方。流帧可以有选择地包含选项数据或元数据。
88.在流帧中，类型字段(即字段702)的值是常数值kstream。字段704表示流帧的长度(比如可以字节为单位)。字段706可作为表示当前连接中生成流帧的该流的唯一标识符。字段708可包含两个标签(比如位)：选项标签(o)和元数据标签(m)。选项标签(o)可用于表示流帧是否包含选项数据。也就是说，当设置选项标签(o)时(比如具有布尔值1)，与选项相关的字段(即字段710和字段712)将包含在流帧中。元数据标签(m)可用于表示流帧是否包含元数据。即当设置元数据标签(m)时，与元数据相关的字段(即字段714和字段716)将被包含在流帧中。
89.当设置选项标志(o)时，字段710包含字段712的大小，其中字段712包含选项数据。当设置元数据标志(m)时，字段714包含字段716的大小，其中字段716包含元数据。字段718包含流的实际数据。字段718的大小可由接收方计算为(frame_length-opt_len-meta_len)。
90.图8是确认帧的结构示例图，以结构800表示。除此之外utf也可具有其他确认帧结构。结构800在图6的帧结构的基础上做了进一步阐述，图6的帧类型为kackframe。确认帧是由接收方(如接收方的确认管理模块222)创建并向发送方发送，以通知发送方表明接收方已接收到数据包。接收方可以确认数据包的范围。一个确认帧中可以有多个范围，在这些范围中有序号的空缺(如发送但未接收的数据包)。如上文所述，接收方可以不再在确认帧中对序号小于或等于largest_ack的帧进行确认。
91.根据本发明的确认帧使得发送方能够从接收方处获得关于是否接收到数据包的反馈。发送方可以使用获得的信息根据接收方的反馈优化数据包的传输。例如，发送方可以根据接收到的时间戳和接收到的范围分布，分别分析上行链路和下行链路性能，从而确定数据包传输的最优策略。举例说明，在一个实施方案中，发送方的拥塞控制管理模块224可以使用确认帧中包含的数据，来计算接收方和/或发送方的预估带宽；拥塞控制管理模块224还可以使用接收到的确认帧中的时间戳来计算抖动(例如上行链路的抖动和/或下行链路的抖动)。上行链路是指发送方用来向接收方传输数据包的网络链路。下行链路是指接收确认帧的网络链路，或者可以是说是接收方用于发送确认帧的链路。
92.上行链路性能可以由发送方根据上行链路统计数据来确定，所述上行链路统计数据由发送方维持与获得的反馈信息相关。获得的反馈信息使得能够将上行链路状态(如性能等)的分析与下行链路状态(如性能等)的分析解耦。这样，发送方的连接管理模块210可以更精确地评估传输质量。发送速率和接收速率之间的差异可以根据数据包序列的探测技术(packet-train-based probe techniques)进行计算。
93.通过将上行链路的状态与下行链路的状态解耦，可以确定(如推断等)未确认的数据包是否是由于上行链路的性能问题而丢失，如果是的话，则数据包将被重传；或者确定是
否因为下行链路性能问题导致确认帧丢失而导致数据包未被确认，这种情况下就不会重传该数据包，从而节省网络带宽，否则重新传输该数据包将会浪费网络带宽。
94.确认帧中包含的反馈信息可以包括每个数据包的接收时间戳和接收数据包序号的范围分布信息。例如，如图8所示，将接收到的最大数据包时间戳和接收到的最大数据包序号记录下来。其他信息则作为相对于最大数据包接收时间和数量为基准的增量值传输，详见特定数据包格式的实施方案。
95.在确认帧中，类型字段(即字段802)的值是常数值kackframe。字段804表示确认帧的长度(比如可以以字节为单位)。位806表示确认帧是否包含数据包接收时间戳(即字段822以及一个或多个字段824)。
96.字段808表示确认收到具有最大数据包序号的数据包的延迟时间(ack_delay)。也就是说，延迟时间可以是接收方收到具有largest_acked序号的数据包的第一时间与接收方发送即时确认帧的第二时间之间的时间差(比如以毫秒为单位).
97.字段810包含接收方接收到的最大数据包序号值(即值maximum_observed_packet_number)。字段812包含接收方接收到的带有最大数据包序号的数据包的时间戳(即largest_observed_recv_time)，接收方可以指接收方的数据包管理模块218。举例说明，接收方可能已收到序号为10-49、56-72和74的数据包。则largest_observed_packet_number为74。
98.字段814包括确认帧中的范围信息的长度。字段816包括确认帧中所包含的范围的数量。可以使用两个字段来描述范围，如字段818和820。字段818可表示从上一个范围到当前范围的数据包序号的空缺值(即next_range_gap)。字段820可表示当前范围的长度(即range_length)。举例说明，假设发送方发送了序号为50-100的数据包，但接收方没有收到数据包60-72、79-83和95-100。此时，largest_observed_packet_number为94；next_range_gap1可以是11(即94-83)；range_length1可以是5(即83-79+1)；next_range_gap2可以是7(即79-72)；range_length2可以是13(即72-60+1)。根据范围内帧的数目值(即字段814的值)，字段818-820可以重复，如省略号821所示。
99.字段822包括确认帧中的时间戳的数目。字段824包括从值largest_observed_packet_number(即字段810的值)到当前数据包序号的增量(如差异)。举例说明，假设largest_observed_packet_number值是100，确认帧中只有序号为80和70的数据包的到达时间戳，而数据包71-79已被丢失。这时，字段822的值为2；delta_number1(即第一个字段824)的值可以为20(即100-80)，且delta_number2(即第二个字段824)的值可以为30(即100-70)。对应于字段824，字段826包括从值largest_observed_recv_time(即字段812的值)到当前数据包的接收时间的相应增量。根据数据包接收的时间戳的数目(即字段822的值)，字段824-826可以重复，如省略号827所示。
100.在另一个实施方案中，第一个字段824(如delta_number4)(图中未示出)的值可以是第二个字段824(如delta_number3)(图中未示出)的紧接在前的值的增量，其中delta_numberl可以是相对于large_observed_packet_number的偏移量。继续使用上述实施方案，字段822的值可以为2；值delta_number1(即第一个字段824)可以为20(即100-80＝20)，而值delta_number2(即第二个字段824)可以为10(即80-70＝10)。
101.在不包含流帧的数据包中也可以传输确认帧。在包含其他流帧的数据包中也可以
携带确认帧。在含有其他流帧的数据包中携带其确认帧被称为捎带确认。如果将确认帧携带在数据包中，而包含(其他帧的)流帧的数据包(如kdata类型的数据包)的大小并不超过最大数据包大小，则可将该确认帧携带在数据包中。
102.确认捎带可以有效地降低确认帧的数据速率消耗，尤其是当网络流量非常大的时候。此外，如本发明所述，确认帧的特定数据包格式可以携带(如包括等)有用信息，如数据包接收时间戳，根据实时网络情况可以动态且自适应地采用确认捎带机制和ack-ack机制，从而提高各种应用场景下的ack性能。关于捎带确认的相关内容详见图12。
103.图9是关闭帧的结构示例图，以结构900表示。除此之外utf也可以具有其他的关闭帧结构。结构900在图6的基础上对帧结构做了进一步阐述，其中图6的帧类型为kclose。关闭帧可用于关闭特定的流或连接。任何一方(即发送方或接收方)都可以向另一方发送关闭帧。关闭帧表示关闭帧的发送方即将执行关闭动作。
104.在关闭帧中，类型字段(即字段902)的值是常数值kclose。字段904表示关闭帧的长度(比如可以以字节为单位)。字段906表示即将被关闭帧的发送方关闭的流的标识符。关闭帧还可用于表示一段连接(以及该连接中的所有流)将被关闭。例如，可设定字段906的预定义值(如0xffff或某个其他值)用于表示结束连接。
105.字段908可以表示关闭动作的错误代码。即，字段908可以表示关闭动作的原因。字段910可用于提供关于关闭动作的原因的更多细节。
106.在一个实施方案中，如果发送方发送出包含元数据的数据包，而在一定时间内未收到确认帧，则发送方可向接收方发送关闭帧。发送方可以向接收方发送一个关闭帧，表明发送了一个尚未初始化的流并且发送方正在关闭该流。然后发送方可以丢弃该尚未初始化的流的缓存流帧。
107.图10是反馈帧的结构示例图，以结构1000表示。除此之外utf也可以具有其他的反馈帧结构。结构1000在图6的帧结构的基础上做了进一步阐述，其帧类型为kfeedback。
108.反馈帧(或拥塞反馈帧)可用于向会话中的对方报告网络统计信息。也就是说，接收方和发送方都可以定期向对方发送反馈帧。反馈帧可以基于发送反馈帧的一方所收集到的网络统计信息来创建。连接中的一方的拥塞控制管理模块224可以收集网络统计数据，并使用该统计数据创建反馈帧。反馈帧可以包含在数据包中，并优先传输到会话对方。对方的拥塞控制管理模块224可以使用反馈帧进行拥塞控制。
109.在反馈帧中，类型字段(即，字段1002)的值是常数值kfeedback。字段1004表示反馈帧的长度(比如可以以字节为单位)。字段1006可表示丢包率，即表示丢失数据包的数量与发送的数据包总数的比率。字段1008表示delta_from_begin_ms，它可以是当前时间(如接收方创建反馈帧的时间)与创建连接的时间之间的时间差。也就是说，字段1008可以表示会话的当前持续时间(如长度等)。字段1014表示估算的带宽(如可以以千比特/秒为单位)，这是对反馈帧的发送方的上行链路每单位时间(如可以以秒为单位)可以传输的数据量的估算。字段1012可以表示自上一个反馈帧以来发送的千比特总数。字段1014表示包含统计数据的反馈帧所属的流的数量。字段1016表示数据包抖动。数据包抖动可以表示接收数据包延迟的变化。例如，发送方可以以均匀的间隔发送连续的数据包流。然而，在几种情况下(如接收方网络拥塞、不正确的排队、配置错误、其他情况或以上情况的组合)，接收方可能无法以均匀的间隔接收到数据包；相反，数据包之间的延迟也可以是变化的，而并非保持不
变。字段1016可以表示与平均值相差两个标准偏差内的抖动，该类抖动占所收集的抖动数据的95％左右。
110.字段1018表示数据包的平均排队时间。对于每个流，各自的字段1020表示流id，紧跟在后面的字段1022是表示该流传输的数据的每秒千比特(或千字节)数。例如，sent_kbpsn可以表示第n个流的带宽。省略号1023表示可能有多个字段1020-1022。
111.在一个实施方案中，utf可将至少一部分网络统计报告给应用层。例如，应用程序可以基于统计来修改应用程序的行为。举例说明，但不作为限制，在rtc会话中，当得知对方网络(即下行链路)连接状况不佳后，应用程序可以自动增加压缩比(如通过增加量化参数(qp))、降低帧率、暂时关闭视频流连接、采用一些其他策略，或以上策略的组合。
112.如图6所述，流帧可以包含元数据。元数据可用于描述流的基本特征。因此，必须保证元数据即使在不可靠的流中也能成功传输。例如，视频应用程序可以使用元数据来携带私有视频描述符。若无此描述符，视频可能无法被正确解码。
113.图11是用于传输元数据的技术的流程图，以技术1100表示。技术1100可以由通用传输架构的一个或多个模块来实现，如图2中的utf 202。技术1100可以由发送方实现，例如向接收方发送流数据的设备所属的应用程序。例如，技术1100可通过图1中的设备102或设备104运行的软件程序来实现。所述软件程序可以包含能够存储在存储器(如图1中的存储器110或存储器118)中的可读指令，并且当处理器(如图1的处理器108或处理器116)执行该指令时，可使相应设备执行技术1100。技术1100可以全部或部分地由图2中的流管理模块214实现。技术1100可以使用专门的硬件或固件来实现，也可以使用多个处理器和/或多个存储器。
114.技术1100采用可靠的、有保障的机制在不可靠的流中传输元数据。元数据可以是流标识符或流描述符。举例说明，在rtc会话中，多个用户(更具体而言，即在各自的用户设备上执行的多个rtc应用程序)可以使用各自的utf连接到服务器。服务器可将来自每个用户的视频流发送给所有用户。在建立连接时，服务器(即服务器上的rtc应用程序)可以向每个用户发送标识用户(如用户名、用户位置等)的流描述符信息(即元数据)，以便每个用户接收到的视频流可以被用户关联或识别。除此之外也可以采用其他元数据形式。
115.技术1100可以根据流帧(如图7中所述的流帧)中的元数据的存放情况来决定如何携带流帧中的元数据。为了减少通过网络发送的帧的数量，如果流帧中有足够的剩余空间来携带元数据，才会将元数据包括在流帧中。元数据可以与流帧(即kstream帧)中的应用程序数据(如实际数据)聚合。当元数据没有足够空间携带时，可以在独立的元数据帧中传输元数据。元数据帧是不包含实际数据的kstream帧(即流帧)。
116.此外，技术1100还实现了冗余传输机制，可以多次发送相同的元数据帧。冗余传输可用于减轻接收方下行链路连接状况不佳时可能会造成元数据丢失的情况，并可提高元数据帧从发送方成功传输(并被接收方接收)的机会。可将元数据重传，直到发送方收到元数据的确认帧。
117.接收方在成功接收到元数据(如果有元数据的话)之前可缓存来自不可靠流的应用程序数据。缓存应用程序数据可以保证不可靠流的应用程序数据不会因为元数据流丢失而被阻止发送。也就是说，尽管一些传统技术可能在传输应用程序数据之前先传输元数据(即元数据帧)，但utf可以在流(例如应用程序)帧中发送元数据。将元数据与应用程序数据
一起传输可确保在接收到元数据时接收方可立即使用应用程序数据。此外，有时候包含元数据的数据包可能会丢失，而随后的包括应用程序数据的数据包则被接收方接收到。此时接收方可以缓存应用程序数据，直到接收到元数据。举例说明，在rtc会话中，应用数据可以是视频或音频数据，因此接收方可以将那些与元数据一起接收的或在元数据之前接收的应用数据进行缓存，这样一旦接收到元数据，就可以在接收方处理缓存的视频和音频数据。
118.技术1100可以决定是否将元数据发送到接收方。例如，接收方的流工厂212接收到发送元数据的请求以及建立(如创建、初始化等)流的请求。在一个实施方案中，可以在向流管理模块214的请求中包含元数据。因此，如果流中有元数据，则utf可以在接收到元数据后才对用户数据进行处理。也就是说，如果应用程序从utf的会话管理模块208处接收到流的应用层数据，那其也接收应用数据和元数据(如果有元数据的话)。重申一下，本发明所述的协议机制可以用于不可靠的流中，以确保流级别的元数据的可靠传输，并在传输数据流之前将元数据传输给应用层。此外，通过将元数据与应用程序数据捎带在一起，可以避免传统上先传输元数据然后传输流数据而可能导致的延迟。
119.在1102处，技术1100将元数据传输到接收方。在一个实施方案中，元数据可以在元数据帧中发送，也可以连同应用数据一起在流帧中发送，如下文1106相关内容所述。例如，接收方的流管理模块214接收到发送应用数据至接收方的请求，流管理模块214可决定是否将元数据与应用数据一起包含在流帧中发送。
120.在1104处，流管理模块214获知是否已经接收到关于元数据的确认。可以在kackframe类型的帧中接收该确认，如图8所述。元数据被确认可以是指发送方接收到包含元数据的数据包的确认。如果已接收到确认，则技术1100终止操作。如果尚未收到确认，则将技术1100进行到步骤1106。
121.在1106处，流管理模块214决定元数据是否可以被包括在用于传输应用数据的流帧中。如上所述，流帧的大小不能大于最大帧的大小。因此，流管理模块214可以决定是否将元数据包含(如，存放，等)在携带应用数据的流帧中。如果可以将元数据包含在流帧中，则将技术1100进行到步骤1108以创建包括应用数据和元数据的流帧。流帧可以被发送到连接管理模块210，然后发送至接收方，如图2的箭头226所示。如果不能将元数据包含在流帧中，则将技术1100进行到步骤1110。
122.在1110处，技术1100确定时间增量(即当前时间与上次元数据传输的时间之间的时间差)是否大于最大阈值时间kmeta_frame_lost_interval。在一个实施方案中，步骤1110可以由流本身执行。如果时间增量大于最大阈值时间(kmeta_frame_lost_interval)，则技术1100进行到步骤1112，随即发送包含元数据的元数据帧。最大阈值时间可以是预期从接收方接收确认帧的最长时间。在一个实施方案中，该常数时间可以是固定的。在另一实施方案中，也可以基于任何接收到的反馈帧来调整该常数时间。如果自上次传输元数据以来还未达到最大阈值时间，则将技术1100进行到步骤1114。
123.在1114处，技术1000在重传元数据帧中的元数据之前等待，等待时间为最小阈值时间(kmeta_frame_send_interval)。通过最小阈值时间的等待，技术1100可以避免过于频繁地重传元数据。最小阈值时间可以是恒定的，也可以由拥塞控制管理模块224根据从接收方接收的反馈帧进行调整。在一个实施方案中，步骤1114可以由流本身执行。
124.如果还没有达到元数据的重传次数(如，4、5、10或一些其他重传次数)，则技术
1100返回到步骤1104，这在图11中并未示出。如果已经达到重传次数，则技术1100进行到步骤1116。如果在重传次数之后元数据未被确认，则技术1100可以推断：无论出于何种原因(如接收方不在线、网络中断等)，元数据的确认将不会被接收或元数据将不会被接收。因此，技术1100可以取消元数据的传输并终止会话。终止会话可以包括传送关闭帧，如图9所述。
125.图12是确认捎带的示例图，以1200表示。确认捎带1200示出了数据流包1202、确认数据包1204和捎带数据包1206。
126.数据流包1202包括udp数据包报头、流帧报头和流实际数据。在rtc会话中，流帧报头和流实际数据可以分别是多媒体帧报头和多媒体实际数据。确认数据包1204包括udp数据包报头、确认帧报头和确认实际数据。确认帧报头和确认实际数据详见图8中关于确认帧的描述。因此，如果将数据流包1202和确认数据包1204中的每一个数据包分开传输，那么其都包含各自的udp数据包报头。
127.而与之相反，捎带数据包1206仅包含一个udp报头，并且包括流数据包1202的多媒体帧报头和多媒体实际数据，以及确认数据包1204的确认帧报头和确认实际数据。这样可以减少网络中确认数据包的数据速率消耗。
128.在一个实施方案中，可以根据当前网络条件自适应地启用捎带机制。例如，在双向视频通信会话中，如果发送方的拥塞控制管理模块224检测到在下行链路方向发生网络拥塞，则可以在该方向(如从发送方到接收方)上自动启用捎带机制。在一个实施方案中，也可以动态配置和调整延迟确认机制(如tcp延迟确认机制以及一些其他延迟确认机制)。
129.图13是使用异构数据流的通用传输架构的程序代码示例，程序代码以1300表示。程序代码1300可以是在设备(如图1中的设备102或设备104，图2中的用户设备204等)上执行的应用程序的源代码。
130.第2行表示对图2中流工厂212的api调用。第4行是一个api调用，该调用将utf配置为使用udp作为底层网络协议进行通信。第10-11行示出了对流工厂212的api调用(如请求等)以创建可靠的流并设置流的元数据，该元数据将被传输到接收方。仅出于说明性目的，元数据是一个简单的字符串(即第11行所示的“this is my metadata”)。但是，本发明中元数据的形式并不限于此，而可以是被序列化后传输到接收方的任何类型。第13行示出了对流管理模块214的api调用以传输应用程序数据(即“application payload to send”)。应用程序数据可以是任何类型的数据。第13行还说明了应用程序可以为应用程序数据设置优先级(即“highestpriority”)。调度模块216可以使用优先级来确定应用数据何时被发送。第15-17行示出了一个回调，utf可使用该回调将接收到的流数据发送给应用程序。
131.第20-21行示出了对流工厂212的另一个api调用(如请求等)以创建不可靠的流并为该流设置元数据，该元数据将被传输到接收方。仅出于说明性目的，元数据是一个简单的字符串(即第21行所示的“this is my metadata”)。第23行示出了对流管理模块214的api调用以传输应用数据(即“application payload to send”)。应用程序数据可以是任何类型的数据。第23行还说明了应用程序可以为应用程序数据设置优先级(即“lowestpriority”)。第25-27行示出了一个回调，utf可使用该回调将接收到的流数据发送给应用程序。
132.基于前述，本发明的另一方面是一组操作，包括传输架构的会话管理模块的第一
操作和传输架构的连接管理模块的第二操作。该组操作可以作为可由处理器执行的指令存储在存储器(如非暂时性计算机可读存储介质)中。
133.所述第一操作可包括：从发送应用程序接收连接会话流的数据帧以传输到接收方；将数据帧传送到连接管理模块；和，维护数据帧的各自状态。所述第二操作可以包括：从接收方接收确认帧，其中确认帧包括数据包序号范围，所述数据包序号范围表示接收方接收到具有数据包序号范围内的序号的数据包；将数据包序号在该范围内的数据包中包含的帧号通知会话管理模块。数据帧的相应状态可以是飞行状态、确认状态、丢失状态或疑似丢失状态中的一种。
134.在一实施方案中，第一操作还包括接收请求以创建流的操作，其中所述请求可以包括所述流是否为可靠流、不可靠流或部分可靠流。在一实施方案中中，第二操作可包括：基于确认帧，将接收方确认的数据帧通知会话管理模块的操作；第一操作还可以包括根据通知的情况分别更新(至少其中一些)数据帧的状态。
135.在一个实施方案中，第二操作还可以包括从接收方接收反馈帧，其中反馈帧包括流的带宽和连接会话的持续时间。在一实施方案中，第一操作还可以包括：根据确认帧，将丢失帧通知给发送方应用程序。例如，如果使用的是可靠流或部分可靠流，则应用程序可确定重传丢失的帧。如上所述，如果使用的是不可靠流，则应用程序可确定重传丢失的帧(至少预定次数)。
136.如上所述，本领域技术人员应知本发明的全部或部分内容可以使用具有计算机程序的通用计算机或处理器来实现，该计算机程序在运行时可执行本发明所述的任何相应的技术、算法和/或指令。此外也可以使用专用计算机或处理器，其中配备用于运行本发明所述的技术、算法或指令的专用硬件。
137.本发明所述各个方面可通过功能块组件和各种处理操作来描述。本发明中的过程和顺序可以单独或以任意组合形式来执行。功能块可以通过可运行特定功能的任意数量的硬件和/或软件组件来实现。例如，所述的内容可以采用各种集成电路组件，例如存储器元件、处理元件、逻辑元件、查表等，所述的集成电路组件在一个或多个微处理器或其他控制设备的控制下执行各种功能。类似地，实现所述内容各个功能时如需采用软件编程或软件元件，可以采用诸如c、c++、java、汇编程序等的任何编程或脚本语言来实现本发明，并且可以采用任何数据结构、对象、进程、例程或其他编程元素的任意组合来执行各种算法。各项功能可以在一个或多个处理器上通过执行算法来实现。此外，本发明所述各个方面可以采用任意数量的常规技术来进行电子配置、信号处理和/或控制、数据处理等。本文广泛使用“机制”和“元件”这些词语，并不限于机械或物理实现，而是可以包括与处理器结合的软件例程等。
138.以上发明的实现或部分实现可以采取计算机程序产品的形式，例如，该程序产品可通过计算机使用或可由计算机可读介质进行访问。计算机可用或计算机可读介质可以是任何设备，只要所述设备能够具体包含、存储、传送或传输可由任何处理器使用或与其结合使用的程序或数据结构。所述介质可以是电子的、磁的、光学的、电磁的或半导体设备等等。此外也可以是其他适用的介质。上述计算机可用或计算机可读介质可以被称为非暂时性存储器或介质，并且可以包括ram或其他可以随时间变化而发生改变的易失性存储器或存储设备。本发明所述的设备存储器并非必须物理上配备于设备中，而是可以由设备远程访问，
并且不必与设备中其他物理上配备的存储器相邻，除非另有特别说明。
139.作为本发明实施方案中执行的一项或多项功能均可使用机器可读指令来实现所述指令为用于对前述一个或多个组合的硬件执行操作的代码形式。计算代码可以以一个或多个模块的形式实现，通过这些模块可以将一个或多个组合的功能作为计算工具来执行，在运行本发明所述方法和系统时，输入和输出数据在每个模块与一个或多个其他模块之间进行相互传输。
140.在本发明中，“信号”和“数据”两词可以互换使用。此外，计算设备各部分功能并非必须以相同的方式来实现。信息、数据和信号可以使用各种不同的技术和方法来表示。例如，本发明中提到的任何数据、指令、命令、信息、信号、位、符号和芯片可以用电压、电流、电磁波、磁场或粒子、光学场或粒子等其中的一项或多项组合来表示。
141.本发明中“实施方案”一词来表示举例、实例或说明。本发明中作为实施方案的任何功能或设计不一定表示其优于或胜于其他功能或设计。相反，使用“实施方案”一词是为了以具体的方式呈现概念。另外，“一个功能”或“一项功能”这两个短语在全文中多次用到，除非特别说明，否则并不意味着同一个实施方式或同一功能。
142.本发明中所使用的术语“或”，对于其连结的两个或多个元素而言，旨在表示包含性的“或”而不是排他性的“或”。也就是说，“x包括a或b”意在表示任何自然的包含性排列，除非另有说明，或者从上下文可明确判断则另当别论。换句话说，如果x包含a，x包含b，或x包含a和b，那么在任何前述实例下“x包含a或b”都成立。以此类推，“x包括a和b中的一个”旨在用作“x包括a或b”的等同词。发明中使用的“和/或”一词旨在表示“和”或非排他性的“或”。也就是说，“x包括a、b和/或c”旨在表示x可包括a、b和c的任意组合，除非另有说明或上下文另有明确指示。换句话说，如果x包括a，x包括b，x包括c，x包括a和b两者，x包括b和c两者，x包括a和c两者，或者x包括a、b和c全部，那么上述情况中的每一种或多种都满足“x包括a、b和/或c”的描述。以此类推，“x包括a、b和c中的至少一个”旨在用作“x包括a、b和/或c”的等同词。
143.本发明中“包含”或“具有”及其同义词旨在表示包括其后列出的项目及其等同物以及附加项目。根据上下文语境，本发明中的“如果”一词可以被解释为“当”“当
……
时”或“假设”等意思。
144.在本发明所述内容(特别是权利要求书)中，“一”、“一个”和“所述”以及类似的指示代词应理解为同时包含单数和复数形式。此外，除非另有说明，本发明中对数值范围的描述只是一种简便的描述方式，旨在表示包含在该范围之内的每一个单独数值，并且每个单独值都包含在说明书中，等效于其在本发明中单独列举。最后，本发明所述的所有方法的步骤可以以任何合适的顺序执行，除非本文另有说明或者与上下文明显矛盾。本发明提供的示例或示例性语言(例如“诸如”)的使用旨在更好地说明本发明，而非用于限制本发明的范围，除非另有说明。
145.说明书使用了各种标题和小标题。包含这些内容是为了增强可读性并简化查和引用材料的过程。这些标题和小标题并非用于、也不会用来影响对权利要求的解释或以任何方式限制权利要求的范围。本文示出和描述的具体实施方式是本发明的说明性示例，而并非以任何方式限制本发明的范围。
146.本文引用的所有参考文献(包括出版物、专利申请和专利等)均通过引用纳入本
文，等效于单独且明确地指明将每个参考文献通过引用纳入本文，且涵盖参考文献的全部内容。
147.虽然本文已经结合某些实施例和实施方案对本发明进行描述说明，但应理解，本发明并不限于所公开的实施方，与之相反，本公开旨在覆盖权利要求范围之内所涵盖的各种变体和等同设置，该范围应被赋予最宽泛的解释以涵盖法律允许的所有上述变体和等同设置。

技术特征：

1.一种在接收设备的发送应用程序和接收应用程序之间进行通信的设备，包括：处理器，其配置为：在发送应用程序和接收应用程序之间建立用于传输数据的流；从发送应用程序接收第一请求，将元数据传输到接收应用程序；从发送应用程序接收第二请求，将应用程序数据传输到接收应用程序；确定包括应用数据和元数据的帧小于或等于最大帧的容量后，构建所述帧包括所述应用数据和所述元数据；和将所述帧以数据包的形式发送到接收装置。2.如权利要求1所述的设备，其中所述处理器进一步配置为：确定所述包括应用数据和元数据的帧大于最大帧的容量后，构建所述帧包括所述元数据，且不包括所述应用程序数据。3.如权利要求1所述的设备，其中所述帧通过不可靠传输协议进行传输。4.如权利要求1所述的设备，其中所述处理器进一步配置为：当未从接收设备接收到所述元数据的确认，将包括元数据的元数据帧发送到接收设备，其中，所述元数据帧在自发送所述帧起，等待阈值时间之后发送。5.如权利要求1所述的设备，其中所述处理器进一步配置为：当未从接收设备接收到所述元数据的确认，以及当前时间和所述帧的发送时间之间的时间差没有超过阈值时间，在发送所述帧的阈值时间之后，将包括所述元数据的元数据帧发送到接收设备。6.如权利要求1所述的设备，其中所述处理器进一步配置为：对于重传次数达到阈值：当未从接收设备接收到元数据的确认，将所述元数据重传到所述接收设备。7.如权利要求6所述的设备，其中所述处理器进一步配置为：当在重传阈值次数后未接收到所述确认，关闭所述流。8.一种用于在接收设备的发送应用程序和接收应用程序之间进行通信的方法，包括：在发送应用程序和接收应用程序之间建立用于传输数据的流；从发送应用程序接收第一请求，将元数据传输到接收应用程序；从发送应用程序接收第二请求，将应用程序数据传输到接收应用程序；确定包括应用数据和元数据的帧小于或等于最大帧的容量后，构建所述帧包括所述应用数据和所述元数据；和将所述帧以数据包的形式发送到接收装置。9.如权利要求8所述的方法，进一步包括：确定所述包括应用数据和元数据的帧大于最大帧的容量后，构建所述帧包括所述元数据，且不包括所述应用程序数据。10.如权利要求8所述的方法，其中所述帧通过不可靠传输协议进行传输。11.如权利要求8所述的方法，其进一步包括：当未从接收设备接收到所述元数据的确认，立即将包括所述元数据的元数据帧发送到接收设备，其中，所述元数据帧在自发送所述帧起，等待阈值时间之后发送。12.如权利要求8所述的方法，其进一步包括：
当未从接收设备接收到所述元数据的确认，以及当前时间和所述帧的发送时间之间的时间差没有超过阈值时间，在发送所述帧的阈值时间之后，将包括所述元数据的元数据帧发送到接收设备。13.如权利要求8所述的方法，其进一步包括：对于重传次数达到阈值：当未从接收设备接收到元数据的确认，将所述元数据重传到所述接收设备。14.如权利要求13所述的设备，其进一步包括：当在重传的阈值次数后未接收到所述确认，关闭所述流。15.一种非暂时性计算机可读存储介质，其包含可执行指令，当处理器运行所述可执行指令时，将执行的操作为，搭建接收设备的发送应用程序和接收应用程序之间进行通信的传输架构，所述操作包括：在发送应用程序和接收应用程序之间建立用于传输数据的流；从发送应用程序接收第一请求，将元数据传输到接收应用程序；从发送应用程序接收第二请求，将应用程序数据传输到接收应用程序；确定包括应用数据和元数据的帧小于或等于最大帧的容量后，构建所述帧包括所述应用数据和所述元数据；和将所述帧以数据包的形式发送到接收装置。16.如权利要求15所述的非暂时性计算机可读存储介质，进一步包括：确定所述包括应用数据和元数据的帧大于最大帧的容量后，构建所述帧包括所述元数据，且不包括所述应用程序数据。17.如权利要求15所述的方法，其中所述帧通过不可靠传输协议进行传输。18.如权利要求15所述的非暂时性计算机可读存储介质，进一步包括：当未从接收设备接收到所述元数据的确认，立即将包括所述元数据的元数据帧发送到接收设备，其中，所述元数据帧在自发送所述帧起，等待阈值时间之后发送。19.如权利要求15所述的非暂时性计算机可读存储介质，进一步包括：当未从接收设备接收到所述元数据的确认，以及当前时间和所述帧的发送时间之间的时间差没有超过阈值时间，在发送所述帧的阈值时间之后，将包括所述元数据的元数据帧发送到接收设备。20.如权利要求15所述的非暂时性计算机可读存储介质，进一步包括：对于重传次数达到阈值：当未从接收设备接收到元数据的确认，将所述元数据重传到所述接收设备；和当在重传的阈值次数后未接收到所述确认，关闭所述流。

技术总结

本发明提供了一种用于在接收设备的发送应用程序和接收应用程序之间进行通信的装置，其包括处理器，所述处理器在发送应用程序和接收应用程序之间建立用于传输数据的流；从发送应用程序接收第一请求，将元数据传输到接收应用程序；从发送应用程序接收第二请求，将应用程序数据传输到接收应用程序；确定一个包括应用数据和元数据的帧小于或等于最大帧容量后，则构建该帧时将包括应用数据和元数据；并将该帧以数据包的形式发送至接收设备。帧以数据包的形式发送至接收设备。帧以数据包的形式发送至接收设备。