UDP传输文件总结1

这是一个课程作业，用udp协议做一个传输文件的小程序。

 

udp是不面向连接的协议，它在传文件上有它的优点：快，因为不需要握手应答之类的，缺点也很明显：不安全，容易丢包，掉序等。

 

 

我的开发分为三步：

1，实现最简单的报文传输文件功能：用二进制进行传文件，但大小不能超过1K，事实上应该不到1K，具体是多大我不记得了。这主要是由网络层在包达到一定大小时（mtu，好像是1500字节）就会切片，而切片后，会增加传输失败的几率,加之你的包很大，丢了后，即使只丢了一个包，也会导致传输失败。

 

2，对文件进行分片，然后再传输：一般一个片8-16字节传输的比较保险，但是这样其实效率是很低的，因为IP数据包头就至少有20字节。（在千兆局域网的条件下，做了个实验平均10万个包，丢那么几十个，大约万分之几的概率）在32字节以上时，基本上会传输失败。而且如果是传音乐、图片的话还好，我试着传了一个10M的rar，用了5分钟，而且有一些损坏，rar里面的部分文件不能看了。

 

3，具体编程方面有一些难点比如byte[]与String、int等的转换；String的判断相等最好别用==，而是用String.equal(),具体为什么不清楚，可能是String后面都会跟着一个/0。大概流程：用两个线程分别进行收、发操作；收在一个端口上进行监听，有包就收然后写到文件；在传输过程中，要先把文件名、文件大小传过去，注意传输的开始和结束的标志。

 

 

 

下一步把广播功能实现了，至于界面什么的，就不费劲了，没意思。

 

 

 

 

 

 

引用一个网友的评论，感觉说的挺对的

http://bbs.firnow.com/dview37t24917.html   bd74283:

“此问题很有可能是跟你的协议实现有关 

你可以做个简单的实验，同样的发送1500字节的程序，一个在你先ping一下目的地址后运行，一个在命令行里面运行arp   -d后运行，看看结果是不是不一样？？如果是的话，那就是这样的原因：发送1500的数据肯定是分片了，而协议栈里面发送之前如果不知道目的地址的ARP影射，则会发一个arp请求包，在等这个包的应答之前会把需要发送的IP包保存起来，但是只保存一个（注意他只保存一个发送请求），这时如果在arp应答到来之前第二片UDP分片要求发送，这时就会出现第二片IP包覆盖第一片的情况，导致只发出了后面的之带IP的包（令人奇怪的是协议栈确实还会厚颜无耻的返回说发了1500个字节，因为上层协议看不到下层协议），目的方自然不认识该包，因为没有连接能与之匹配。 
以上是我在做TCPIP协议栈的时候测试并且找到的一个问题，应该和你的原因一样的。为了证实你也可以将你发出去的包抓下来看下就清楚了。 

另外，书上推荐的是UDP不要超过500字节，因为如果跨网络的话，他们的MTU是不一样的，比如ethernet到ATM？？？”