关于UDP丢包的检测,该怎么处理

关于UDP丢包的检测
背景描述 : 
    下载一个文件, 用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丢包检测这样的问题. 各位大虾们看看小弟的问题, 给个方法解决解决.

------解决方案--------------------
http://blog.csdn.net/yujun00/article/details/636495

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

自己用 UDP 把 TCP 的东西这么重做一遍有意思么……
------解决方案--------------------
楼上说得有理，就这几个线程，如果不干些大事，一般的cpu还是能受得了的。估计是没sleep。

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