CN101854286A - 基于用户数据报协议的数据流发送、接收方法及装置 - Google Patents

Abstract

本发明公开了一种基于用户数据报协议的数据流发送、接收方法及装置，涉及多媒体网络通信技术领域。为了解决现有技术中，由于UDP包较大，所造成的IP层切分后数据包容易在网络传输中丢失的问题而发明。本发明提供的基于用户数据报协议的数据流发送方法，包括：将多媒体数据切分为不大于预设值的数据段；将所述数据段封装在用户数据报协议子包中；发送携带有所述用户数据报协议子包的用户数据报协议包。采用本发明可以降低IP层数据传输中的UDP包丢失的概率，还可以提高数据流的时效性。

Description

基于用户数据报协议的数据流发送、接收方法及装置

技术领域

本发明涉及多媒体网络通信技术领域，尤其涉及一种基于用户数据报协议的数据流传输技术。

背景技术

随着多媒体网络应用的快速发展，网络视音频的应用越来越广泛。在带宽一定的条件下，网络多媒体数据的传输要求尽可能的高效可靠。但是，由于多媒体数据具有的数据量大，实时性要求高，需要根据具体应用的不同侧重点选择不同底层网络传输协议，进而设计不同的视音频数据流的传输方法。

目前，TCP(Transmission Control Protocol，传输控制协议)和UDP(UserDatagram Protocol，用户数据报协议)是两种使用广泛的网络传输协议。在网络多媒体数据的传输应用中，TCP提供的是面向连接的、可靠的数据流传输，而UDP提供的是非面向连接的、不可靠的数据流传输。TCP能够通过丢包重传机制保证传输数据的可靠性；而UDP的传输速度较快，开销也比TCP小。如果网络多媒体传输要求实时性较高，即数据传输速度较快，而对于丢失数据则有一定的容忍度，则该网络多媒体应用可以采用基于UDP的机制实现。

在实现本发明的过程中，发明人发现现有技术中至少存在如下问题：

在网络多媒体数据采用UDP机制进行数据流传输时，由于UDP提供的是非面向连接的，不可靠的数据流传输，所以很容易造成传输数据流中数据包的丢失。尤其是当网络多媒体数据传输过程中的UDP包较大时，所述的UDP包首先需要包切分，才可以在IP层进行传输。这样，就使得切分后的UDP数据包更加容易受到网络原因的影响而导致切分后UDP数据的丢失，从而使得整个UDP包被丢弃。

发明内容

为了解决现有技术中，由于UDP包较大，所造成的IP层切分后数据包容易在网络传输中丢失的问题。本发明提供了一种基于用户数据报协议的数据流发送、接收方法及装置。

在实现本发明技术方案的过程中，本发明提供了一种基于用户数据报协议的数据流发送方法。该方法，包括：

将多媒体数据切分为不大于预设值的数据段；

将所述数据段封装在用户数据报协议子包中；

发送携带有所述用户数据报协议子包的用户数据报协议包。

在实现本发明技术方案的过程中，本发明提供了一种基于用户数据报协议的数据流接收方法。该方法，包括：

接收携带有所述用户数据报协议子包的用户数据报协议包；

将所述的用户数据报协议包进行排序。

在实现本发明技术方案的过程中，本发明还提供了一种基于用户数据报协议的数据流发送装置。该装置，包括：

数据切分单元，用于将多媒体数据切分为不大于预设值的数据段；

子包获取单元，用于将所述数据段封装在用户数据报协议子包中；

信息发送单元，用于发送携带有所述用户数据报协议子包的用户数据报协议包。

在实现本发明技术方案的过程中，本发明还提供了一种基于用户数据报协议的数据流接收装置。该装置，包括：

信息接收单元，用于接收携带有所述用户数据报协议子包的用户数据报协议包；

数据排序单元，用于将所述的用户数据报协议包进行排序。

本发明实施例提供的一种基于用户数据报协议的数据流发送、接收方法及装置，通过将多媒体数据切分为不大于预设值的数据段；并将所述数据段封装在用户数据报协议子包中；发送携带有所述用户数据报协议子包的用户数据报协议包给客户端。其中，由于所述的发送给客户端的用户数据报协议包中携带的用户数据报协议子包负载不大于预设值，所述当所述携带有用户数据报协议子包的用户数据报协议包传输到IP层时不需要进行切分就可以直接进行传输。与现有技术将负载较大的UDP切分后在IP进行传输相比，本发明实施例可以将所述携带有所述用户数据报协议子包的UDP包不需切分直接在IP层进行传输，大大降低UDP数据包切分后的丢失概率，从而提高了客户端多媒体播放质量。

附图说明

图1为本发明实施例提供的一种基于用户数据报协议的数据流发送方法的第一实施例流程图；

图2为本发明实施例提供的一种基于用户数据报协议的数据流发送方法的第二实施例流程图；

图3为本发明实施例提供的一种基于用户数据报协议的数据流发送装置结构示意图；

图4为本发明实施例提供的一种基于用户数据报协议的数据流接收方法的第一实施例流程图；

图5为本发明实施例提供的一种基于用户数据报协议的数据流接收方法的第二实施例流程图；

图6为本发明实施例提供的一种基于用户数据报协议的数据流接收装置结构示意图。

具体实施方式

下面结合附图对本发明实施例提供的一种基于用户数据报协议的数据流发送、接收方法及装置进行详细描述。

如图1所示，本发明实施例提供的一种基于用户数据报协议的数据流发送方法的第一实施例；在实现本发明实施例的过程中，该方法，包括：

101：将多媒体数据切分为不大于预设值的数据段；由于基于UDP协议进行传输的多媒体数据包括：视频数据和音频数据两类；所以将多媒体数据切分也就是将传输给客户端的视频数据和音频数据进行切分。其中，所述的预设值可以为128字节。

102：将所述数据段封装在用户数据报协议子包中；

将所述多媒体数据切分后的数据段封装在用户数据报协议子包中；即可将切分后的视频数据段和音频数据段分别封装在用户数据用户数据报协议子包中。

103：发送携带有所述用户数据报协议子包的用户数据报协议包。

需要注意的是，所述用户数据报协议子包，包括：子包头类型字段、子包负载大小字段、子包时间戳字段和子包负载数据字段。所述用户数据报协议子包格式如下表所示：

其中，HeadType是子包头类型字段，用于指示该子包头的类型；Size是子包负载大小字段，用于指示该子包负载的大小，不包括子包内各个字段的大小；所述子包负载的大小不会超过128个字节；Time是子包时间戳字段，用于指示该子包的时间戳。

以下对HeadType的每个bit位进行详细说明，其格式如下表所示：

由于使用UDP传输的只有视频和音频两类数据，所以可用bit8为1来标识子包包含的是视频数据；用bit8为0来标识子包包含的是音频数据。由于流编号是通过5个bit位来标识一个客户端和服务器端建立一个连接后可以同时传输网络流的个数，因此，一个客户端和服务器端之间最多可以同时传输32个网络流。也就是说，同一连接可以同时传输多个网络流，最多为32个。

需要注意的是，以上所述同一连接可以同时传输的多个网络流可以根据实际情况的需要对最多网络流进行调整。

以下再对子包负载大小字段size和子包时间戳字段time进行详细说明；以上所述的子包负载大小字段size和子包时间戳字段time并非每次都全部出现。所述字段是否出现根据子包头类型的2个bit位而定。其含义分别表示如下表：

还需要注意的是，因为一个子包的负载数据最多为128个字节，如果每次UDP包只携带一个子包进行传输，则包头开销相对较大。为了既保证UDP包在IP层进行传输时不切分，又使得UDP包头开销降低，本发明实施例还可以采用交叉子包进行数据传输。即允许一个UDP包一次可以传送多个粘结在一起的子包，通过区分不同的通道和流的编号在接收端对粘结的包内容进行重组。这样使得一次传输可以传输多种类型的内容，且几个不同类型的较短的子包片可以提供更好的实时性。例如，一个UDP包中同时负载了音频和视频数据，比起依次发送音频包和视频包来说，客户端能更快地进行音频与视频的同步。此外，当出现丢包情况时，由于每次每个类型的数据传输量不大，丢失后对客户端播放多媒体数据的影响也较小。

如图2所示，为本发明实施例提供的一种基于用户数据报协议的数据流发送方法的第二实施例；在实现本发明实施例的过程中，该方法，包括：

201：当接收到客户端发送的连接建立请求时，判断是否有空闲传输通道及相关资源为客户端提供服务；

202：如果有为客户端提供服务的空闲传输通道及相关资源，获取客户端所需的多媒体数据；继续执行步骤204；

203：如果没有为客户端提供服务的空闲传输通道及相关资源，发送连接已满消息通知客户端。

204：将多媒体数据切分为不大于预设值的数据段；也就是说，将客户端需要的多媒体数据进行切分，将所述多媒体数据切分为不大于预设值的数据段；该预设值可以为128字节；

205：将所述数据段封装在用户数据报协议子包中；

206：按照时间顺序，对所述用户数据报协议子包进行排序；

207：将负载总和不大于546字节的所述时间顺序接近的用户数据报协议子包粘结，并封装在用户数据报协议包；

需要注意的是，本发明实施例将UDP包负载的大小限制在546字节以内，这样负载加上UDP包头长度8字节、UDP编号字段长度2字节以及IP包头长度20字节，就不高于公网最大传输单元MTU的576字节，一般不再需要拆包。因此，当所述的用户数据报协议子包所承载的数据不大于128字节时，一个UDP包可以搭载4个用户数据报协议子包。

还需要注意的是，当封装UDP包时，可以通过如下方法进行子包粘结：

1、按照时间顺序分别排列视频用户数据报协议子包和音频用户数据报协议子包；

2、时间戳不接近时，按照时间戳顺序组合用户数据报协议子包；

3、时间戳接近时，如果存在视频用户数据报协议子包和音频用户数据报协议子包，则将这两类子包交叉组合；

4、UDP包总负载长度不能超过546字节。如果粘接一个子包使得负载可能超过546字节，则应将该子包放入下一个UDP包中。

208：发送携带有所述用户数据报协议子包的用户数据报协议包。

还需要注意的是，当服务器端发送一定数量的所述用户数据报协议包之后，

服务器端判断当前客户端与所述服务器端是否连接；

如果当前客户端与所述服务器端是连接的，则继续发送用户数据报协议包；

如果当前客户端与所述服务器端是断开的，则停止发送用户数据报协议包。

如图3所示，为本发明实施例提供的一种基于用户数据报协议的数据流发送装置；在实现本发明实施例的过程中，该装置，包括：

判断单元301，用于当接收到客户端发送的连接建立请求时，判断是否有空闲传输通道及相关资源为客户端提供服务；

数据获取单元302，用于如果有为客户端提供服务的空闲传输通道及相关资源，获取客户端所需的多媒体数据；

数据切分单元303，用于将多媒体数据切分为不大于预设值的数据段；该预设值可以为128字节；

子包获取单元304，用于将所述数据段封装在用户数据报协议子包中；其中，所述用户数据报协议子包所承载的数据不大于128字节；

排序单元305，用于按照时间顺序，对所述用户数据报协议子包进行排序；

子包粘结单元306，用于将负载总和不大于546字节的所述时间顺序接近的用户数据报协议子包粘结，并封装在用户数据报协议包。

信息发送单元307，用于发送携带有所述用户数据报协议子包的用户数据报协议包；还用于如果没有为客户端提供服务的空闲传输通道及相关资源，发送连接已满消息通知客户端。

需要注意的是，该装置还包括：

当服务器端发送一定数量的所述用户数据报协议包之后，还包括：

连接判断单元，用于判断当前客户端与所述服务器端是否连接；

如果当前客户端与所述服务器端是连接的，则继续发送用户数据报协议包；

如果当前客户端与所述服务器端是断开的，则停止发送用户数据报协议包。

如图4所示，为本发明实施例提供的一种基于用户数据报协议的数据流接收方法的第一实施例；在实现本发明实施例的过程中，该方法，包括：

401：接收携带有所述用户数据报协议子包的用户数据报协议包；

402：将所述的用户数据报协议包进行排序。

如图5所示，为本发明实施例提供的一种基于用户数据报协议的数据流接收方法的第二实施例；在实现本发明实施例的过程中，该方法，包括：

501：接收携带有所述用户数据报协议子包的用户数据报协议包；

502：将所述的用户数据报协议包进行排序；

503：判断所述的用户数据报协议包的顺序是否连续；

504：如果所述的用户数据包协议包的顺序是不连续的，则进行相应的丢包处理。例如：当客户端发现其接收到的数据包乱序，即客户端当前应该接收到的UDP包的编号为m，而实际接收到的UDP包的编号为n，且n大于m，则编号为m与n之间的UDP包可能丢失，也可能延迟；

需要注意的是，当所述的用户数据报协议包的顺序不连续时，

启动定时器；等待一段时间，即如果客户端在等待的这段时间内对UDP包重排序，同时等待延迟的包。

当定时器定时超时，判断所述丢失的用户数据报协议包是否携带有配置信息；也就是说当定时器定时超后，客户端仍未收到缺失的数据包，则确认所述数据包丢失，并进一步判断所述丢失的用户数据报协议包是否携带有配置信息；例如：当定时器所定时间t超时后，m与n之间仍然缺UDP包则认为所述的UDP包丢失，判断所述丢失的UDP包是否携带有配置信息。

如果所述的丢失的UDP包携带有配置信息，则发送所述用户数据报协议包重传信息；由于传输多媒体数据的通道编号和多媒体流的编号之间有对应关系，所以当收到一个子包头不足5位的负载子包时，而该子包的包头信息中所含的通道编号是当前不存在的编号时，可以确定发生了新流的负载包丢失的状况。当新流的负载包丢失时，重传与否取决于新流的数据播放信息是否为配置信息，也就是说是否重传需要确定该子包中携带的数据信息是否为客户端进行数据播放的配置信息；如果为配置信息，则进行重传；如果不是配置信息，则丢弃。

如果所述的丢失的用户数据报协议包携带的不是配置信息，则按照当前接收的用户数据报协议包进行同步更新。例如：当定时器超时后，客户端端将从m之后编号最小的UDP包开始，对各个通道分别寻找第一个含有时间戳的负载子包，利用这些负载子包中的时间戳进行同步更新，该时间戳之前的的子包全部丢弃，并根据这些时间戳对各个通道进行相应的同步更新。

还需要注意的是，当客户端已从服务器断开，或者由于网络原因导致连接终止时，服务器应能够获得消息，停止继续发送UDP包，这可以通过让客户端每收到一定数量UDP包后给服务器端返回一个反馈数据包来实现。当服务器端接受此反馈数据包超时或者在一定的时间内没有收到反馈数据包，则服务器端可以判断连接已经中断，停止发送UDP包。也就是说，

当客户端接收到一定数量的所述用户数据报协议包后，

发送反馈数据包；其中，所述反馈数据包用于通知服务器端与客户端保持连接状态。此处，客户端可以通过启动定时器，或者计数器；控制反馈数据包的发送；当所述的定时器定时时间到或者计数器的计数满足条件时，发送反馈数据包。

如图6所示，为本发明实施例提供的一种基于用户数据报协议的数据流接收装置；在实现本发明实施例的过程中，该装置，包括：

信息接收单元601，用于接收携带有所述用户数据报协议子包的用户数据报协议包；

数据排序单元602，用于将所述的用户数据报协议包进行排序。

顺序判断单元603，用于判断所述的用户数据报协议包的顺序是否连续；

丢包处理单元604，用于如果所述的用户数据包协议包的顺序是不连续的，则进行相应的丢包处理。

需要注意的是，当所述的用户数据报协议包的顺序不连续时，还包括：

定时器启动单元，用于启动定时器；

信息类型判断单元，用于当定时器定时超时，判断所述丢失的用户数据报协议包是否携带有配置信息；

重传信息发送单元，用于如果所述的丢失的用户数据报协议包携带有配置信息，则发送所述用户数据报协议包重传信息；

同步更新单元，用于如果所述的丢失的用户数据报协议包携带的不是配置信息，则按照当前接收的用户数据报协议包进行同步更新。

还需要注意的是，当接收到所述用户数据报协议包后，

反馈数据包发送单元，用于发送反馈数据包；其中，所述反馈数据包用于通知服务器端与客户端保持连接状态。具体的讲：

当客户端与服务器端进行数据交互时，客户端还可以通过启动单元来启动定时器或者计数器来控制反馈数据包的发送；即

所述反馈数据包发送单元，用于当所述的定时器定时时间到或者计数器的计数满足条件时，发送反馈数据包；其中，所述的反馈数据包用于通知服务器端当前客户端与服务器端的连接状态。

本发明实施例提供的一种基于用户数据报协议的数据流发送、接收方法及装置，通过将多媒体数据切分为不大于预设值的数据段；并将所述数据段封装在用户数据报协议子包中；发送携带有所述用户数据报协议子包的用户数据报协议包给客户端。其中，由于所述的发送给客户端的用户数据报协议包中携带的用户数据报协议子包负载不大于预设值，所述当所述携带有用户数据报协议子包的用户数据报协议包传输到IP层时不需要进行切分就可以直接进行传输。与现有技术将负载较大的UDP切分后在IP进行传输相比，本发明实施例可以将所述携带有所述用户数据报协议子包的UDP包不需切分直接在IP层进行传输，大大降低UDP数据包切分后的丢失概率，从而提高了客户端多媒体播放质量。

通过以上的实施方式的描述，本领域普通技术人员可以理解：实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，包括如上述方法实施例的步骤，所述的存储介质，如：ROM/RAM、磁碟、光盘等。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (19)

1.一种基于用户数据报协议的数据流发送方法，其特征在于，包括：

将多媒体数据切分为不大于预设值的数据段；

将所述数据段封装在用户数据报协议子包中；

发送携带有所述用户数据报协议子包的用户数据报协议包。

2.根据权利要求1所述的基于用户数据报协议的数据流发送方法，其特征在于，所述将所述数据段封装在用户数据报协议子包中的步骤之后，还包括：

按照时间顺序，对所述用户数据报协议子包进行排序；

将负载总和不大于546字节的所述时间顺序接近的用户数据报协议子包粘结，并封装在用户数据报协议包。

3.根据权利要求1所述的基于用户数据报协议的数据流发送方法，其特征在于，所述用户数据报协议子包，包括：子包头类型字段、子包负载大小字段、子包时间戳字段和子包负载数据字段。

4.根据权利要求1至3中任意一项所述的基于用户数据报协议的数据流发送方法，其特征在于，所述将多媒体数据切分为不大于预设值的数据段的步骤之前，还包括：

当接收到客户端发送的连接建立请求时，判断是否有空闲传输通道及相关资源为客户端提供服务；

如果有为客户端提供服务的空闲传输通道及相关资源，获取客户端所需的多媒体数据；

如果没有为客户端提供服务的空闲传输通道及相关资源，发送连接已满消息通知客户端。

5.根据权利要求4所述的基于用户数据报协议的数据流发送方法，其特征在于，当服务器端发送一定数量的所述用户数据报协议包之后，还包括：

判断当前客户端与所述服务器端是否连接；

如果当前客户端与所述服务器端是连接的，则继续发送用户数据报协议包；

如果当前客户端与所述服务器端是断开的，则停止发送用户数据报协议包。

6.一种基于用户数据报协议的数据流接收方法，其特征在于，包括：

接收携带有所述用户数据报协议子包的用户数据报协议包；

将所述的用户数据报协议包进行排序。

7.根据权利要求6所述的基于用户数据报协议的数据流接收方法，其特征在于，还包括：

判断所述的用户数据报协议包的顺序是否连续；

如果所述的用户数据包协议包的顺序是不连续的，则进行相应的丢包处理。

8.根据权利要求7所述的基于用户数据报协议的数据流接收方法，其特征在于，当所述的用户数据报协议包的顺序不连续时，

启动定时器；

当定时器定时超时，判断所述丢失的用户数据报协议包是否携带有配置信息；

如果所述的丢失的用户数据报协议包携带有配置信息，则发送所述用户数据报协议包重传信息；

如果所述的丢失的用户数据报协议包携带的不是配置信息，则按照当前接收的用户数据报协议包进行同步更新。

9.根据权利要求6至8中任意一项所述的基于用户数据报协议的数据流接收方法，其特征在于，当接收到所述用户数据报协议包后，

发送反馈数据包；其中，所述反馈数据包用于通知服务器端与客户端保持连接状态。

10.根据权利要求9所述的基于用户数据报协议的数据流接收方法，其特征在于，当客户端与服务器端进行数据交互时，

启动定时器，或者计数器；

当所述的定时器定时时间到或者计数器的计数满足条件时，发送反馈数据包；其中，所述的反馈数据包用于通知服务器端当前客户端与服务器端的连接状态。

11.一种基于用户数据报协议的数据流发送装置，其特征在于，包括：

数据切分单元，用于将多媒体数据切分为不大于预设值的数据段；

子包获取单元，用于将所述数据段封装在用户数据报协议子包中；

信息发送单元，用于发送携带有所述用户数据报协议子包的用户数据报协议包。

12.根据权利要求11所述的基于用户数据报协议的数据流发送装置，其特征在于，还包括：

排序单元，用于按照时间顺序，对所述用户数据报协议子包进行排序；

子包粘结单元，用于将负载总和不大于546字节的所述时间顺序接近的用户数据报协议子包粘结，并封装在用户数据报协议包。

13.根据权利要求11或12所述的基于用户数据报协议的数据流发送装置，其特征在于，当接收到客户端发送的连接建立请求时，该装置还包括：

判断单元，用于当接收到客户端发送的连接建立请求时，判断是否有空闲传输通道及相关资源为客户端提供服务；

数据获取单元，用于如果有为客户端提供服务的空闲传输通道及相关资源，获取客户端所需的多媒体数据；

所述信息发送单元，还用于如果没有为客户端提供服务的空闲传输通道及相关资源，发送连接已满消息通知客户端。

14.根据权利要求13所述的基于用户数据报协议的数据流发送装置，其特征在于，当服务器端发送一定数量的所述用户数据报协议包之后，还包括：

连接判断单元，用于判断当前客户端与所述服务器端是否连接；

如果当前客户端与所述服务器端是连接的，则继续发送用户数据报协议包；

如果当前客户端与所述服务器端是断开的，则停止发送用户数据报协议包。

15.一种基于用户数据报协议的数据流接收装置，其特征在于，包括：

信息接收单元，用于接收携带有所述用户数据报协议子包的用户数据报协议包；

数据排序单元，用于将所述的用户数据报协议包进行排序。

16.根据权利要求15所述的基于用户数据报协议的数据流接收装置，其特征在于，还包括：

顺序判断单元，用于判断所述的用户数据报协议包的顺序是否连续；

丢包处理单元，用于如果所述的用户数据包协议包的顺序是不连续的，则进行相应的丢包处理。

17.根据权利要求16所述的基于用户数据报协议的数据流接收装置，其特征在于，当所述的用户数据报协议包的顺序不连续时，还包括：

定时器启动单元，用于启动定时器；

信息类型判断单元，用于当定时器定时超时，判断所述丢失的用户数据报协议包是否携带有配置信息；

重传信息发送单元，用于如果所述的丢失的用户数据报协议包携带有配置信息，则发送所述用户数据报协议包重传信息；

同步更新单元，用于如果所述的丢失的用户数据报协议包携带的不是配置信息，则按照当前接收的用户数据报协议包进行同步更新。

18.根据权利要求15至17中任意一项所述的基于用户数据报协议的数据流接收装置，其特征在于，当接收到所述用户数据报协议包后，

反馈数据包发送单元，用于发送反馈数据包；其中，所述反馈数据包用于通知服务器端与客户端保持连接状态。

19.根据权利要求18所述的基于用户数据报协议的数据流接收装置，其特征在于，当客户端与服务器端进行数据交互时，

启动单元，用于启动定时器，或者计数器；

所述反馈数据包发送单元，用于当所述的定时器定时时间到或者计数器的计数满足条件时，发送反馈数据包；其中，所述的反馈数据包用于通知服务器端当前客户端与服务器端的连接状态。

Images