关于UDP丢包的检测

[SaitoFun]

背景描述 :
下载一个文件, 用TCP请求数据, 用UDP接收数据.
数据的请求和接收分别在两个线程里. 每次TCP请求16K数据, UDP每次回复1K数据.
整个16K下载完毕, 将16K数据一次性写入文件.
有这么几个任务集 :
1. 正在下载的任务集A
2. 已经下载完成的任务集B
3. 空闲待用的任务集C
有这么几个线程 :
1. 写文件线程
2. 超时检测线程
3. 数据接收线程
4. 数据请求的发起线程
各个线程的工作描述 :
1. 数据请求发起线程, 从任务集C中获取空闲任务发起数据请求, 并将对应任务添加到任务集A中;
2. 写文件线程将获取任务集B中的任务, 将数据写入文件后, 释放对应任务到任务集C中;
3. 数据接收线程将数据写入到任务集A中的对应任务中, 整个任务写完之后将任务添加到任务集B中;
4. 超时检测线程定期检测任务集A中的任务超时情况, 如果发现任务超时则认定为丢包了, 会请求重传;

问题描述 :
1. UDP肯定是避免不了丢包的, 所以肯定也需要一个超吃重传的检测机制
2. 目前的处理办法是起一个线程的去检测丢包的情况, 丢包了则重传, 但问题是CPU占用太严重了

已经做过的尝试 :
1. 控制超时的时间, 我测试过了我的程序, 重复接收的数据微乎其微, 大概500MB的文件重复接收了也就那么十几KB. 说明超时时间的控制, 基本上算是合格了.
2. 在超时检测线程中增加超时检测间隔的时间, 但是CPU的占用还是超出了预期.

有没有什么更好的机制去解决UDP丢包检测这样的问题. 各位大虾们看看小弟的问题, 给个方法解决解决.

[zhanshen2891]

你把文件拆成有序的数据包，接收端先弄出一个相应大小的空文件，然后把收到的数据包按照序号写进去，等接收完毕的时候检查哪些序号的包丢失了，请求重传这些丢失的包。传完之后再检查，如此循环。

其实传文件最好还是用TCP，它的流式协议正好适合做这个。

[SaitoFun]

[Quote=引用 1 楼 zhanshen2891 的回复:]

你把文件拆成有序的数据包，接收端先弄出一个相应大小的空文件，然后把收到的数据包按照序号写进去，等接收完毕的时候检查哪些序号的包丢失了，请求重传这些丢失的包。传完之后再检查，如此循环。

其实传文件最好还是用TCP，它的流式协议正好适合做这个。
[/Quote]

楼上说的这种情况在我这里不使用, 首先我现在使用的协议是我们公司自己定的协议, 规定就是TCP请求, UDP接收, 而且这个文件最终会用于播放, 所以, 必须按照一定的规律去下载, 不能说整个文件下完成了再去看丢包的情况. 这样和当前的需求不符合. 如果发生丢包, 需要尽快的检测出来, 并且重新请求.

[鼠]

有个东西叫做滑动窗口。

[SaitoFun]

[Quote=引用 3 楼 hpsmouse 的回复:]

有个东西叫做滑动窗口。
[/Quote]
能具体说说吗? 或者给些资料什么的, 不胜感谢

[鼠]

http://blog.csdn.net/yujun00/article/details/636495

http://en.wikipedia.org/wiki/Sliding_Window_Protocol

自己用 UDP 把 TCP 的东西这么重做一遍有意思么……

[SaitoFun]

[Quote=引用 5 楼 hpsmouse 的回复:]

http://blog.csdn.net/yujun00/article/details/636495

http://en.wikipedia.org/wiki/Sliding_Window_Protocol

自己用 UDP 把 TCP 的东西这么重做一遍有意思么……
[/Quote]
还是有区别的, 具体情况具体分析嘛

[赵4老师]

CPU负荷过大的真相往往是某个循环中既没有调用Sleep也没有调用阻塞函数！

[l_ocean]

楼上说得有理，就这几个线程，如果不干些大事，一般的cpu还是能受得了的。估计是没sleep。

至于丢包检测，可以在包头加个序号，当传完时向发送端发个已收到的包号。　也可以定时向发送端发个已收到的包号。　　发送端再计算下，讲丢包再发一次。

[奔跑吧猴哥]

老生常谈了。
发送序号
接收序号
K
W
.....