作者：咖啡色的午后_905 | 来源：互联网 | 2023-07-17 17:03
做了类似QQ的东西,当然和QQ比差远了.就是向某个人传文件的速度很慢,但传过去的文件是完整的.传的过程中双方有一次确认收到包的握手.还有发送的包如果比较大(几十K,当然不会超过65535BYTE的)
做了类似QQ的东西,当然和QQ比差远了.就是向某个人传文件的速度很慢,但传过去的文件是完整的.传的过程中双方有一次确认收到包的握手.还有发送的包如果比较大(几十K,当然不会超过65535 BYTE的)时,丢包很严重,如果包只有几K时情况好的多.但发7M的文件要10分钟还多一点.QQ就快多了.
想问一下各位兄弟有没有什么高见?
实在不行我想用2条线程发,对方用2条收了.
8 个解决方案
把文件分隔为多个小包方式，采用断点续传，且每个小包采用校验，解决数据丢失，小包方式最好小于0。5kbyte
1、把文件分隔为多个小包方式传输，
2、你可以做两个线程，一个专门分解文件，一个专门发送接收信息。
看来楼主确实下了功夫在这个问题上,发贴子都发那多份^_^.
1、把文件分隔为多个小包方式传输，
2、你可以做两个线程，一个专门分解文件，一个专门发送接收信息。
用 UDP 伟文件,时间都浪费到中间的应答上面了.
如果对速度要求比较高,那还是用 TCP 吧.
TCP 不用中间应答都可以的.
UDP不支持流量控制，要自己做。
否则从高速内网向Internet的接收者传送文件，很多包都被中间路由丢弃了，需要大量重传，当然慢了。
另外通过Internet的传送，为提高效率，包的大小应该不超过路由MTU的大小（通常在1500字节）。
看看这个吧: http://www.realoa.net
多谢各位兄弟的意见,我又重新写了一个算法,用的还是单线程,传输速度已接近QQ,但还没有进行多用户的压力测试,有兴趣的兄弟可帮我测试一下吗?QQ:304593221
京公网安备 11010802041100号