CN112511573B - 一种udp数据包的传输控制方法 - Google Patents
一种udp数据包的传输控制方法 Download PDFInfo
- Publication number
- CN112511573B CN112511573B CN202110171203.7A CN202110171203A CN112511573B CN 112511573 B CN112511573 B CN 112511573B CN 202110171203 A CN202110171203 A CN 202110171203A CN 112511573 B CN112511573 B CN 112511573B
- Authority
- CN
- China
- Prior art keywords
- packet
- link
- data packet
- buffer area
- lost
- 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.)
- Active
Links
Images
Classifications
-
- 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
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- 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/14—Session management
- H04L67/141—Setup of application sessions
-
- 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/14—Session management
- H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
-
- 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/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
Abstract
本发明公开了一种UDP数据包的传输控制方法,所述UDP数据包的头部包括RCMP协议头,所述方法包括:基于所述RCMP协议头建立UDP链接并维护UDP链接;发送和接收数据;结束UDP链接。本发明根据实际的应用需求在UDP数据包中增加协议头,逻辑简单,实用性强,能够较好的满足音视频业务实时性的要求。
Description
技术领域
本发明涉及通信技术领域,更具体的,涉及一种UDP数据包的传输控制方法。
背景技术
音视频业务的特点是实时、一对一或者一对多、音视频需要同步等一些列的工作,在云会议产品中,使用RTCP协议会引入很多繁琐的逻辑和不可控制性,因此通常直接使用TCP协议来保证RTP数据的完整性,但是TCP协议太过于复杂,在网络差的情况下,因为实行的是退让原则,所以会大量降低带宽的使用率,不符合云会议实时性的要求。
发明内容
为了解决上述至少一个技术问题,本发明提出了一种UDP数据包的传输控制方法,所述UDP数据包的头部包括RCMP协议头,所述方法包括:
基于所述RCMP协议头建立UDP链接并维护UDP链接;
发送和接收数据;
结束UDP链接;
其中,所述RCMP协议头包括以下字段:
lost字段,表示丢包数;heart字段,为心跳包标志位;fin字段,为链接终止标志位;sync字段,为链接建立标志位;syncACK字段,为链接建立响应标志位;seq字段表示包序号;lostSEQ 字段表示丢失数据包的起始序号;timestamp字段表示包发送的时间;ID字段表示链接的唯一识别标志。
进一步地,所述lost字段与lostSEQ字段配合,lost字段非0时,表示包序号lostSEQ到lostSEQ + (lost-1)之间的包丢失;lostSEQ字段 表示丢失数据包的起始序号,当lost字段非0时该序号才有效。
进一步地,所述基于所述RCMP协议头建立UDP链接包括:
客户端向服务器发送链接建立数据包,该链接建立数据包的sync字段为1;
服务器收到链接建立数据包,若同意建立链接,则向客户端发送响应数据包,该响应数据包的syncACK字段为1;否则向客户端发送拒绝数据包,该拒绝数据包的fin字段为1;
客户端接收到响应数据包,链接建立成功。
进一步地,若链接建立数据包、响应数据包或拒绝数据包丢失,则客户端每隔固定的时间重复发送链接建立数据包,直到接收到响应数据包或拒绝数据包。
进一步地,所述基于所述RCMP协议头维护UDP链接包括:
UDP链接建立成功后,服务器和客户端若预设时间t1内未发出数据包,则向对端发送心跳包;
服务器和客户端每隔预设时间t1检查本地记录的链接接收活动时间与当前时间的差是否大于预设时间t2,若是,则删除本地链接的唯一识别标志;
其中,所述链接接收活动时间为最后一次接收到数据包或心跳包的时间。
进一步地,所述发送和接收数据包括:
发送端分别初始化发送缓冲区、发送缓冲区头指针、发送缓冲区尾指针;
发送当前数据包,并将当前数据包缓存至发送缓冲区头指针指向的位置,然后计算新的发送缓冲区头指针指向位置,若新的发送缓冲区头指针指向位置不为空,则将当前数据包缓存到新的发送缓冲区头指针指向的位置;
若新的发送缓冲区头指针和发送缓冲区尾指针相等,则计算新的发送缓冲区尾指针。
进一步地,所述发送和接收数据还包括:
接收端初始化接收缓冲区、接收缓冲区头指针、接收缓冲区尾指针;
接收到数据包后,首先判断接收缓冲区头指针是否等于接收缓冲区尾指针;
如果接收缓冲区头指针等于接收缓冲区尾指针,则接收缓冲区为空,未发生过丢包,将数据包传送给上层模块;
若接收缓冲区头指针小于接收缓冲区尾指针,则计算当前丢包数并计算接收到的数据包相对接收缓冲区头指针指向的数据包的序号偏移量;
根据偏移量值和丢包数执行不同的数据包接收操作。
进一步地,所述发送和接收数据还包括:
客户端收到lost字段不为0的请求补包的数据包,则根据lost字段记录的丢包数和lostSEQ字段给出的丢失数据包的起始序号,得到需要重新发送的包序号,若需要重新发送的包序号在接收缓冲区中则重新发送。
进一步地,所述结束UDP链接包括:
当客户端或服务器需要断开UDP链接时,向对端发送链接终止标志位为1的数据包,然后删除本地记录的链接的唯一识别标志ID值;
当客户端或服务器接收到链接终止标志位为1的数据包,则删除本地记录的链接的唯一识别标志ID值。
本发明公开的一种UDP数据包的传输控制方法,通过增加新的RCMP协议头来实现链接的建立、维护和结束以及数据的收发,逻辑简单,实用性强,能够较好的满足在线会议等音视频业务实时性的要求。
附图说明
图1示出了根据本发明实施例的UDP数据包的传输控制方法中UDP链接建立流程图;
图2示出了根据本发明实施例的UDP数据包的传输控制方法UDP链接维护流程图;
图3示出了根据本发明实施例的UDP数据包的传输控制方法发送数据流程图;
图4示出了根据本发明实施例的UDP数据包的传输控制方法接收缓冲区内容示意图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是,在不冲突的情况下,本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是,本发明还可以采用其他不同于在此描述的其他方式来实施,因此,本发明的保护范围并不受下面公开的具体实施例的限制。
名词解释:
UDP:用户数据报传输协议(User Datagram Protocol)。
RCMP:本发明所提出的基于UDP的RTP控制消息协议(RTP Control MessageProtocol)。
RTP:实时传输协议(Real-time Transport Protocol),RFC3550
RTCP:实时传输控制协议(Real-time Transport Control Protocol),RFC3550
根据本发明的一个实施例,提供了一种UDP数据包的传输控制方法,所述UDP数据包的头部包括RCMP协议头,所述方法包括:
基于所述RCMP协议头建立UDP链接并维护UDP链接;
发送和接收数据;
结束UDP链接;
其中,所述RCMP协议头包括以下字段:
lost字段,表示丢包数;heart字段,为心跳包标志位;fin字段,为链接终止标志位;sync字段,为链接建立标志位;syncACK字段,为链接建立响应标志位;seq字段表示包序号;lostSEQ 字段表示丢失数据包的起始序号;timestamp字段表示包发送的时间;ID字段表示链接的唯一识别标志。
进一步地,所述lost字段与lostSEQ字段配合,lost字段非0时,表示包序号lostSEQ到lostSEQ + (lost-1)之间的包丢失;lostSEQ字段 表示丢失数据包的起始序号,当lost字段非0时该序号才有效。
在该实施例中,在UDP数据报的头部增加基于本发明提出的RCMP协议的头部,称为RCMP协议头(RCMP_HEAD), 依靠RCMP_HEAD中携带的信息实现UDP可靠连接和数据传输的可靠性。基于RCMP建立的链接为双向链接,无论发起方是谁,只要连接建立成功,双方可以互发数据。
具体地,所述RCMP协议头包括以下字段:
a)lost字段,表示丢包数,字段长度为12比特,所述lost字段与lostSEQ字段配合,lost非0时,表示包序号lostSEQ到lostSEQ + (lost-1)之间的包丢失,lost包不占用包序号;
b)heart字段,表示心跳包标志位,字段长度为1比特,1表示该包为心跳包,心跳包不占用包序号;
c)fin字段,表示链接终止标志位,字段长度为1比特,当终止链接时,发送一个该标志被置1的数据包,链接就会被立即终止,不考虑该数据包是否丢失;
d)sync字段,表示链接建立标位,字段长度为1比特,当建立链接时,第一个包该字段必须设置为1,然后等待对端应答,收到应答后,链接建立成功,否则重复发送,直到链接成功或者放弃;
e)syncACK字段,表示链接建立响应数据包,字段长度为1比特,当收到链接建立请求包sync后,服务器向客户端发送响应包syncACK;
f)seq字段,表示包序号,字段长度为16比特,同一方向上的不同数据包都有一个包序号,包序号根据数据包实际的顺序而递增,初始值为1,当达到65535后自动翻转为0继续递增;包序号的作用是用来标记包的顺序,接收端可以根据收到的包序号判断收到的数据包是否完整,顺序是否正确,有丢包的情况下可以向发送方请求丢失的序号的包。心跳包不占用包序号。lost数据包不占用包序号。
g)lostSEQ字段, 表示丢失数据包的起始序号,字段长度为16比特,当lost字段非0时该序号才有效;例如,发送端收到lost=3,lostSEQ=223的数据包,表示包序号为223、224、225这3个序号代表的数据包丢失了,发送端需要重新发送。
h) timestamp字段,表示包发送的时间,字段长度为32比特,该时间定义为程序启动时到目前的毫秒数,数值达到最大值0xFFFFFFFF后自动翻转;
i) ID字段,表示链接的唯一识别标志,字段长度为32比特。
需要说明的是,在本发明中一条UDP链接需要一个唯一的识别标志ID,ID字段可以有很多种生成方式,只要保证整个系统中唯一即可。例如在线会议系统中可以通过会前系统分配的用户id作为用户到服务器的UDP链接的唯一识别标志。
进一步地,如图1所示,所述基于所述RCMP协议头建立UDP链接包括:
客户端向服务器发送链接建立数据包,该链接建立数据包的sync字段为1;
服务器收到链接建立数据包,若同意建立链接,则向客户端发送响应数据包,该响应数据包的syncACK字段为1;否则向客户端发送拒绝数据包,该拒绝数据包的fin字段为1;
客户端接收到响应数据包,链接建立成功;收到拒绝数据包,链接建立失败。
本方案中,若链接建立数据包丢失、响应数据包或拒绝数据包丢失,则客户端每隔固定的时间重复发送链接建立数据包,直到收到服务器发送的响应数据包或拒绝数据包。
本方案所述的UDP链接由一方发起,另一方响应,2次握手完成,简化了类似TCP链接建立那样复杂的3次握手机制。在一个成功建立链接的实施例中,链接发起方为客户端,被链接方为服务器,UDP链接建立流程如下:
客户端向服务器发送链接建立数据包Psync,Psync定义如下:
Pa={lost=0, heart=0, fin=0, sync=1, syncACK=0, seq=1, lostSEQ=0,timestamp=599812350, ID=1234}。
服务器收到Psync数据包,同意建立链接且本地没有ID=1234的UDP链接则保存该链接的唯一识别标志,有则不用保存,然后向客户端发送响应数据包Pack,定义如下:
Pack={lost=0, heart=0, fin=0, sync=0, syncACK=1, seq=1, lostSEQ=0,timestamp=599812610, ID=1234}。
进一步地,所述基于所述RCMP协议头维护UDP链接包括:
UDP链接建立成功后,服务器和客户端若预设时间t1内未发出数据包,则向对端发送心跳包;
服务器和客户端每隔预设时间t1检查本地记录的链接接收活动时间与当前时间的差是否大于预设时间t2,若是,则删除本地链接的唯一识别标志;
其中,所述链接接收活动时间为最后一次接收到数据包或心跳包的时间。
具体地,UDP链接建立成功后,服务器和客户端分别维护一个定时器,定时器时长为预设值t1,每隔预设的时间t1秒对链接接收活动时间进行检查,客户端和服务器收到数据包后需要更新本地链接接收活动时间为当前时间,定时器会每隔预设时间t1秒检查当前时间,若当前时间超过t2秒没有被更新则认为链接失效,删除本地链接的唯一识别标志;
客户端和服务器定时器还负责维护链接的有效性,当检测到链接在预设时间t1秒内没有数据发出时,自动向服务器发送一个心跳包。
如图2所示,在一个具体的实施例中,UDP链接建立成功后,服务器和客户端分别维护一个定时器,定时器时长为预设值2秒,每隔预设的时间2秒对链接接收活动时间进行检查,客户端和服务器收到数据包后需要更新本地链接接收活动时间为当前时间,定时器会每隔预设时间2秒检查当前时间,若当前时间超过6秒没有被更新则认为链接失效,删除本地链接的唯一识别标志;
客户端和服务器定时器还负责维护链接的有效性,当检测到链接在预设时间2秒内没有数据发出时,自动向服务器发送一个心跳包。这样就能保证对端的链接状态为有效状态。所以客户端和服务器每发出去一个数据包都会更新本地链接发送活动时间。
心跳包不占用包序号,例如心跳包Pheart={lost=0, heart=1, fin=0, sync=0,syncACK =0, seq=0, lostSEQ=0, timestamp=1599813610, ID =1234}。
进一步地,所述发送和接收数据包括:
发送端分别初始化发送缓冲区、发送缓冲区头指针、发送缓冲区尾指针;
发送当前数据包,并将当前数据包缓存至发送缓冲区头指针指向的位置,然后计算新的发送缓冲区头指针指向位置,若新的发送缓冲区头指针指向位置不为空,则将当前数据包缓存到新的发送缓冲区头指针指向的位置;
若新的发送缓冲区头指针和发送缓冲区尾指针相等,则计算新的发送缓冲区尾指针。
如图3所示,发送端包括有一个发送缓冲区和发送缓冲区头指针和发送缓冲区尾指针,缓冲区的大小由业务类型决定,例如音频包可以设置成4个长度。
假设发送缓冲区sendbuff由一个数组实现,数组大小为4,发送缓冲区头指针sendhead,发送缓冲区尾指针sendend,其定义如下:
void *sendbuff[4];
int sendhead, sendend;
初始化时sendbuff={0, 0,0,0},sendhead=0,sendend=0;
发送数据时首先发送当前数据,然后将该数据缓存到sendhead指向的位置sendbuff[sendhead],然后根据sendhead=(sendheand+1)%4,计算出新的sendhead,如果新的sendhead指向的位置不等于null,则删除原来的数据,再将当前发送的数据缓存到sendhead执行的位置;
调整完sendhead之后,如果sendhead和sendend相等,继续按照sendend=(sendend+1)%4的规则计算新的sendend值。
进一步地,所述发送和接收数据还包括:
接收端初始化接收缓冲区、接收缓冲区头指针、接收缓冲区尾指针;
接收到数据包后,首先判断接收缓冲区头指针是否等于接收缓冲区尾指针;
如果接收缓冲区头指针等于接收缓冲区尾指针,则接收缓冲区为空,未发生过丢包,将数据包传送给上层模块;
若接收缓冲区头指针小于接收缓冲区尾指针,则计算当前丢包数并计算接收到的数据包相对接收缓冲区头指针指向的数据包的序号偏移量;
根据偏移量值和丢包数执行不同的数据包接收操作。
在一个具体的实施例中,接收端包括有:一个接收缓冲区和接收缓冲区头指针和接收缓冲区尾指针,接收缓冲区必须大于发送缓冲区,例如音频包发送缓冲区是4,则接收缓冲区可以设置为6。
设缓冲区receivebuff由一个数组实现,数组大小为6,接收缓冲区头指针receivehead,接收缓冲区尾指针receiveend,其定义如下:
void *receivebuff[6];
int receivehead, receiveend;
初始化receivebuff ={0, 0,0,0,0,0}, receivehead =0, receiveend =0;
接收到数据包pkt后,首先判断receivehead是否等于receiveend,如果相等,说明缓冲区为空,未发生过丢包,直接将数据包上抛给上层模块,流程结束。
如果receivehead不等于receiveend,则计算当前丢包数lost_count,公式如下:
如果receivehead小于receiveend,则lost_count=(receivehead+6)-receiveend;
否则lost_count=receivehead-receiveend;
计算数据包pkt相对receivebuff[receivehead]指向的数据包的序号偏移量receive_diff,计算方法如下:receive_diff=pkt.seq-receivebuff[receivehead]; 根据偏移量和丢包数执行不同的数据包接收操作具体如下:
若receive_diff 等于0,则说明与receivebuff[receivehead]包重复,直接丢弃该包,流程结束;
若 receive_diff<-lost_count,则说明是历史包,直接丢弃该包,流程结束;
若 -lost_count=<receive_diff<0,则说明是丢失的数据包的补报到了,计算该包位置index,公式如下:
index=receivehead-lost_count;
如果index小于0,则调整index=index+6;
计算出index后,查看receivebuff[index]是否为0,为0则直接将数据包pkt存入此位置,否则就是重复包,直接丢弃该包,流程结束;
历史包到来后,如果不是重复包,则需要触接收发缓冲区重新调整逻辑,方法是从receiveend开始检测其位置上对应的数据包是否为0,不为0,说明补包成功,上抛数据包给第三方模块,然后调整receiveend=(receiveend+1)%6,直到遇到为0的位置,停止调整,流程结束。
若 6>receive_diff>0,则说明有新的数据包到来,计算出其位置并缓存下来,只有新包到来时才会触发丢包检测,进而发送丢包请求给发送端。
首先计算新数据包的位置new_head=(receivehead+ receive_diff)%6,计算出新包位置后,如果new_head已经和receiveend有交叉则必须将receiveend到new_head的数据包全部抛给上层,并清空这部分接收缓冲区。
最后发送丢包请求,变量receiveend到receiveheand之间的接收缓冲区空间,将所有缺失的数据包都向客户端发送丢包请求,流程结束。例如接收缓冲区内容如图4所示,则需要发送2个丢包请求Plost1,Plost2,内容如下:
Plost1={lost=1, heart=0, fin=0, sync=0, syncACK=0, seq=0, lostSEQ=331, timestamp=1596513610, ID =1234}
Plost2={lost=2, heart=0, fin=0, sync=0, syncACK=0, seq=0, lostSEQ=333, timestamp=1596213610, ID =1234}
若 receive_diff>=6,说明数据包序号跳跃太大,超出了接收缓冲区,则按照收包顺序将接收缓冲区中的数据包和收到的数据包传给上层模块处理,并初始化缓冲区,流程结束。
进一步地,所述发送和接收数据还包括:
客户端收到lost不为0的请求补包的数据包,则根据lost字段记录的丢包数和lostSEQ字段给出的丢失数据包的起始序号,得到需要重新发送的包序号,若需要重新发送的包序号在接收缓冲区中则重新发送。
在一个具体的实施例中,例如发包缓冲区中的数据包为[113,114,115,116],收到补包请求包内容如下
plost={lost=4,heart=0,fin=0,sync=0,syncACK=0,seq=0, lostSEQ=112,timestamp=1596513610,ID =1234}
则客户端解析到服务器为收到的包序号是112,113,114,115,因为112已经不再发送缓冲区了,所以客户端只会重发113,114,115,重发时任何参数都不改变,直接按照包的原始顺序分别发送这些数据包。
进一步地,所述结束UDP链接包括:
当客户端或服务器需要断开UDP链接时,向对端发送链接终止标志位为1的数据包,然后删除本地记录的链接的唯一识别标志ID值;
当客户端或服务器接收到链接终止标志位为1的数据包,则删除本地记录的链接的唯一识别标志ID值。
在一个具体的实施例中,结束链接数据包为:
Pfin={lost=0, heart=0, fin=1, sync=0, syncACK=0, seq=3, lostSEQ=0,timestamp=1599513610, ID =1234}。
链接建立成功后,双方收到数据后,首先校验链接的唯一识别标志ID,识别链接,只有链接识别成功后才处理该数据,否则直接丢弃。
在本申请所提供的几个实施例中,应该理解到,所揭露的设备和方法,可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,如:多个单元或组件可以结合,或可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:移动存储设备、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以所述权利要求的保护范围为准。
Claims (3)
1.一种UDP数据包的传输控制方法,其特征在于,所述UDP数据包的头部包括基于UDP的RTP控制消息协议RCMP协议头,所述方法包括:
基于所述RCMP协议头建立UDP链接并维护UDP链接;
发送和接收数据;
结束UDP链接;
其中,所述RCMP协议头包括以下字段:
lost字段表示丢包数;heart字段,为心跳包标志位;fin字段,为链接终止标志位;sync字段,为链接建立标志位;syncACK字段,为链接建立响应标志位;seq字段,表示包序号;lostSEQ 字段,表示丢失数据包的起始序号;timestamp字段,表示包发送的时间;ID字段表示链接的唯一识别标志;
所述lost字段与lostSEQ字段配合,lost字段非0时,表示包序号lostSEQ到lostSEQ +(lost-1)之间的包丢失;lostSEQ 字段表示丢失数据包的起始序号,当lost字段非0时该序号才有效;
所述基于所述RCMP协议头建立UDP链接包括:
客户端向服务器发送链接建立数据包,该链接建立数据包的sync字段为1;
服务器收到链接建立数据包,若同意建立链接,则向客户端发送响应数据包,该响应数据包的syncACK字段为1;否则向客户端发送拒绝数据包,该拒绝数据包的fin字段为1;
客户端接收到响应数据包,链接建立成功;
若链接建立数据包、响应数据包或拒绝数据包丢失,则客户端每隔固定的时间重复发送链接建立数据包,直到接收到响应数据包或拒绝数据包;
所述基于所述RCMP协议头维护UDP链接包括:
UDP链接建立成功后,服务器和客户端若预设时间t1内未发出数据包,则向对端发送心跳包;
服务器和客户端每隔预设时间t1检查本地记录的链接接收活动时间与当前时间的差是否大于预设时间t2,若是,则删除本地链接的唯一识别标志;
其中,所述链接接收活动时间为最后一次接收到数据包或心跳包的时间;
所述发送和接收数据包括:
发送端分别初始化发送缓冲区、发送缓冲区头指针、发送缓冲区尾指针;
发送当前数据包,并将当前数据包缓存至发送缓冲区头指针指向的位置,然后计算新的发送缓冲区头指针指向位置,若新的发送缓冲区头指针指向位置不为空,则将当前数据包缓存到新的发送缓冲区头指针指向的位置;
若新的发送缓冲区头指针和发送缓冲区尾指针相等,则计算新的发送缓冲区尾指针;
所述发送和接收数据还包括:
接收端初始化接收缓冲区、接收缓冲区头指针、接收缓冲区尾指针;
接收到数据包后,首先判断接收缓冲区头指针是否等于接收缓冲区尾指针;
如果接收缓冲区头指针等于接收缓冲区尾指针,则接收缓冲区为空,未发生过丢包,将数据包传送给上层模块;
若接收缓冲区头指针小于接收缓冲区尾指针,则计算当前丢包数并计算接收到的数据包相对接收缓冲区头指针指向的数据包的序号偏移量;
根据偏移量值和丢包数执行不同的数据包接收操作。
2.根据权利要求1所述的方法,其特征在于,所述发送和接收数据还包括:
客户端收到lost字段不为0的请求补包的数据包,则根据lost字段记录的丢包数和lostSEQ字段给出的丢失数据包的起始序号,得到需要重新发送的包序号,若需要重新发送的包序号在接收缓冲区中则重新发送。
3.根据权利要求1所述的方法,其特征在于,所述结束UDP链接包括:
当客户端或服务器需要断开UDP链接时,向对端发送链接终止标志位为1的数据包,然后删除本地记录的链接的唯一识别标志ID值;
当客户端或服务器接收到链接终止标志位为1的数据包,则删除本地记录的链接的唯一识别标志ID值。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110171203.7A CN112511573B (zh) | 2021-02-08 | 2021-02-08 | 一种udp数据包的传输控制方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110171203.7A CN112511573B (zh) | 2021-02-08 | 2021-02-08 | 一种udp数据包的传输控制方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112511573A CN112511573A (zh) | 2021-03-16 |
CN112511573B true CN112511573B (zh) | 2021-05-11 |
Family
ID=74953044
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110171203.7A Active CN112511573B (zh) | 2021-02-08 | 2021-02-08 | 一种udp数据包的传输控制方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112511573B (zh) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1783877A (zh) * | 2004-11-30 | 2006-06-07 | Ut斯达康通讯有限公司 | 实时通讯数据流穿越网络地址转换设备和防火墙的方法 |
CN101394363A (zh) * | 2008-11-10 | 2009-03-25 | 北京佳讯飞鸿电气股份有限公司 | 一种rtcp通信的实现方法 |
CN102353844A (zh) * | 2011-06-24 | 2012-02-15 | 华南理工大学 | 带对称导线自补偿的双路电导率检测监控装置及方法 |
CN102566515A (zh) * | 2010-12-09 | 2012-07-11 | 沈阳高精数控技术有限公司 | 一种用于总线式数控系统的数据互操作方法 |
CN102629927A (zh) * | 2012-04-09 | 2012-08-08 | 华为技术有限公司 | Rtp媒体数据的接收、发送方法及设备、处理系统 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4655006B2 (ja) * | 2006-08-23 | 2011-03-23 | 日本電気株式会社 | Ipストリーム送受信システム、ipストリーム受信装置及びそれらに用いる受信処理タイミング同期化方法 |
US8306063B2 (en) * | 2006-08-29 | 2012-11-06 | EXFO Services Assurance, Inc. | Real-time transport protocol stream detection system and method |
CN101170487B (zh) * | 2006-10-25 | 2010-05-12 | 华为技术有限公司 | 数据流复用中的压缩方法和压缩系统以及压缩设备 |
CN101145968B (zh) * | 2007-08-02 | 2011-01-05 | 中兴通讯股份有限公司 | 网管系统和传输设备间数据发送及接收方法 |
-
2021
- 2021-02-08 CN CN202110171203.7A patent/CN112511573B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1783877A (zh) * | 2004-11-30 | 2006-06-07 | Ut斯达康通讯有限公司 | 实时通讯数据流穿越网络地址转换设备和防火墙的方法 |
CN101394363A (zh) * | 2008-11-10 | 2009-03-25 | 北京佳讯飞鸿电气股份有限公司 | 一种rtcp通信的实现方法 |
CN102566515A (zh) * | 2010-12-09 | 2012-07-11 | 沈阳高精数控技术有限公司 | 一种用于总线式数控系统的数据互操作方法 |
CN102353844A (zh) * | 2011-06-24 | 2012-02-15 | 华南理工大学 | 带对称导线自补偿的双路电导率检测监控装置及方法 |
CN102629927A (zh) * | 2012-04-09 | 2012-08-08 | 华为技术有限公司 | Rtp媒体数据的接收、发送方法及设备、处理系统 |
Also Published As
Publication number | Publication date |
---|---|
CN112511573A (zh) | 2021-03-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7310694B2 (en) | Reducing information reception delays | |
CN103841002B (zh) | 语音传输方法、终端、语音服务器及语音传输系统 | |
US6310892B1 (en) | Reliable connectionless network protocol | |
EP1206062A2 (en) | Data communication system, data communication method, and recording medium with data communication program recorded thereon | |
CN106210924B (zh) | 视频网络传输控制方法和系统 | |
CN112436994B (zh) | 一种数据传输方法及电子设备 | |
US20020095511A1 (en) | Optimized performance for transaction-oriented communications using stream-based network protocols | |
WO1998023067A1 (en) | System and method for dynamically reconfigurable packet transmission | |
EP1397899A1 (en) | Real-time packetization and retransmission in streaming applications | |
US20060271680A1 (en) | Method For Transmitting Window Probe Packets | |
CN112436924B (zh) | 一种数据传输方法及电子设备 | |
EP1806870B1 (en) | Method for providing data and data transmission system | |
CN112995182B (zh) | 媒体流传输方法、装置、设备及介质 | |
CN112769526B (zh) | 数据包重传方法、系统和存储介质 | |
CN108234087A (zh) | 数据传输方法及发送端 | |
CN115002023B (zh) | 一种链路聚合方法、链路聚合装置、电子设备及存储介质 | |
EP1395000B1 (en) | A method of transmitting data streams dependent on the monitored state of the client application buffer | |
US8943362B2 (en) | Control and monitoring for fast millimeter-wave link using out-of-band wireless channel | |
KR100240645B1 (ko) | 멀티캐스트 통신의 패킷 오류 제어기 및 이를 이용한패킷 오류제어 방법 | |
US7330432B1 (en) | Method and apparatus for optimizing channel bandwidth utilization by simultaneous reliable transmission of sets of multiple data transfer units (DTUs) | |
CN112511573B (zh) | 一种udp数据包的传输控制方法 | |
CN116032998A (zh) | 数据传输方法、装置、计算机可读存储介质及电子设备 | |
JP2003125020A (ja) | 情報配信システム及び情報配信方法 | |
JP2004187099A (ja) | 通信制御方法、通信システム及び通信装置 | |
CN112468513A (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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |