(进个人看看，不然没法儿结贴呀)求一个用udp传输大文件的思路！顺带问下udp打洞是什么概念？
前段时间写了个远程控制的小程序，这个程序里包含了3个连接：
首先是udp，用来让控制端发送消息到被控制端(被控制端相当于Server）
其次是两个TCP，用来 收发、处理 截屏图片和鼠键输入事件

udp为先导--被控制端一经运行就会打开一个udp端口等待客户端发命令过来，致使控制端可方便与服务器端建立和断开联系

有6个命令
2个是建立和断开控制端与被控制端的TCP连接
2个是启动和停止服务器端发送图片的线程
2个是启动和停止服务器端接收并处理鼠键事件的线程

发送“连接”命令后，控制端与被控制端会通过udp端口建立起两个TCP连接
这socket连接是放在被控制端主程序内的（建立socket连接的时候，服务器会打开一个ServerSocket接收客户端）
被控制端的另外两个线程，则是借助这两个socket连接构造自身

发送“断开连接”命令后，前述的两个socket连接会断开掉，控制端与被控制端的2个TCP连接断开

发送“截屏”命令后，被控制端就会启动发送图片的线程，不断地向控制端发送截屏图片
同时控制端弹出一个窗口来用于接收被控制端发过来的截图

发送“停止截屏”，服务器端发送截屏图片的线程停止，客户端接收截屏图片的子窗体也关闭

还有就是“协助”和“停止协助”的命令，就是在客户端接收截屏的窗体上加入一个鼠标和键盘事件的监听，
将事件化为对象用对象流发送出去，在被控制端起一个线程用于接收这些事件对象并进行相应的处理！


程序的功能和基本结构描述完毕，当然还有未能描述清楚的地方！
接下来附上这个项目的地址，有兴趣的可以自己去下载来看看
http://download.csdn.net/source/2934701


现在说下我的问题，我发送截图是用的TCP协议！！
我每秒截图20帧，大小为1440*768
每张图片大概200kB左右
局域网测试稍微有点延迟，但能用！
但是我用这个和我一个在广东的同学做测试，则根本都连不上(我在湖南长沙)
他给我的建议是：
①命令改用TCP可靠连接发送
②截图这种极耗费网络资源的用UDP连接发送(增强实时性减小延迟必须的！)
后来我仔细想了想，确实是这样的！
我们学校用的是网通2m的网络
理想状况才能发2mB
而如果按我那个思路的话
200kB*20 == 4MB
这网络确实是背不起！
好了，如果要把这个项目投诸于实用
看来改成用TCP连接发送命令 和 UDP连接发送截图是必须的了

现在才到了我的问题！
如何用UDP这种不可靠的连接发送大文件？我试了一下
UDP每个包才能发送64kb大小的数据
没仔细看还以为有那么点意思了
仔细看才发现是小写的b
也就是8kB！！
这也忒小了吧？！

这么一来的话？我一张截图再怎么缩小大小和进行压缩
也不能压成8kB呀！
那就是说必须发送成多个DatagramPacket咯
这样一来，UDP又是不可靠的发送，丢了一个包的话
一张图片就变的缺胳膊少腿儿了
甚至图片接收过来什么都显示不出来
而且刚刚有考虑到一个问题
就是后面的图片也许发的比前面的快，反而先显示了出来！
问题真是太多了！
希望有人能给出一个思路解决这个问题！也就是关于设计UDP协议使能快速稳定传输的思路
或者是用TCP连接高效发送图片的思路，也成！
关于UDP这条路线，我还是不怎么看好，其中多了很多自己动手的成分，不是一件简单的事情！
望对此有兴趣的同志，高手、大侠们能给予长期的关注！这个我准备做成一个web版的视频语音服务
嫌分给的太少的，如果能协助我解决这个问题，追加100分，绝不食言！
感谢各位的支持！！

------解决方案--------------------
网络传输文件，大小是关键，对于文本文件，可采用zip等方法压缩；图片也最好经过压缩处理，关于压缩可以参考下我的几篇博文，希望能有点帮助；至于udp打洞，这个就不太了解了。
------解决方案--------------------

 你们都有公网IP地址吗？ 否则你们只要有一方在路由器/防火墙/NAT之后的话，肯定是连接不上的。在这种情况下，必须用UDP打洞。原理和技术上面的文章都有了。

至于UDP发送文件，显然是可以的。但是需要自己手工处理丢包重传，倒包修正等等问题。 因为UDP本来就是不可靠的。

另外，网络包(不管是TCP还是UDP)都不会长的，你看到8Kb这是应用层，真正发送的时候，还要拆成MTU，Internet上的话，每个数据包大概在1Kb 多一点。