如何提高UDP传文件的速度?

做了类似QQ的东西,当然和QQ比差远了.就是向某个人传文件的速度很慢,但传过去的文件是完整的.传的过程中双方有一次确认收到包的握手.还有发送的包如果比较大(几十K,当然不会超过65535 BYTE的)时,丢包很严重,如果包只有几K时情况好的多.但发7M的文件要10分钟还多一点.QQ就快多了.
想问一下各位兄弟有没有什么高见?
实在不行我想用2条线程发,对方用2条收了.

解决方案 »

  1.   

    传送文件的话最好不要用udp协议！还是tcp能好一些！不会丢包！而且也不用考虑你那总确认收包的握手过程
      

  2.   

    把文件数据分成小包，并自己定义收发协议，发送数据时消息中加序号，接收端受到数据包就确认，发送端换存数据，并定时检查过期没有被确认的数据包，并重发。
    也就是说用UDP协议按流的方式发送文件，速度会很快。
      

  3.   

    为什么不考虑用TCP传呢？这样就几乎不用考虑丢包了
      

  4.   

    TCP和UDP传送各有所长,TCP可以不需要后期对数据包进行二次整理,但是得到的是速度上的限制,并且不利于P2P,UDP是正好相反,但是数据包的整理和确认机制却需要有相当的强度.
    个人觉得对于UDP传送可以使用类似于断点续传的机制.在建立握手时,传送文件的大小,同时在接收方创建文件并做出空间分配,同时还可以直接传送一个文件的分块规划,关存于一个信息数组当中.另外再加上一个ID号,比如可以考虑使用GUID,占位长度为16Byte,再加一个顺序号(由顺序号还能确认该数据在文件当中的Position),这样子就当是使用超大文件unsigned __int64,最大值18446744073709551615ULL,也就占8个字节,就算是传文件的起始Position也没有多少耗用.网络环境好一点,包可以稍加大一点可以提高效率.而使用GUID主要是为了方便多点传送,单点传送,就只需要传一个位置即可.但是要记得将未决信息进行存盘,在方便续传.
      

  5.   

    传文件一般要用TCP的吧
    慢的话就多线程啊都已经很成熟的技术了
    再慢就是网络问题了
      

  6.   

    参考开院项目 UDT, SF.NET上有,可靠的UDP传输.. 速度很快,接近QQ...
      

  7.   

    建议那些提意见改用TCP的最好少提这种建议.用UDP自有用UDP的道理,TCP不是什么情形下都可以适用的.建议楼主搜搜以前的贴,讨论UDP文件传输的贴子挺多的.另外可以参考UDT项目.
      

  8.   

    P2P无法用TCP协议。到现在速度问题还没有大的提高(和QQ比),再次麻烦各位出招!!!
      

  9.   

    你可以试试我的一个实现,不过现在是用的tcp,所以没有办法做到nat穿越,我觉得关键还是如何在自己的传输协议上实现传输的完整并且做到和底层网络协议(tcp/udp)无关.http://www.cppblog.com/hdqqq/archive/2006/08/17/11380.html
      

  10.   

    http://blog.csdn.net/pclili/archive/2005/01/14/213631.aspx可以参考.我用UDP实现过.不丢包.
      

  11.   

    看了楼上的各位说的各种意见，都是基于编程的方式来说的。
    其实还可以通过合理利用网络来提高速率，用的好也能提高不少网速。那就是合理设置每次发送的数据大小：假设我们每次send的数据为2K，并且使用TCP方式的话，是没有合理利用网络的。以太网报文最大为1518，减去4个字节的CRC，减去14个字节的帧头，减去20个字节的IP头，减去20个字节的TCP头，每个报文传送的有效数据为1460字节。那么2K（2048字节）就得分为2个报文发出去，第一个报文传1460字节，第二个报文传588字节。可以看见第二个报文只利用了一半的网络。假设我们每次send的数据为2920字节，那么分两次发出去的都是满承载的1518字节的报文，就最大限度的利用了网络带宽。以上说的TCP的情况，最好设为1460的倍数。UDP也是一样的算，这就大家自己去算了。如果有人认为我说的不对请自己在自己电脑上抓包看一下就知道了，毕竟事实胜于雄辩。