CN109560901A - 一种数据重传方法、装置、终端设备及存储介质 - Google Patents

一种数据重传方法、装置、终端设备及存储介质 Download PDF

Info

Publication number
CN109560901A
CN109560901A CN201811354499.0A CN201811354499A CN109560901A CN 109560901 A CN109560901 A CN 109560901A CN 201811354499 A CN201811354499 A CN 201811354499A CN 109560901 A CN109560901 A CN 109560901A
Authority
CN
China
Prior art keywords
data packet
time
data
missing
server
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
Application number
CN201811354499.0A
Other languages
English (en)
Other versions
CN109560901B (zh
Inventor
冯修杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Huya Information Technology Co Ltd
Original Assignee
Guangzhou Huya Information Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Guangzhou Huya Information Technology Co Ltd filed Critical Guangzhou Huya Information Technology Co Ltd
Priority to CN201811354499.0A priority Critical patent/CN109560901B/zh
Publication of CN109560901A publication Critical patent/CN109560901A/zh
Application granted granted Critical
Publication of CN109560901B publication Critical patent/CN109560901B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1874—Buffer management
    • H04L1/1877—Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
    • 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1887—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Communication Control (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种数据重传方法、装置、终端设备及存储介质，所述方法运用于接收端，所述方法包括步骤：接收发送端发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续，所述发送端与接收端之间基于不可靠协议；若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。旨在解决现有的数据重传技术中，存在数据重传冗余或影响数据使用的问题。

Description

一种数据重传方法、装置、终端设备及存储介质
技术领域
本申请涉及互联网领域，尤其涉及数据重传领域。
背景技术
在数据传输过程中，若采用UDP等不可靠协议，在发生网路抖动或故障时，数据可能发生延时或丢失，接收端若不及时请求发送端重传未接收到的数据，可能影响接收端对数据的使用，例如，若上述传输的数据为直播流媒体数据，可能导致播放直播流媒体数据时，出现花屏、卡顿或延时等现象，但若接收端太早请求发送端重传未接收到的数据，可能会造成数据重复冗余，例如，数据在传输时由于网络抖动而延时，若太早请求重传未接收到的数据，在接收到重传的数据后，可能还会接收到延时的数据，而造成冗余，产生占用网络带宽的问题。
发明内容
为了解决上述技术问题，本申请提供一种数据重传方法、装置、终端设备及存储介质。
在本申请的第一方面，提供一种数据重传方法，所述方法运用于接收端，所述方法包括步骤：
接收发送端发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续，所述发送端与接收端之间基于不可靠协议；
若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；
向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。
在一些例子中，所述向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，包括：
将所述目标编号从预重传缓存区存放至一待重传缓存区；
向发送端或保存有所述数据包的第三端请求所述待重传缓存区中存放的编号对应的数据包。
在一些例子中，所述第一预设时间包括：
当前抖动缓冲时间或历史抖动缓冲时间乘以预设系数的最小值，或历史重传时间的平均值或最小值。
在一些例子中，所述第二预设时间包括：
当前抖动缓冲时间与历史重传时间的平均值或最小值的和。
在一些例子中，所述向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，在满足如下条件时执行：
所述目标编号数量达到第三预设值；或
距上次请求目标编号对应的数据包的时间达到第四预设值。
在一些例子中，所述数据包用于组装成流媒体数据，所述流媒体数据包括关键帧和非关键帧；所述编号还用于标识数据包所属流媒体数据的帧类；
属于关键帧的编号对应的第一预设时间小于属于非关键帧的编号对应的第一预设时间；和/或
属于关键帧的编号对应的第二预设时间大于属于非关键帧的编号对应的第二预设时间。
在本申请的第二方面，提供一种P2P网络中数据重传方法，包括步骤：
接收从P2P网络中的节点及服务器发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续；所述P2P网络中各节点间基于不可靠协议；
若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；
向服务器请求重传目标编号对应的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号，并且所述目标编号的值小于从服务器获取的数据包的最大编号。
在一些例子中，所述接收从P2P网络中的节点及服务器发送的数据包，包括：
接收从P2P网络发送的数据包；
若不存在数据包由服务器发送，则从服务器获取预设时间周期或预设编号间隔的数据包。
在本申请的第三方面，提供一种数据重传装置，包括：
接收模块，用于接收发送端发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续，所述发送端与接收端之间基于不可靠协议；
处理模块，用于若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。
在本申请的第四方面，提供一种P2P网络中数据重传装置，包括：
接收装置，用于接收从P2P网络中的节点及服务器发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续；所述P2P网络中各节点间基于不可靠协议；
处理装置，用于若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；向服务器请求重传目标编号对应的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号，并且所述目标编号的值小于从服务器获取的数据包的最大编号。
在本申请的第五方面，提供一种终端设备，包括：
处理器；以及
存储器，所述存储器被配置成存储计算机程序，所述计算机程序被配置成被所述处理器执行如前述第一方面或第二方面任意一项方法所述的操作。
在本申请的第六方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行如前述第一方面或第二方面任意一项方法所述的操作。
本申请检测到存在数据包丢失或延时，并不是立即请求重传数据包，也不是机械地延时固定时间再去请求重传数据包。而是将缺失的编号存放至一预重传缓存区，然后记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间，来确定需要重传的目标编号对应的数据包以及最佳的数据重传时机。这样接收端就有最大的可能性接收到因为网络因素而迟到的数据包，从而最大程度避免了请求重传数据包后又收到网络延时到达的数据包，减少由于传输延时使得接收到的数据包与重传得到的数据包的重复数量，以致最大限度的降低数据包的冗余，减少重传的网络流量。更进一步地，又不会因为太晚获得重传的数据包而影响数据的使用，例如若数据为流媒体数据，那么可以减少播放过程中的卡顿和/或花屏等问题。
附图说明
图1是数据传输的场景示意图；
图2为本申请实施例示例性示出的一数据重传方法的流程图；
图3为本申请实施例示例性示出的一P2P网络示意图；
图4为本申请实施例示例性示出的一基于P2P网络的数据重传方法的流程图；
图5为本申请实施例示例性示出的另一基于P2P网络的数据重传方法的流程图的具体流程图；
图6为本申请实施例示例性示出的直播场景示意图；
图7为本申请实施例示例性示出的一基于P2P网络的直播中数据重传的流程图；
图8a-图8c为本申请实施例中三种不同的服务器架构下搭建的网络；
图9为本申请实施例示例性示出的数据重传装置的示意图；
图10为本申请实施例示例性示出的一终端设备的示意图；
图11为本申请实施例示例性示出的P2P网络中数据重传装置；
图12为本申请实施例示例性示出的另一终端设备的示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
图1为数据传输的示意图，发送端110与接收端120之间通过网络传输资源数据，若发送端110与接收端120之间采用UDP等不可靠协议，在发送端110与接收端120发生网路抖动或故障时，传输的资源数据可能发生延时或丢失，接收端120若不及时请求发送端110重传未接收到的资源数据，可能影响接收端120对资源数据的使用，例如，若上述传输的资源数据为直播流媒体数据，发送端为服务器，接收端为观众客户端，采用现的数据重传方法，会存在过晚或过早请求重传，若过晚请求重传，会导致观众客户端播放直播流媒体数据时，出现花屏、卡顿或延时等现象，但若太早请求重传，可能会造成数据重复冗余，例如，数据在传输时由于网络抖动而延时，若太早请求重传未接收到的数据，在接收到重传的数据后，可能还会接收到延时的数据，而造成冗余，产生占用网络带宽的问题。
为了解决上述技术问题，本申请提出一种数据重传方法、装置、电子设备及存储介质，参照图2，为本申请实施例示例性示出的一种数据重传方法的流程图，所述方法运用于接收端，所述方法包括步骤：
S210，接收发送端发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续，所述发送端与接收端之间基于不可靠协议。
S220，若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间。
本申请实施例所述的“缺失的编号”指的是，例如：如果收到的数据包的编号包括1-499，以及501-502，数据包编号不连续，缺失的编号为500。
一些例子中，本步骤具体可以是检测到接收到的编号跳变，将跳变后接收到的数据包的编号减一的编号，或跳变前数据包的最大编号加一的编号存放至一预重传缓存区。
本申请实施例所述的“预重传缓存区”可以是一预重传队列，用于存放缺失的编号。一些例子中，所述预重传缓存区中已存放至“待重传缓存区”的编号可以被释放。另一些例子中，若检测到已接收到预重传缓存区中的编号对应的数据包，将该编号从预重传缓存区释放。
本申请实施例所述的“存放时间”可以通过如下方式计算得到：记录编号被存放至预重传缓存区的时间T1，之后会循环检查，例如间隔一定周期检查一次。假如当前时间为T2，判断预重传缓存区中所有编号的T2-T1是否不小于第一预设时间。
本申请实施例所述的“待使用时间”指的是该数据包被用户调用的时间与当前时间的差值，一种常见的使用(调用)方式是播放，例如，所述资源数据为实时流媒体数据，接收端一边接收数据包，一边根据数据包的编号拼装成图像帧和音频帧用于播放，例如，某数据包a用于拼装图像帧a，而图像帧a在T3时刻被播放，T7＝T3-T2(T2为当前时刻)为待使用时间。具体的，由于流媒体数据播放的速度是均匀的(举例来说，假如30fps的流媒体数据播放，那么平均一帧图像帧的播放时间是1000ms/30＝33ms)，因此，可以通过当前播放的帧序号，推测若干时间之后，需要播放的帧序号。比如，当前时间播放第100帧，那么330ms后，需要播放第110帧。可以定期循环检查预重传缓存区的每个编号，对每个编号都通过映射关系得到它的图像帧序号。用图像帧序号和当前图像帧序号相减，并乘以每一帧的播放耗时，就是这个编号对应的数据包的预估的待使用时间，可以记为T7。举例而言：假如当前播放第100帧，预重传队列的某个编号199995对应的图像帧帧序号是120，如果流媒体数据的帧率是30fps，那么编号为199995的预估的待使用时间，也就是T7＝(120-100)*(1000/30)＝660ms。也就是说，再过660ms，就会播放编号为120这个图像帧，编号为199995的数据包在再过T7时会被使用，否则流媒体数据将无法正常播放，可能导致卡顿花屏。
S230，向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。
在一些例子中，本申请所述第一预设时间包括：当前抖动缓冲时间T4或历史抖动缓冲时间T5乘以预设系数α的最小值，例如：若α＝0.5，第一预设时间为{0.5*T4,0.5*T5}min或{0.5*T4,2.5}min，其中2.5是根据历史抖动缓冲时间得出的经验值，α可以是任意数值；或历史重传时间的平均值或最小值。本申请实施例提出的“重传时间”指的是一个从请求重传到接收到该数据包的时间。
在一些例子中，本申请所述第二预设时间包括：当前抖动缓冲时间T4与历史重传时间的平均值T6或最小值T8之和。例如：第二预设时间为T4+T6或T4+T8。一个具体的例子中，以所述资源数据为实时流媒体数据为例，第二预设时间的具体算法可以如下：
记录最近若干次向发送端发送请求到收到接收到数据包的平均时间T6；记录当前的抖动缓冲时间T4；获取待重传缓存区中的编号的待使用时间T7；当T7<＝(T4+T6)，该编号为目标编号。
一些例子中，本步骤可以是接收端向发送端请求所述目标编号对应的数据包。在另外一些例子中，由于复杂的数据传输***中，除了发送端和接收端之外，可能还存在第三端保存有所述数据包，例如服务器，有时该第三端也充当发送端的角色，若数据传输***还包括第三端，则步骤S230中可以是向保存有所述数据包的第三端(例如服务器)请求所述目标编号对应的数据包。
本申请实施例所述的接收端或发送端可以是一应用程序或服务，例如直播客户端，所述接收端或发送端可以被安装在终端设备上，该终端设备可以具有连网功能，例如移动终端(例如智能手机、智能平板及笔记本电脑等)及固定终端(台式电脑、服务器、智能电视及车载终端等)等。本申请不限制终端设备的类型。
本申请实施例所述的不可靠协议可以包括UDP协议等，与所述不可靠协议相对的是可靠协议，例如：TCP协议以及HTTP协议等。
至此，本申请检测到存在数据包丢失或延时，并不是立即请求重传数据包，也不是机械地延时固定时间再去请求重传数据包。而是将缺失的编号存放至一预重传缓存区，然后记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间，来确定需要重传的目标编号对应的数据包以及最佳的数据重传时机。这样接收端就有最大的可能性接收到因为网络因素而迟到的数据包，从而最大程度避免了请求重传数据包后又收到网络延时到达的数据包，减少由于传输延时使得接收到的数据包与重传得到的数据包的重复数量，以致最大限度的降低数据包的冗余，减少重传的网络流量。更进一步地，又不会因为太晚获得重传的数据包而影响数据的使用，例如若数据为流媒体数据，那么可以减少播放过程中的卡顿和/或花屏等问题。
进一步，在一些例子中，上述步骤S230所述向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，具体可以包括：
当所述存放时间达到第一预设时间或所述待使用时间不大于第二预设时间后，将所述缺失的编号从预重传缓存区存放至一待重传缓存区，该被存放至重传缓存区的编号为目标编号；
向发送端或保存有所述数据包的第三端请求所述待重传缓存区中存放的编号对应的数据包。
本申请所述的“待重传缓存区”指的是：可以是一待重传队列，用于存放待向接收端请求重传的数据包的编号。
在一些例子中，可以是循环检查预重传缓存区，在满足所述存放时间达到第一预设时间或所述待使用时间不大于第二预设时间后，将所述缺失的编号从预重传缓存区存放至一待重传缓存区。
实际应用中，当丢包数量较小时，前述实施例所述的方法可以最大限度的降低数据包的冗余，又不影响数据的使用。但是，当丢包数量较大时，每个数据包均单独向发送端请求重传，势必会占用大量的网络带宽，甚至造成网络拥塞。为了解决丢包数量较大的问题，在一些例子中，上述步骤S230可以在满足如下条件时执行：
所述目标编号(例如待重传缓存区中存放的编号)数量达到第三预设值，例如目标编号数量达到10个，执行步骤S230。
距上次请求所述目标编号(例如待重传缓存区中存放的编号)对应的数据包的时间达到第四预设值后执行，例如：若上一次发出重传请求是TA时刻，当当前时刻-TA达到第四预设值，可以执行步骤S230。一些例子中，该第四预设值可以是400ms。
实际应用中发现，若所述数据包拼装得到的资源数据为视频流数据，由于视频流数据中的图像一般可以分为关键帧(例如：I和/或P帧)和非关键帧(例如：B帧)的特殊性。本申请实施例的一个些例子中，所述编号还用于标识数据包所属流媒体数据的帧类；属于关键帧的编号对应的第一预设时间小于属于非关键帧的编号对应的第一预设时间；和/或属于关键帧的编号对应的第二预设时间大于属于非关键帧的编号对应的第二预设时间，即属于关键帧的数据包的优先重传。
一个具体的例子中，所述预重传缓存区包括高优先级预重传缓存区和低优先级预重传缓存区，根据缺失的编号所属的帧类型，将属于关键帧的编号存放至高优先级预重传缓存区，将属于非关键帧的编号存放至低优先级预重传缓存区，其中，高优先级预重传缓存区对应的第一预设时间小于低优先级预重传缓存区，可以将第一预设时间的预设系数α设置为不同值，如，高优先级预重传缓存区的α设置为1/2，低优先级预重传缓存区的α设置为3/5；或者高优先级预重传缓存区对应的第二预设时间大于低优先级预重传缓存区，例如：高优先级预重传缓存区的第二预设时间为T4+T6+经验值x或T4+T8+经验值x，该经验值x可以是100ms。
至此，通过使属于关键帧的数据包的优先重传，可以降低重要数据包丢失的负面影响。
本申请前述的实施例可以运用在P2P网络中，图3是本申请实施例提出的一种网络架构，该网络架构中包括服务器设备300和客户端设备(310、320、330)，客户端设备可以借助服务器设备相互搭建成P2P网络。由于不同的应用环境下，用户对网络设备的功能需求可能不同，因此，每个应用场景中服务器和客户端设备的数量以及功能可以不同。
本申请前述的实施例可以运用在P2P网络中，所述发送端可以是P2P网络中的节点，而所述步骤S230中向服务器请求重传目标编号对应的数据包。
在一个具体的例子中，参照图4，为本申请实施例示例性示出的另一种数据重传的方法的流程图，该方法运用在P2P场景中，该方法包括步骤：
P2P网络中一节点执行S410，接收从P2P网络中的节点发送的数据包。
当然一些例子中，S410可以是接收从P2P网络中的节点以及服务器发送的数据包。
其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续；所述P2P网络中各节点间基于不可靠协议。在一些例子中，节点与服务器之间可以基于可靠协议，也可以基于不可靠协议。
S420，若检测到获取的数据包编号不连续；将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；
S430，向服务器请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。
需要说明的是，图4所述的各步骤可以参照前述实施例，此处不再赘述。
在一些例子中，为了进一步提高P2P网络中数据传输的效率，在一些例子中，不同的数据包根据自身的编号被分成多个组，每个节点可以从不同节点获取不同组的数据包，例如节点1从a节点获取第一组的数据包，从b节点获取第二组数据包。
具体的，一些例子中，可以用各数据包的编号对分组数进行求余，根据求余的余数确定各数据包的分组。例如：一直播流媒体数据被切割成了编号为1-20的数据包，分组数为5，用各数据包的编号对5进行求余，例如编号为1，1/5的余数是1，余数为1的都属于第一组，所以编号为1的数据包属于第一组，以此类推，可以确定各数据包的分组情况，每组分组的数据包组成一路子流，例如余数为0的数据包属于0号子流，余数为1的数据包属于1号子流，以此类推。在一些例子中，所述分组数可以根据流媒体数据的码率或分辨率或承担分发数据包任务的服务器的数量确定，具体求余的策略不做限定。将数据包分组后，服务器可以基于分组将数据包分发给P2P网络中的节点，例如，可以由多个服务器分别将不同组的数据包发送给P2P网络中从服务器获取资源数据的节点，以提高数据传输效率，及增加节点播放流媒体数据的起播速度。当然，在一些例子中，将数据包分组后，每个节点可以从不同的节点获取不同分组的数据，可以进一步提高P2P网络中数据传输效率。
在实际应用中，节点从P2P网络中的节点获取的数据包发生丢包时，为了保证重传的效率和稳定性，会向服务器请求重传数据包。但是由于网络原因，每个服务器上的数据包可能有差别，例如，如果请求重传的数据包的编号为99，而该服务器还未收到编号为99的数据包，那服务器会返回错误，如此，不仅耽误时间，而且可能造成无法通过重传接收到该数据包。为了避免上述问题，在一些例子中，节点会从P2P网络中的其他节点以及服务器获取数据包，并且目标编号的值还需小于从服务器获取的数据包的最大编号。以进一步保证数据重传的稳定性和效率。
参照图5，为本申请实施例示例性示出的另一数据重传方法，执行图4的所述步骤S410：接收从P2P网络中的节点发送的数据包，还执行步骤：S411判断是否存在数据包由服务器发送。例如：在搭建P2P网络时，先向P2P网络中至少一个节点请求连接，连接成功后，从已连接的节点和/或服务器订阅数据包，根据订阅数据包的情况，判断是否存在数据包由服务器发送。
若是，则执行图4的步骤S420、图4步骤S430，并且目标编号满足：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号，并且所述目标编号的值小于从服务器获取的数据包的最大编号。
具体的，节点获取的一部分数据由P2P网络中的节点提供，另一部分数据由服务器提供，例如：数据包分为5组，分别是0-4号子流，节点从服务器获取0号子流，从P2P网络中的至少一个其他节点获取1-4号子流；此时，由于已经从可靠传输的服务器获取了数据包，这些从服务器获取的数据包可以较真实地反映节点应该获取的数据包的情况以及服务器目前拥有数据包的情况，节点可以记录从服务器获取的数据包的最大编号y，使得目标编号的值不大于该最大编号y，一些例子也可以是放入待重传缓存区的编号不可大于该最大编号y。
若不是，则执行步骤S412：从服务器获取预设时间周期或预设编号间隔的数据包，以记录从服务器接收到的数据包的情况；再执行图4的步骤S420、图4步骤S430。
具体的，节点获取的所有数据包均由P2P网络中的节点提供，此时，当节点检测到自身不存在数据包从服务器获取，向服务器发出请求，服务器会按照预设的时间周期或预设的时间间隔给该节点发送数据包，例如：每隔100个编号给节点发送数据包，以使节点可以记录服务器目前拥有数据包的情况，节点可以记录从服务器获取的数据包的最大编号y，使得目标编号的值不大于该最大编号y，一些例子也可以是放入待重传缓存区的编号不可大于该最大编号y。
本申请上述实施例所述的方法还可以运用在直播的P2P场景中。参照图6，为本申请实施例示例性示出的直播场景图。第一观众客户端、第二观众客户端、第三观众客户端及主播客户端分别被安装在终端设备610、620、630及640上，主播客户端可以通过屏幕捕捉，以及配合调用摄像头录制视频、拍摄照片等其他方式制作流媒体数据，流媒体数据包括一帧帧图像帧及音频数据，然后通过网络将制作的流媒体数据发送给服务端600。服务端600用于提供直播的后台服务，例如保存各主播客户端与观众客户端的对应关系，P2P网络的管理，将流媒体数据切割成若干数据包，将数据包按照自定义的格式封装，并进行封装后的数据包的分发等，当第一观众客户端、第二观众客户端及第三客户端与主播客户端在同一直播间内，服务端600可以通知第一观众客户端、第二观众客户端及第三观众客户端建立P2P网络，P2P网络中的第一观众客户端、第二观众客户端及第三观众客户端相互之间可以交互数据包，以减轻服务器的压力，提高各直播客户端获取流媒体数据的效率。P2P网络中的直播客户端也被称为节点。
本申请实施例所述的是指众多用户聚合在一起的社交网络平台、即时通讯平台等，用户通过登录客户端的方式进入直播间，用户在直播间内以成员的身份存在，同一个直播间内包含有多种身份的成员，比如观众、主播等。用户可任意加入或退出直播间。对于具有一定权限的用户，其可添加或删除直播间成员，也可新建或解散直播间，这类具有权限的用户的身份为主播。在直播间内，任意多个成员可进行聊天、通话、视频或推送电子赠品等交互。
本申请实施例所述的“主播客户端”“观众客户端”可以指安装在终端设备上的软件，在某些情况下，所述直播客户端与观众客户端集成在一个软件上，当用户的身份为主播时，该客户端可以被称为主播客户端，当用户的身份是观众时，该客户端被称为观众客户端。本申请说明书中的直播客户端是对主播客户端和观众客户端的统称。
参照图7，为本申请实施例提出的另一重传方法，运用在直播场景中，包括步骤：
S710：主播客户端将采集的流媒体数据发送给服务器。
S720：服务器将接收到的流媒体数据切割成若干数据包，并将每个数据包按照自定义的格式封装，所述自定义的格式中包括编号，编号用于描述每个数据包唯一性。
在数据包封装阶段，为了使切割后的数据包能够被对客户端接收后有序组装以及客户端之间形成对等节点后能够交互数据包，服务器可以为每个数据包编号，作为描述每个数据包唯一标识的字段，某些例子中，可以自定义数据包的格式来实现此目的，自定义的格式中可以规定特定字段作为此唯一标识。
S730：与所述主播客户端在同一直播间的观众客户端建立P2P网络。
S740：服务器将所述封装的数据包分发给P2P网络中订阅服务器的节点；
S750：新进入P2P网络的直播客户端a进入所述直播间，从服务器获取P2P网络的节点列表，向所述节点列表中的至少一个节点发送连接请求；
S760：直播客户端a与响应所述请求的节点建立连接。
S770：直播客户端A与其中一已连接的节点协商订阅数据。
本步骤中，所述被订阅的节点在收到数据包后，将收到的数据包发送给所述观众客户端，通过被订阅的节点主动推送数据的方式，减少被动请求的信令交互的时间，提高数据传输的效率。
S780：直播客户端a接收从P2P网络中的节点及服务器发送的数据包。
S790：直播客户端a若检测到获取的数据包编号不连续，所述缺失的编号对应的数据包不由服务器发送，直播客户端a将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间。
S7100：当所述缺失的编号以及所述存放时间达到第一预设时间或所述待使用时间不大于第二预设时间，且所述缺失的编号小于从服务器获取的数据包的最大编号，直播客户端a将所述缺失的编号从预重传缓存区存放至一待重传缓存区。
S7200：向服务器请求所述待重传缓存区中存放的编号对应的数据包。
图7所述的方法不同于传统的P2P模式，首先将流媒体数据切割成数据包而不是文件块，文件块的大小可能在上百KB，而相对于文件块来说，数据包的可切割粒度更小，可以作为更小的传输单元在网络中传输，例如在考虑切割后的数据包的大小时，可以结合互联网网络层的传输特性来设计，使得数据包的大小与P2P网络中各连接通道的传输带宽匹配。举例来说，各对等节点之间建立的通道可以是UDP通道，每个数据包的大小可以是1KB左右，略小于MTU(互联网网络层最大传输单元)，这样，每个数据包可以由1个IP包传输，不需要出现基于IP包拆包，因此比切割文件的方式效率更高，从而使得具有更广泛的适用场景，尤其是直播场景。
本申请实施例提出的服务器可以由多种实体承担，这取决于设计者对不同网络设备的角色划分。例如，图8a、图8b、图8c是三种不同场景下的网络架构，可以看出，不同业务模式下，由于业务或设备管理的需求不同，可以由不同类型的服务器设备承担上述服务器的功能。图8a中，第一服务器承担收集流媒体数据的角色，第二服务器承担切割数据包的角色，第三服务器作为向对等节点分发数据包的角色。图8b中，第一服务器集成了收集流媒体数据和切割数据包的功能，第二服务器作为分发数据包的服务器。图8c中，服务器将收集流媒体数据、切割数据包、分发数据包的功能集于一体。需要指出，除了图8a、图8b及图8c所列举的示例以外，并不排除有其他形式的网络架构或服务器功能。
在实际应用中，节点在播放流媒体数据时可能会出现短暂的延时或卡顿问题，申请人发现由于直播与传统的P2P技术应用的场景具有很大差别，传统的P2P技术主要应用在共享视频或音频资料的场景(例如视频点播等网站的视频指定数据包下载)，相比与上述场景，直播存在每时每刻均可能有大量的用户进出直播间的特点，使得基于直播的P2P网络时刻动态变化，并且变化频率极快，但这会造成播放流媒体数据时出现短暂的延时或卡顿问题。为了解决上述直播中的问题，在一些例子中，所述方法还包括步骤：记录与本节点已连接的节点数量；
当与本直播客户端已连接的节点数量少于预设值时，再次向服务器发送获取节点列表的请求。例如：本直播客户端与3个节点已连接，分别为节点1、节点2及节点3，但是由于网络抖动或节点1、节点2及节点3其中一节点退出直播间，那么，与本直播客户端保持连接状态的节点数量可能少于预设值，当少于预设值时，再次向服务器发送获取节点列表的请求，并向获取的节点列表中的节点发送连接请求，以保证与本直播客户端建立连接的节点数量少于预设值，使得本直播客户端获取流媒体数据的节点退出直播间，或是网络故障时，本直播客户端可以快速从其他成功连接的节点获取流媒体数据，以保证本端用户观看时延时和卡顿较少，极好地适应直播场景。
请参见图9，数据重传装置900，包括：
接收模块910，用于接收发送端发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续，所述发送端与接收端之间基于不可靠协议；
处理模块920，用于若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。
图9中数据重传装置的实施例可以应用在终端设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在终端设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图10所示，为本申请数据重传装置所在终端设备的一种硬件结构图，除了图10所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的客户端设备通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。处理器被用于执行：
接收发送端发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续，所述发送端与接收端之间基于不可靠协议；
若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；
向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。
请参见图11，提供一种P2P网络中数据重传装置1100，包括：
接收装置1110，用于接收从P2P网络中的节点及服务器发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续；所述P2P网络中各节点间基于不可靠协议；
处理装置1120，用于若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；向服务器请求重传目标编号对应的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号，并且所述目标编号的值小于从服务器获取的数据包的最大编号。
图11中P2P网络中数据重传装置的实施例可以应用在终端设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在终端设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图12所示，为本申请P2P网络中数据重传装置所在终端设备的一种硬件结构图，除了图12所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的客户端设备通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。处理器被用于执行：
接收从P2P网络中的节点及服务器发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续；所述P2P网络中各节点间基于不可靠协议；
若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；
向服务器请求重传目标编号对应的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号，并且所述目标编号的值小于从服务器获取的数据包的最大编号。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
在本申请实施例中，计算机可读存储介质可以是多种形式，比如，在不同的例子中，所述机器可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。特殊的，所述的计算机可读介质还可以是纸张或者其他合适的能够打印程序的介质。使用这些介质，这些程序可以被通过电学的方式获取到(例如，光学扫描)、可以被以合适的方式编译、解释和处理，然后可以被存储到计算机介质中。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (12)

1.一种数据重传方法，其特征在于，所述方法运用于接收端，所述方法包括步骤：
接收发送端发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续，所述发送端与接收端之间基于不可靠协议；
若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；
向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。
2.根据权利要求1所述的方法，其特征在于，所述向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，包括：
将所述目标编号从预重传缓存区存放至一待重传缓存区；
向发送端或保存有所述数据包的第三端请求所述待重传缓存区中存放的编号对应的数据包。
3.根据权利要求1所述的方法，其特征在于，所述第一预设时间包括：
当前抖动缓冲时间或历史抖动缓冲时间乘以预设系数的最小值，或历史重传时间的平均值或最小值。
4.根据权利要求1所述的方法，其特征在于，所述第二预设时间包括：
当前抖动缓冲时间与历史重传时间的平均值或最小值的和。
5.根据权利要求1所述的方法，其特征在于，所述向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，在满足如下条件时执行：
所述目标编号数量达到第三预设值；或
距上次请求目标编号对应的数据包的时间达到第四预设值。
6.根据权利要求1所述的方法，其特征在于，所述数据包用于组装成流媒体数据，所述流媒体数据包括关键帧和非关键帧；所述编号还用于标识数据包所属流媒体数据的帧类；
属于关键帧的编号对应的第一预设时间小于属于非关键帧的编号对应的第一预设时间；和/或
属于关键帧的编号对应的第二预设时间大于属于非关键帧的编号对应的第二预设时间。
7.一种P2P网络中数据重传方法，其特征在于，包括步骤：
接收从P2P网络中的节点及服务器发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续；所述P2P网络中各节点间基于不可靠协议；
若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；
向服务器请求重传目标编号对应的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号，并且所述目标编号的值小于从服务器获取的数据包的最大编号。
8.根据权利要求7所述的方法，其特征在于，所述接收从P2P网络中的节点及服务器发送的数据包，包括：
接收从P2P网络发送的数据包；
若不存在数据包由服务器发送，则从服务器获取预设时间周期或预设编号间隔的数据包。
9.一种数据重传装置，其特征在于，包括：
接收模块，用于接收发送端发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续，所述发送端与接收端之间基于不可靠协议；
处理模块，用于若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；向发送端或保存有所述数据包的第三端请求重传目标编号的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号。
10.一种P2P网络中数据重传装置，其特征在于，包括：
接收装置，用于接收从P2P网络中的节点及服务器发送的数据包，其中，所述数据包携带用于描述数据包的唯一性的编号，所述编号连续；所述P2P网络中各节点间基于不可靠协议；
处理装置，用于若检测到获取的数据包编号不连续，将缺失的编号存放至一预重传缓存区，并记录所述缺失的编号的存放时间，及计算所述缺失的编号对应的数据包的待使用时间；向服务器请求重传目标编号对应的数据包，其中，所述目标编号包括：存放时间达到第一预设时间或所述待使用时间不大于第二预设时间的编号，并且所述目标编号的值小于从服务器获取的数据包的最大编号。
11.一种终端设备，其特征在于，包括：
处理器；以及
存储器，所述存储器被配置成存储计算机程序，所述计算机程序被配置成被所述处理器执行如权利要求1至8任意一项方法所述的操作。
12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行如权利要求1至8任意一项方法所述的操作。
CN201811354499.0A 2018-11-14 2018-11-14 一种数据重传方法、装置、终端设备及存储介质 Active CN109560901B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811354499.0A CN109560901B (zh) 2018-11-14 2018-11-14 一种数据重传方法、装置、终端设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811354499.0A CN109560901B (zh) 2018-11-14 2018-11-14 一种数据重传方法、装置、终端设备及存储介质

Publications (2)

Publication Number Publication Date
CN109560901A true CN109560901A (zh) 2019-04-02
CN109560901B CN109560901B (zh) 2021-09-21

Family

ID=65866369

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811354499.0A Active CN109560901B (zh) 2018-11-14 2018-11-14 一种数据重传方法、装置、终端设备及存储介质

Country Status (1)

Country Link
CN (1) CN109560901B (zh)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110602568A (zh) * 2019-08-07 2019-12-20 武汉兴图新科电子股份有限公司 一种基于rtp的视频流传输丢包重传方法、设备及存储设备
CN110889648A (zh) * 2019-12-09 2020-03-17 金蝶软件（中国）有限公司 单据编号方法、服务器以及存储介质
CN111162857A (zh) * 2019-12-23 2020-05-15 成都德芯数字科技股份有限公司 一种数据包的接收方法、装置及调频应急广播***
CN111193936A (zh) * 2019-12-27 2020-05-22 腾讯科技（深圳）有限公司 视频流传输方法、装置、电子设备及计算机可读存储介质
CN111669610A (zh) * 2020-05-27 2020-09-15 北京奇艺世纪科技有限公司 直播视频的传输方法、***、装置、服务器及、电子设备及存储介质
CN112398797A (zh) * 2019-08-19 2021-02-23 贵州白山云科技股份有限公司 数据传输方法、接收装置、发送装置、介质、设备及***
CN112584525A (zh) * 2020-12-07 2021-03-30 广州技象科技有限公司 基于多用户接入的上行数据分割方法及装置
CN112769708A (zh) * 2019-11-05 2021-05-07 北京华为数字技术有限公司 数据传输的方法、装置及计算机可读存储介质
CN112969075A (zh) * 2021-01-29 2021-06-15 北京字节跳动网络技术有限公司 直播过程中的补帧方法、装置及计算设备
CN113392667A (zh) * 2021-08-17 2021-09-14 深圳市成为信息技术有限公司 一种读写器的数据传输方法、数据接收器及存储介质
CN114499777A (zh) * 2022-04-15 2022-05-13 四川腾盾科技有限公司 一种集群无人***数据传输方法
CN114598628A (zh) * 2020-12-04 2022-06-07 中兴通讯股份有限公司 一种网络检测丢包方法、电子设备及计算机可读存储介质
CN114866196A (zh) * 2021-01-19 2022-08-05 武汉斗鱼鱼乐网络科技有限公司 数据包重传方法、装置、电子设备和存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080198748A1 (en) * 2007-02-16 2008-08-21 Gilfix Michael A System and Method for Burst Traffic Smoothing for SIP Processing Elements
CN102045362A (zh) * 2010-12-21 2011-05-04 北京高森明晨信息科技有限公司 一种基于udp协议的数据传输方法和***
CN103763073A (zh) * 2014-01-09 2014-04-30 深圳市迪威视讯股份有限公司 一种丢包重传的方法及终端
CN103957169A (zh) * 2014-05-14 2014-07-30 上海复兰信息科技有限公司 一种基于反向请求的可靠udp的实现方法
CN106792262A (zh) * 2016-12-05 2017-05-31 乐视控股（北京）有限公司 视频数据传输方法及装置
CN107147481A (zh) * 2017-07-19 2017-09-08 北京数码视讯科技股份有限公司 丢包重传方法、装置及电子设备
CN107979449A (zh) * 2016-10-25 2018-05-01 杭州海康威视数字技术股份有限公司 一种数据传输方法及装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080198748A1 (en) * 2007-02-16 2008-08-21 Gilfix Michael A System and Method for Burst Traffic Smoothing for SIP Processing Elements
CN102045362A (zh) * 2010-12-21 2011-05-04 北京高森明晨信息科技有限公司 一种基于udp协议的数据传输方法和***
CN103763073A (zh) * 2014-01-09 2014-04-30 深圳市迪威视讯股份有限公司 一种丢包重传的方法及终端
CN103957169A (zh) * 2014-05-14 2014-07-30 上海复兰信息科技有限公司 一种基于反向请求的可靠udp的实现方法
CN107979449A (zh) * 2016-10-25 2018-05-01 杭州海康威视数字技术股份有限公司 一种数据传输方法及装置
CN106792262A (zh) * 2016-12-05 2017-05-31 乐视控股（北京）有限公司 视频数据传输方法及装置
CN107147481A (zh) * 2017-07-19 2017-09-08 北京数码视讯科技股份有限公司 丢包重传方法、装置及电子设备

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110602568B (zh) * 2019-08-07 2021-06-25 武汉兴图新科电子股份有限公司 一种基于rtp的视频流传输丢包重传方法、设备及存储设备
CN110602568A (zh) * 2019-08-07 2019-12-20 武汉兴图新科电子股份有限公司 一种基于rtp的视频流传输丢包重传方法、设备及存储设备
CN112398797A (zh) * 2019-08-19 2021-02-23 贵州白山云科技股份有限公司 数据传输方法、接收装置、发送装置、介质、设备及***
CN112769708A (zh) * 2019-11-05 2021-05-07 北京华为数字技术有限公司 数据传输的方法、装置及计算机可读存储介质
CN110889648A (zh) * 2019-12-09 2020-03-17 金蝶软件（中国）有限公司 单据编号方法、服务器以及存储介质
CN111162857A (zh) * 2019-12-23 2020-05-15 成都德芯数字科技股份有限公司 一种数据包的接收方法、装置及调频应急广播***
CN111193936A (zh) * 2019-12-27 2020-05-22 腾讯科技（深圳）有限公司 视频流传输方法、装置、电子设备及计算机可读存储介质
CN111193936B (zh) * 2019-12-27 2021-11-12 腾讯科技（深圳）有限公司 视频流传输方法、装置、电子设备及计算机可读存储介质
CN111669610A (zh) * 2020-05-27 2020-09-15 北京奇艺世纪科技有限公司 直播视频的传输方法、***、装置、服务器及、电子设备及存储介质
CN114598628A (zh) * 2020-12-04 2022-06-07 中兴通讯股份有限公司 一种网络检测丢包方法、电子设备及计算机可读存储介质
WO2022116976A1 (zh) * 2020-12-04 2022-06-09 中兴通讯股份有限公司 一种网络检测丢包方法、电子设备及计算机可读存储介质
CN112584525A (zh) * 2020-12-07 2021-03-30 广州技象科技有限公司 基于多用户接入的上行数据分割方法及装置
CN112584525B (zh) * 2020-12-07 2023-02-03 广州技象科技有限公司 基于多用户接入的上行数据分割方法及装置
CN114866196A (zh) * 2021-01-19 2022-08-05 武汉斗鱼鱼乐网络科技有限公司 数据包重传方法、装置、电子设备和存储介质
CN114866196B (zh) * 2021-01-19 2024-05-24 北京神州数码云科信息技术有限公司 数据包重传方法、装置、电子设备和存储介质
CN112969075A (zh) * 2021-01-29 2021-06-15 北京字节跳动网络技术有限公司 直播过程中的补帧方法、装置及计算设备
CN113392667A (zh) * 2021-08-17 2021-09-14 深圳市成为信息技术有限公司 一种读写器的数据传输方法、数据接收器及存储介质
CN114499777A (zh) * 2022-04-15 2022-05-13 四川腾盾科技有限公司 一种集群无人***数据传输方法

Also Published As

Publication number Publication date
CN109560901B (zh) 2021-09-21

Similar Documents

Publication Publication Date Title
CN109560901A (zh) 一种数据重传方法、装置、终端设备及存储介质
WO2020192152A1 (zh) 视频传输的方法、根节点、子节点、p2p服务器和***
CN109474684B (zh) 一种获取直播视频流的方法、装置、终端设备及存储介质
Gusev et al. Ndn-rtc: Real-time videoconferencing over named data networking
US9438494B2 (en) Apparatus and methods for optimizing network data transmission
CN113271316B (zh) 多媒体数据的传输控制方法和装置、存储介质及电子设备
WO2018121742A1 (zh) 一种流数据的传输方法和装置
US7643420B2 (en) Method and system for transmission control protocol (TCP) traffic smoothing
US9363188B2 (en) Cable modem termination system control of cable modem queue length
RU2647654C2 (ru) Система и способ доставки аудиовизуального контента в клиентское устройство
CN110445723B (zh) 一种网络数据调度方法及边缘节点
TW201540031A (zh) 實現客戶端側的傳送功能的傳輸加速器
EP1473636A1 (en) Information processing device and method, and computer program
Krawiec et al. DASCo: dynamic adaptive streaming over CoAP
CN110191315B (zh) 一种基于视联网的监控查看方法和装置
CN108924609A (zh) 流媒体数据传输的方法、电子设备、装置及存储介质
CN110474721A (zh) 视频数据传输方法、装置及计算机可读存储介质
CN109561137A (zh) 建立p2p网络的方法、装置、终端设备及介质
CN109510868A (zh) 一种建立p2p网络的方法、装置、终端设备及存储介质
CN116261021B (zh) 一种视频流播放方法、装置、电子设备及存储介质
CN113726817B (zh) 一种流媒体数据的传输方法、装置及介质
CN111245733A (zh) 一种数据传输的方法和装置
CN109040199A (zh) 一种分发资源数据的方法、***及存储介质
CN110086772B (zh) 一种监控视频的获取方法和***
Jonglez End-to-end mechanisms to improve latency in communication networks

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
GR01 Patent grant
GR01 Patent grant