CN108900907A - 封装数据包方法及装置、电子设备、介质 - Google Patents
封装数据包方法及装置、电子设备、介质 Download PDFInfo
- Publication number
- CN108900907A CN108900907A CN201810771754.5A CN201810771754A CN108900907A CN 108900907 A CN108900907 A CN 108900907A CN 201810771754 A CN201810771754 A CN 201810771754A CN 108900907 A CN108900907 A CN 108900907A
- Authority
- CN
- China
- Prior art keywords
- data packet
- data
- packet
- client
- field
- 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
- 238000000034 method Methods 0.000 title claims abstract description 49
- 238000005538 encapsulation Methods 0.000 claims abstract description 36
- 230000005540 biological transmission Effects 0.000 claims abstract description 31
- 241000209140 Triticum Species 0.000 claims description 39
- 235000021307 Triticum Nutrition 0.000 claims description 39
- 238000009826 distribution Methods 0.000 claims description 22
- 238000003860 storage Methods 0.000 claims description 7
- 238000004590 computer program Methods 0.000 claims description 5
- 238000005520 cutting process Methods 0.000 claims description 5
- 230000003993 interaction Effects 0.000 claims description 5
- 238000012545 processing Methods 0.000 claims description 5
- 235000013399 edible fruits Nutrition 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 10
- 230000008569 process Effects 0.000 description 4
- 241001269238 Data Species 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 241000208340 Araliaceae Species 0.000 description 1
- 240000000233 Melia azedarach Species 0.000 description 1
- 235000005035 Panax pseudoginseng ssp. pseudoginseng Nutrition 0.000 description 1
- 235000003140 Panax quinquefolius Nutrition 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 238000010924 continuous production Methods 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 238000005315 distribution function Methods 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 239000000686 essence Substances 0.000 description 1
- 238000005194 fractionation Methods 0.000 description 1
- 235000008434 ginseng Nutrition 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
- H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0006—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
Abstract
本申请公开了封装数据包方法及装置、电子设备、介质，所述方法包括步骤：获取资源数据；将资源数据切割成预定大小的数据包；将所述数据包按自定义格式封装，其中，所述自定义格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的连续编号，所述第二字段包括所述预定大小的数据包的数据内容。利用该数据包封装方法，可以成功的将P2P模式运用到直播数据传输领域。
Description
技术领域
本申请涉及互联网领域，尤其涉及封装数据包方法及装置、电子设备、介质。
背景技术
传统的P2P技术是基于文件共享需求产生的，P2P模式常常被用在共享视频或音频资料的场景(例如视频点播等网站的视频资源下载)。各网络节点直播数据时，通常将资源以文件的形式存储在各网络节点上，并将文件拆分成若干个子文件传输给对端节点。由于传统的P2P技术通常是基于文件的方式传输数据，需要事先将文件制作好，而文件传输的方式使得P2P技术的适用场景存在局限定，并不适用于直播模式的实时视频流的传输。
发明内容
为了解决上述技术问题，本申请提供封装数据包的方法、装置、电子设备。
根据本申请实施例的第一方面，提供一种封装数据包的方法，所述方法包括步骤：
获取资源数据；
将资源数据切割成预定大小的数据包；
将所述数据包按自定义格式封装，其中，所述自定义格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的连续编号，所述第二字段包括所述预定大小的数据包的数据内容。
在一些例子中，所述将所述数据包按自定义格式封装之后，还包括步骤：
以所述封装后的数据包的编号为被除数，进行求余处理，根据求余结果确定所述封装后的数据包的分组号；
根据所述封装后的数据包的分组号，指定分发所述封装后的数据包的数据分发端。
在一些例子中，所述资源数据为包括至少两个连麦客户端的直播数据，所述各连麦客户端的直播数据包括若干帧不同时间戳的图像帧，其中，相同时间戳的所述图像帧的编号连续。
在一些例子中，相同时间戳的所述图像帧的编号连续，具体包括：
确定数据包的分组数；
确定各连麦客户端的数据包所属分组号；
根据所述各连麦客户端的数据包所属分组号，确定所述同一时间戳的所述图像帧对应的各数据包的编号顺序，其中，以所述编号为被除数，分组数为被被除数，进行求余后的结果为所述编号对应的数据包所属分组号。
在一些例子中，所述自定义格式还包括：
第三字段，包括表征所述资源数据的唯一性的第二标识。
在一些例子中，所述数据包的大小与所述封装后的数据包用于传输时的网络的传输带宽匹配；或
所述数据包的大小为1KB。
在一些例子中，所述方法应用于服务器，所述方法还包括步骤：
将封装后的所述数据包发给各客户端，以使各客户端建立P2P网络后，基于预先约定的传输策略和所述编号交互所述数据包。
在一些例子中，所述资源数据为直播流媒体数据。
本申请的第二方面，提供一种封装数据包的装置，所述装置包括：
切割模块，用于获取资源数据，将资源数据切割成预定大小的数据；
封装模块，用于将所述切割成预定大小的数据写入待封装的数据包的第二字段；根据上一封装后的数据包的编号以及编号连续的原则，确定当前待封装的数据包的编号；将所述确定的编号写入所述当前待封装的数据包的第一字段，其中，所述数据包的封装格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的编号，所述第二字段包括所述数据包的数据。
本申请的第三方面，提供一种封装数据包的设备，包括：
处理器；以及
存储器，所述存储器被配置成存储计算机程序，所述计算机程序被配置成被所述处理器执行如上述第一方面所述的任意一项所述方法的步骤。
本申请的第四方面，提供一种存储介质，所述程序被处理器执行时实现如上述第一方面所述的任意一项所述方法的步骤。
利用本申请提供的数据包封装方法可以成功的将P2P模式运用到直播数据传输领域。不同于传统的P2P模式，将资源数据(包括直播流媒体数据)切割成预设大小的数据包而不是文件块，文件块的大小可能在上百KB，而相对于文件块来说，数据包的可拆分粒度更小，可以作为更小的传输单元在网络中传输，并且所述数据包的第一字段包括描述所述数据包的唯一性的编号，接收到所述数据包的客户端只需通过所述编号及拼装规则，即可对资源数据进行拼装还原，极大提高了客户端播放所述资源数据的效率。并且本申请提出的编号为预定位数的连续编号，当按照本申请提出的格式封装的数据包丢包时，可以通过编号连续的特点，确定丢失的数据包，提高数据包传输的速率。
附图说明
图1为本申请实施例提出的一种封装数据包的方法的部分流程图；
图2为本申请实施例示例性示出的自定义封装格式的示意图；
图3a-图3c为本申请实施例中三种不同的服务器架构下搭建的网络；
图4本申请实施例提出的一种直播系统的网络架构示意图；
图5为本申请实施例示例性示出的一种将图1所述的封装数据包的方法运用在直播场景中的流程图；
图6为本申请实施例示例性示出的另一自定义封装格式的示意图；
图7为本申请实施例示例性示出的一种网络框架图；
图8为本申请实施例性示出的一种直播连麦场景示意图；
图9为本申请实施例性示出的实现相同时间戳的所述图像帧的编号连续的流程图；
图10是本申请实施例提出的方法应用在P2P场景中的流程图；
图11为本申请实施例中的一封装数据包的装置的示意图；
图12为本申请实施例中的一个电子设备的示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
参照图1为本申请实施例提出的一种封装数据包的方法的部分流程图，所述方法包括步骤：
S110：获取资源数据；
S120：将资源数据切割成预定大小的数据包；
S130：将所述数据包按自定义格式封装，其中，所述自定义格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的连续编号，所述第二字段包括所述预定大小的数据包的数据内容。
所述封装后的数据包用于在网络中传输，可以由数据分发端进行数据包的分发，并由接收到所述数据包的客户端根据第一字段中的编号，有序拼装得到资源数据，以供所述客户端播放(或浏览，或打开)所述资源数据。
本申请实施例提出的所述资源数据是指待封装的资源，值得说明，资源数据并不局限于以文件形式存在的文件数据(例如常见的音频/视频文件、图片文件、各种Office文档等等)，对于流媒体数据同样适用，例如直播场景下直播数据等。若所述资源数据为可以为直播流媒体数据，所述“资源数据被拆分成若干数据包”是实时发生的，无需等待服务器接收到整个资源数据再进行拆分，服务器收到部分资源数据后，可以将部分资源数据拆分成若干数据包。
本申请实施例提出的将资源数据切割成预设大小的数据包，所述预设大小可以与所述封装后的数据包用于传输时的网络的传输带宽匹配。在一些例子中，所述数据包的大小可以为1KB。
参照图2，为本申请实施例示例性示出的自定义封装格式的示意图，自定义格式可以包括第一字段210、第二字段220及第四字段230，所述第一字段210包括确定数据包唯一性的连续编号，所述编号可以是预定位数的编号，例如32位，所述第二字段220包括所述预定大小的数据包的数据内容；所述第四字段230可以用于描述数据包的长度。一些例子中，所述编号具有连续且自增一的特点，即当前待封装的数据包的编号，可以根据上一封装后的数据包的编号确定，例如上一封装后的数据包的编号为10002，则当前待封装的数据包的编号为10002+1＝10003。
通过本申请实施例提出的自定义格式，当接收所述数据包的客户端发现所述数据包存在丢包时，可以快速确定丢失的数据包，例如：当客户端接收到的数据包的编号为:10000、10002及10003时，由于数据包的编号是连续增一的，可以判断出编号为10001的数据包丢失，并向任一服务器请求编号为10001的数据包。
本申请实施例所述的方法可以由服务器来执行，所述服务器可以由多种实体承担，这取决于设计者对不同网络设备的角色划分。例如，图3a、图3b、图3c是三种不同场景下的网络架构，可以看出，不同业务模式下，由于业务或设备管理的需求不同，可以由不同的服务器设备承担本申请实施例所述的封装数据包方法所述的步骤的执行主体。图3a中，第一服务器承担收集直播数据的角色(类似与传统直播系统中的直播服务器的角色)，第二服务器承担拆分数据包的角色，后文可以将承担拆分数据包角色的服务器称为切片服务器，第三服务器作为向对等节点分发数据包的角色(例如，类似于传统的CDN服务器，该第三服务器/CDN服务器可以被称为数据分发端)。图3b中，第一服务器集成了收集直播数据和拆分数据包的功能，第二服务器作为分发数据包的服务器。图3c中，服务器将收集直播数据、拆分数据包、分发数据包的功能集于一体。需要指出，除了图3a、图3b、图3c所列举的示例以外，并不排除有其他形式的网络架构或服务器功能。
本申请实施例提出的封装数据包的方法可以运用在直播场景中。图4是本申请实施例提出的一种直播系统的网络架构，网络架构中包括主播客户端410、服务器420、观众客户端431-434。由于不同的应用环境下，用户对网络设备的功能需求可能不同，因此，每个应用场景中服务器和客户端(包括主播客户端或观众客户端)设备的数量以及功能可以不同。
参照图5，为本申请实施例示例性示出的一种将图1所述的封装数据包的方法运用在直播场景中的流程图，部分步骤如下：
S510：主播客户端将直播数据发送给服务器；
S520：所述服务器在直播数据被拆分成若干数据包；
S530：所述服务器将所述数据包按自定义格式封装，其中，所述自定义格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的连续编号，所述第二字段包括所述预定大小的数据包的数据内容；
S540：服务器将封装后的数据包分发给与所述主播客户端对应的观众客户端，以使观众户端接收所述封装后的数据包后，有序拼装得到资源数据。
在直播场景中，不同直播间的资源数据不同，一些例子中，各直播间的资源数据与各自的地址(URL)关联，当观众客户端向服务器请求资源数据时，所述观众客户端会携带表征资源数据唯一性的第二标识，服务器根据所述第二标识，从该资源数据关联的地址(URL)获取对应的数据包，并将所述数据包分发给发出请求的观众客户端。所述第二标识可以包括直播场景中的直播间的标识(例如频道号、直播流标识及直播间主播标识等)或/和客户端标识(例如客户端账号或ID)。在另一例子中，参照图6，另一自定义格式示意图，所述自定义格式还可以包括第三字段240，所述第三字段240包括表征所述资源数据的唯一性的第二标识，服务器可以根据所述第三字段中的第二标识确定资源数据。
进一步，在一些例子中，用于数据包分发的服务器的数量可以为至少两个，所述至少两个用于数据包分发的服务器可以分别分发指定的数据包，以提高数据包分发效率。参照图7，为本申请实施例示例性示出的一种网络框架图，图7的网络中主播客户端与直播服务器建立TCP连接通道，直播服务器与切片服务器相连，切片服务器与两个CDN服务器711及712(图7中为了方便描述仅以两个CDN服务器为示例，CDN服务器的数量视实际情况而定)相连。直播服务器从主播服务器获取资源数据后，将所述资源数据发送给切片服务器，所述切片服务器将资源数据被拆分成若干数据包后，将所述数据包按自定义格式封装，其中，所述自定义格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的连续编号，所述第二字段包括所述预定大小的数据包的数据内容；接着将封装后的数据包发送至CDN服务器711及712，由CDN服务器711及712分别分发指定的数据包。
一个具体的例子中，所述确定各CDN服务器分发指定的数据包的方法可以是：根据预设的分组数，用每个数据包的编号对预设的分组数进行求余，确定各服务器将分发的数据包。例如：一资源数据被拆分成了编号为1-20的数据包，预设的分组数为5个，以CDN服务器的数量为5个为例，分别是CDN服务器1-5，用每个数据包的编号对共享服务器的数据进行求余，根据余数将各数据包分组，1/5的余数是1，为第1组，编号为1的数据包由CDN服务器1进行分发；2/5的余数是2，为第2组，编号为2的数据包由CDN服务器2进行分发；5/5的余数是0，为第0组，编号为5的数据包由CDN服务器5进行分发；以此类推，可以确定各数据包的分组，及各CDN服务器分发的数据包。当然可以理解，所述预设的分组数可以根据资源数据的码率、分辨率、清晰度或/和CDN服务器的数量确定，具体求余的策略不做限定。通过上述使各服务器分发求余的数据包的方式，可以进一步提高数据分发效率，使客户端更快的打开/播放所述资源数据。以所述资源数据为直播视频流数据为例，所述直播视频流由多帧图像帧组成，而本申请将每帧图像帧拆分成若干数据包，当多个服务器向同一客户端分发每帧图像的不同数据包时，客户端可以快速组装得到每一帧图像，以提高客户端播放资源数据的效率，尤其对于直播视频流数据，获得第一帧图像的速率远远高于各服务器分别分发连续几帧图像帧拆分成的数据包，如此可以明显提高起播速度，减少延时。需要说明的是，各服务器分发的数据包的组数可以不限，各服务器分发的数据包的组数可以相同也可以不同，例如a服务器分发余数为0、1、2及3共4组数据包；b服务器分发余数为4及5共2组数据包。还需要说明的是，上述实施例的执行主体不限于CDN服务器，其他任意用于数据分发的执行主体均可以套用上述实施例。
本申请通过将资源数据切割成数据包而不是子文件，相比于由于格式与特定的视频编解码协议高度匹配，所以只能依赖单个的文件分发的服务器的子文件，本申请提出的切割后的数据包由自定义格式封装，每个封装后的数据包拥有表征数据包唯一性的编号，所述封装后的数据包仅依赖编号组合还原成资源数据，所以可以通过至少两个服务器分别向客户端进行数据包的分发数据包，以此提高了数据分发效率，更重要的是，多服务器进行数据分发，在面对存在服务器故障时可以表现出更好的稳定性。
进一步，在一些例子中，当多个服务器分发数据时，若其中一服务器发生异常，可以紧急从其他服务器获取发生异常的服务器本该分发的数据包。例如：将数据包的编号对10进行求余，数据包被分为10组，余数为0-2的数据包从a服务商的服务器获取，余数为3-5的数据包从b服务商的服务器获取，余数为6-10的数据包从c服务商获取，当b服务器发生故障时，客户端可以紧急从a服务商或c服务商的服务器获取余数为3-5的数据包。
本申请实施例提出的封装数据包的方法还可以应用在直播连麦场景中。本申请实施例提出的连麦是主播与观众、主播与主播之间的一种互动方式，在连麦过程中，主播与观众的身份也由此转变成发起者与参与者，当发起者向参与者发起连麦请求，参与者接受连麦后，便在发起者与参与者自身所在的客户端之间建立起连接，而直播画面也由上述两个客户端共同提供。一般情况下，直播画面可以是发起者的直播画面为大窗口，参与者的直播画面为小窗口的画中画形式进行显示。在传统的连麦技术中，上述直播画面显示方式可以由连麦的发起者或参与者随意调整。在某些例子中，连麦还可以是多人连麦。在本申请实施例中，将连麦的发起者和参与者所在的客户端称为连麦客户端。
在直播连麦场景中，资源数据为包括至少两个连麦客户端的直播数据，各连麦客户端的直播数据包括若干帧不同时间戳的图像帧，为了减少是延迟，本申请实施例提出的封装数据包的方法，在服务器对数据包进行封装时，可以将相同时间戳的所述图像帧的编号连续。例如，参照图8为本申请实施例性示出的一种直播连麦场景示意图，连麦客户端811及连麦客户端821基于网络、通过服务端800以连麦的形式建立连接，观众客户端831与连麦客户端811及连麦客户端821中的任一在相同的直播间内，观众客户端831可以以画中画的形式展示连麦客户端811及连麦客户端821的画面。连麦客户端811的直播数据为直播视频流a，连麦客户端821的直播数据为直播视频流b，服务器获取直播视频流a和直播视频流b后，将直播视频流a和直播视频流b切割成数据包，并将所述数据包按自定义格式封装，且将直播视频流a与直播视频流b的时间轴统一，相同时间戳的图像帧被连续编号，如属于直播视频流a的图像帧a和属于直播视频流b的图像帧b时间戳相同，则图像帧a与图像帧b被连续编号，一个具体的例子中，例如图像帧a被拆分成10个数据包，编号分别是10001至10010，那么图像帧b的数据包的编号为100011至10020。我们知道，大部分连麦直播中，会同时展示多个连麦客户端的直播数据，如果先将直播视频流a的数据包编号，再给直播视频流b的数据包编号，客户端收到全部视频流的数据才能进行展示，导致客户端播放资源数据时，严重卡顿。采用同一时间戳的图像帧连续编号的方式，可以减少客户端播放资源数据时的卡顿，增加播放流畅性。
为了进一步减少卡顿，在一些例子中，参照图9，上述相同时间戳的所述图像帧的编号连续，具体可以由以下步骤实现：
S910：确定数据包的分组数；
S920：确定各连麦客户端的数据包所属分组号；
S930：根据所述各连麦客户端的数据包所属分组号，确定所述同一时间戳的所述图像帧对应的各数据包的编号顺序，其中，以所述编号为被除数，分组数为被被除数，进行求余后的结果为所述编号对应的数据包所属分组号。
在一个具体的例子中，两个连麦客户端a和b连麦，连麦客户端a的直播数据为直播视频流a，连麦客户端b的直播数据为直播视频流b，属于直播视频流a的图像帧a和属于直播视频流b的图像帧b时间戳相同，若分组数为8个，直播视频流a的数据包的属于的分组号为1、2、3及4，直播视频流b属于的分组号为5、6、7及8，则根据所述所属分组号，以所述编号为被除数，分组数为被被除数，进行求余后的结果为所述编号对应的数据包所属分组号，确定每个数据包的编号，即每对4个属于直播视频流a的数据包编号后，对4个属于直播视频流b的数据包进行编号，如此重复交叉编号。
本申请实施例提出的封装数据包的方法还可以运用在P2P场景中，所述Peer-to-peer(P2P)是一种分布式网络，P2P网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等)，这些共享资源需要由网络提供服务和内容，能被其它对等节点(peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源(服务和内容)提供者(服务器server)，又是资源(服务和内容)获取者(客户端client)。基于上述P2P的特点，P2P网络中的对等节点获取资源的数据非常快。但是，传统的P2P技术是基于文件共享需求产生的，P2P模式常常被用在共享视频或音频资料的场景(例如视频点播等网站的视频资源下载)。各网络节点流媒体数据时，通常将资源以文件的形式存储在各网络节点上，并将文件拆分成若干个子文件传输给对端节点。由于传统的P2P技术通常是基于文件的方式传输数据，需要事先将文件制作好，而文件传输的方式使得P2P技术的适用场景存在局限定，并不适用于直播模式的实时视频流的传输。
为了使本申请实施例的P2P网络能够突破传统P2P网络的常规传输模式(即传统技术中以拆分文件的方式在对等节点之间传输数据)，本申请提出以下技术方案，图10是本申请实施例提出的方法应用在P2P场景中的流程图，部分步骤如下：
服务器在资源数据被拆分成若干数据包(S1010)后，将所述数据包按自定义格式封装(S1020)，其中，所述自定义格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的连续编号，所述第二字段包括所述预定大小的数据包的数据内容；
服务器将封装后的数据包分发给对应的客户端(S1030)；
服务器使所述客户端建立P2P网络(S1040)；
所述客户端在P2P网络中基于预先约定的传输策略和所述编号与其他客户端交互所述数据包(S1050)。
不同于传统的P2P模式，实施例中执行S1010时，首先将资源数据切割成数据包而不是文件块，文件块的大小可能在上百KB，而相对于文件块来说，数据包的可拆分粒度更小，可以作为更小的传输单元在网络中传输，例如在考虑切割后的数据包的大小时，可以结合互联网链路层的传输特性来设计，使得数据包的大小与P2P网络中各连接通道的传输带宽匹配。举例来说，各对等节点之间建立的通道可以是UDP通道，每个数据包的大小可以是1KB左右，约等于MTU(互联网链路层最大传输单元)，这样，每个数据包可以由1个UDP包传输，不需要出现基于UDP包拆包，因此比拆分文件的方式效率更高，从而使得具有更广泛的适用场景。
本申请实施例提出的客户端之间交互数据包可以指，一些客户端在发出请求某些编号的消息后，已下载这些编号的数据包的客户端可以响应该请求，将数据包发送给请求方。由于各个客户端在P2P网络中处于地位均等的角色(即对等节点)，因此某个时刻的请求方可以在下一时刻成为响应方，因此，P2P网络中的客户端之间的数据包交互可以是双向的，而并非一定是单向传输。
在一些例子中，图10所述的方法也可以应用在直播场景中，所述资源数据为直播流媒体数据，所述直播流媒体数据由主播客户端发送给服务器，由服务器执行上述图10所述的步骤，图10所述的客户端为与所述主播客户端对应的观众客户端。
在S1030阶段，以应用在直播场景中为例，一些例子中，为了数据包能够广泛散布在P2P网络的各对等节点上，以便对等节点之间相互传输数据包，服务器可以将数据包发送给关注某个主播客户端的每个观众客户端。当然，设计者也可以针对不同的业务场景设置不同的分发策略，例如，服务器可以只发送给指定的其中一些观众客户端。
以应用在直播场景中为例，在一个例子中，在S1030之前，观众客户端可以向服务器主动请求，告知服务器自身的第二标识，例如，可以是服务器接收到观众客户端向服务器发送获取资源数据的指令后，执行步骤S1050，所述获取资源数据的指令可以携带观众客户端的直播间标识，服务器根据观众客户端所在直播间标识来确定将数据包发送给哪些观众客户端。需要说明的是，上述观众客户端标识可以包括：观众的用户名或ID，若观众客户端仅通知服务器观众客户端标识，服务器可以通过所述观众客户端标识确定所述观众客户端所在的直播间。
在构建P2P网络时，不同的应用实例中，建立连接通道的方式可以有所不同。例如，一些例子中可以参照现有技术的P2P网络中对等节点建立UDP通道的方式来实现；另一些例子中，可以针对实际的场景设计新的流程。例如，所有的观众客户端向服务器发起注册请求，将所在直播间标识以及建立连接所必须的信息(例如网络连接地址、端口号等)通知给服务器，这些信息可以携带在注册请求中、也可以以在其他消息中发送给服务器。服务器基于客户端所在直播间标识，在满足建立P2P网络的条件下，服务器通知在同一直播间的观众客户端之间需要建立P2P网络连接，形成对等节点。在其他实例中，仍然可对具体流程作出各种不同的变形。
服务器通知各观众客户端构建P2P网络的时机本申请并不作限定，可以在服务器接收到观众客户端发送的获取资源数据的指令时，通知各观众客户端，可以是在服务器收到观众客户端的直播间标识后即通知各观众客户端，也可以是在向观众客户端传输一段时间数据包后再通知各观众客户端，还可以是接收到观众客户端发起的请求建立P2P网络的请求时，通知各观众客户端。作为一个例子，可以是观众客户端判断是否满足预先设定的建立P2P网络的条件，当满足条件时向服务器发送构建P2P网络的请求，服务器接收到上述请求后，根据所述观众客户端所在直播间的标识将在同一直播间的观众客户端汇聚成P2P网络。
作为例子，相关的传输策略可以在服务器向客户端下发配置信息时下发给客户端，当然，也可以提前在客户端中设置好相关的传输策略。仍以直播场景为例，一些例子中，客户端进入某一频道，向服务器请求频道相关的配置信息时将建立P2P网络的传输策略发送给客户端、一些例子中，客户端向服务器注册时，服务器将建立P2P网络的传输策略发送给客户端。
当然，由于直播场景对数据传输的实时性和稳定性要求高，因此可以服务器先将部分数据包发送给各个客户端，使得客户端在能够保证及时播放的前提，在观众客户端播放资源数据的同时，从其他客户端接收其他编号的数据包，避免众多观众客户端同时访问服务器导致的网络拥堵问题。
网络中的任何一个对等节点可以向其他对等节点请求数据包，在S1050阶段，对等节点可以基于编号以及预先约定的传输策略向其他对等节点请求数据包，预先约定的传输策略可以规定哪些标识的数据包可以在P2P网络中传播。为了保证资源数据播放的实时性，传输策略可以规定：在预定时间内先从服务器获取数据包之后，向所述服务器查询是否存在直播间标识所对应的观众客户端，如果存在，则向其他观众客户端请求数据包。
一些例子中，为了防止有些对等节点误接入某个P2P网络，对等节点之间交互数据包时，还可以携带第二标识(如：直播间标识)，来对P2P网络中的对等节点身份校验。
与前述封装数据包的方法的实施例相对应，本申请还提供了封装数据包封装数据包的装置的实施例。
请参考图11，封装数据包的装置1100，包括：
切割模块1101，用于获取资源数据，将资源数据切割成预定大小的数据；
封装模块1102，用于将所述切割成预定大小的数据写入待封装的数据包的第二字段；根据上一封装后的数据包的编号以及编号连续的原则，确定当前待封装的数据包的编号；将所述确定的编号写入所述当前待封装的数据包的第一字段，其中，所述数据包的封装格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的编号，所述第二字段包括所述数据包的数据。
图11中封装数据包的装置的实施例可以应用在服务器设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务器设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图12所示，为本申请封装数据包的装置所在服务器设备的一种硬件结构图，除了图12所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务器设备通常根据该设备的实际功能，还可以包括其他硬件。所述处理器被用于执行以下操作：
获取资源数据；
将资源数据切割成预定大小的数据包；
将所述数据包按自定义格式封装，其中，所述自定义格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的连续编号，所述第二字段包括所述预定大小的数据包的数据内容。
在本申请实施例中，计算机可读存储介质可以是多种形式，比如，在不同的例子中，所述机器可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。特殊的，所述的计算机可读介质还可以是纸张或者其他合适的能够打印程序的介质。使用这些介质，这些程序可以被通过电学的方式获取到(例如，光学扫描)、可以被以合适的方式编译、解释和处理，然后可以被存储到计算机介质中。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。
Claims (11)
1.一种封装数据包的方法，其特征在于，所述方法包括步骤：
获取资源数据；
将资源数据切割成预定大小的数据包；
将所述数据包按自定义格式封装，其中，所述自定义格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的连续编号，所述第二字段包括所述预定大小的数据包的数据内容。
2.根据权利要求1所述的方法，其特征在于，所述将所述数据包按自定义格式封装之后，还包括步骤：
以所述封装后的数据包的编号为被除数，进行求余处理，根据求余结果确定所述封装后的数据包的分组号；
根据所述封装后的数据包的分组号，指定分发所述封装后的数据包的数据分发端。
3.根据权利要求1所述的方法，其特征在于，所述资源数据为包括至少两个连麦客户端的直播数据，所述各连麦客户端的直播数据包括若干帧不同时间戳的图像帧，其中，相同时间戳的所述图像帧的编号连续。
4.根据权利要求3所述的方法，其特征在于，相同时间戳的所述图像帧的编号连续，具体包括：
确定数据包的分组数；
确定各连麦客户端的数据包所属分组号；
根据所述各连麦客户端的数据包所属分组号，确定所述同一时间戳的所述图像帧对应的各数据包的编号顺序，其中，以所述编号为被除数，分组数为被被除数，进行求余后的结果为所述编号对应的数据包所属分组号。
5.根据权利要求1所述的方法，其特征在于，所述自定义格式还包括：
第三字段，包括表征所述资源数据的唯一性的第二标识。
6.根据权利要求1所述的方法，其特征在于，
所述数据包的大小与所述封装后的数据包用于传输时的网络的传输带宽匹配；或
所述数据包的大小为1KB。
7.根据权利要求1至6任一一项所述的方法，其特征在于，所述方法应用于服务器，所述方法还包括步骤：
将封装后的所述数据包发给各客户端，以使各客户端建立P2P网络后，基于预先约定的传输策略和所述编号交互所述数据包。
8.根据权利要求7所述的方法，其特征在于，所述资源数据为直播流媒体数据。
9.一种封装数据包的装置，其特征在于，所述装置包括：
切割模块，用于获取资源数据，将资源数据切割成预定大小的数据；
封装模块，用于将所述切割成预定大小的数据写入待封装的数据包的第二字段；根据上一封装后的数据包的编号以及编号连续的原则，确定当前待封装的数据包的编号；将所述确定的编号写入所述当前待封装的数据包的第一字段，其中，所述数据包的封装格式包括第一字段和第二字段，所述第一字段包括确定数据包唯一性的编号，所述第二字段包括所述数据包的数据。
10.一种封装数据包的设备，其特征在于，包括：
处理器；以及
存储器，所述存储器被配置成存储计算机程序，所述计算机程序被配置成被所述处理器执行如权利要求1至8任意一项所述方法的步骤。
11.一种存储介质，其特征在于，所述程序被处理器执行时实现如权利要求1至8任意一项所述方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810771754.5A CN108900907A (zh) | 2018-07-13 | 2018-07-13 | 封装数据包方法及装置、电子设备、介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810771754.5A CN108900907A (zh) | 2018-07-13 | 2018-07-13 | 封装数据包方法及装置、电子设备、介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN108900907A true CN108900907A (zh) | 2018-11-27 |
Family
ID=64349167
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810771754.5A Pending CN108900907A (zh) | 2018-07-13 | 2018-07-13 | 封装数据包方法及装置、电子设备、介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108900907A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110489484A (zh) * | 2019-07-11 | 2019-11-22 | 视联动力信息技术股份有限公司 | 数据同步方法、装置、可读存储介质及电子设备 |
| CN112243159A (zh) * | 2019-07-19 | 2021-01-19 | 武汉佳世创科技有限公司 | 基于dvb的数据处理、读取方法及服务器、终端以及系统 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090094376A1 (en) * | 2005-03-23 | 2009-04-09 | Alcatel Lucent | System and Method for Effectuating Playlist Seeking with Respect to Digital Multimedia Content From a Network Node |
| CN101945129A (zh) * | 2010-09-10 | 2011-01-12 | 北京易视腾科技有限公司 | P2p流媒体直播的低延时传输方法及系统 |
| CN105392068A (zh) * | 2015-11-04 | 2016-03-09 | 合一网络技术(北京)有限公司 | 分布式多传输信道网络直播视频并行分发方法及系统 |
| CN105491393A (zh) * | 2015-12-02 | 2016-04-13 | 北京暴风科技股份有限公司 | 多人视频直播业务的实现方法 |
| CN106034242A (zh) * | 2015-03-09 | 2016-10-19 | 杭州施强网络科技有限公司 | 一种p2p系统中音视频直播流媒体数据传输方法 |
-
2018
- 2018-07-13 CN CN201810771754.5A patent/CN108900907A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090094376A1 (en) * | 2005-03-23 | 2009-04-09 | Alcatel Lucent | System and Method for Effectuating Playlist Seeking with Respect to Digital Multimedia Content From a Network Node |
| CN101945129A (zh) * | 2010-09-10 | 2011-01-12 | 北京易视腾科技有限公司 | P2p流媒体直播的低延时传输方法及系统 |
| CN106034242A (zh) * | 2015-03-09 | 2016-10-19 | 杭州施强网络科技有限公司 | 一种p2p系统中音视频直播流媒体数据传输方法 |
| CN105392068A (zh) * | 2015-11-04 | 2016-03-09 | 合一网络技术(北京)有限公司 | 分布式多传输信道网络直播视频并行分发方法及系统 |
| CN105491393A (zh) * | 2015-12-02 | 2016-04-13 | 北京暴风科技股份有限公司 | 多人视频直播业务的实现方法 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110489484A (zh) * | 2019-07-11 | 2019-11-22 | 视联动力信息技术股份有限公司 | 数据同步方法、装置、可读存储介质及电子设备 |
| CN112243159A (zh) * | 2019-07-19 | 2021-01-19 | 武汉佳世创科技有限公司 | 基于dvb的数据处理、读取方法及服务器、终端以及系统 |
| CN112243159B (zh) * | 2019-07-19 | 2023-05-05 | 武汉佳世创科技有限公司 | 基于dvb的数据处理、读取方法及服务器、终端以及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11363116B2 (en) | Systems and methods for intelligent routing and content placement in information centric networks | |
| CN110121059B (zh) | 监控视频处理方法、装置及存储介质 | |
| CN109151497B (zh) | 一种连麦直播方法、装置、电子设备及存储介质 | |
| CN109120946B (zh) | 收看直播的方法和装置 | |
| CN108965912B (zh) | 一种视频数据处理的方法、客户端以及服务器 | |
| Chen et al. | MSPlayer: Multi-source and multi-path video streaming | |
| RU2647654C2 (ru) | Система и способ доставки аудиовизуального контента в клиентское устройство | |
| CN109474684A (zh) | 一种获取直播视频流的方法、装置、终端设备及存储介质 | |
| CN110572433B (zh) | 一种视频调度方法、系统及装置 | |
| CN108924609A (zh) | 流媒体数据传输的方法、电子设备、装置及存储介质 | |
| CN108833591A (zh) | P2p网络中数据传输的方法、电子设备、装置、网络架构 | |
| CN110191315B (zh) | 一种基于视联网的监控查看方法和装置 | |
| CN109379254B (zh) | 一种基于视频会议的网络连接的检测方法和系统 | |
| CN108965428A (zh) | 直播数据的传输方法、装置、电子设备、系统 | |
| CN109688417A (zh) | 一种数据分发系统、方法、装置、电视盒子及存储介质 | |
| CN110445723A (zh) | 一种网络数据调度方法及边缘节点 | |
| CN110049341A (zh) | 视频处理方法和装置 | |
| CN109561137A (zh) | 建立p2p网络的方法、装置、终端设备及介质 | |
| CN109361856A (zh) | 一种全景直播方法、装置、终端设备及存储介质 | |
| CN108900907A (zh) | 封装数据包方法及装置、电子设备、介质 | |
| CN110049280B (zh) | 监控数据的处理方法和装置 | |
| CN110213334A (zh) | 一种共享文件的传输方法及装置 | |
| CN109510868A (zh) | 一种建立p2p网络的方法、装置、终端设备及存储介质 | |
| CN111212255B (zh) | 监控资源获取方法、装置及计算机可读存储介质 | |
| CN109040199A (zh) | 一种分发资源数据的方法、系统及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20181127 |
|
| RJ01 | Rejection of invention patent application after publication |