工作日记：TCP和UDP实现传输数据时部分数据丢失原因分析和解决方法-C++技术网

工作日记：TCP和UDP实现传输数据时部分数据丢失原因分析和解决方法

更新时间：2015-06-25 14:52:43浏览次数：1+次

2013年8月21日星期三晴

    昨天用TCP实现了文件传送。各种文件的传送，大小不限。但是有一个问题，就是有个别数据丢失，比如歌曲会偶尔出现卡顿，虽然不伤大雅，但是技术上确实有缺陷的，总是不好。但至于什么原因，一下子也弄不清楚。至少从之前不能顺利的传送文件来说，心情舒畅多了。之前的传文件大文件不行，大小写定了，只能是传送一个确定的大小的文件。这次实现了自由传送，就是数据有丢失而美中不足。之前也都是用UDP实现的，但总是有问题，也搞不清楚问题所在。查资料也查不出所以然。所以就暂停了用UDP实现了。看了一下别人用MFC实现的TCP文件传送。大致看了一下思路，然后尝试用API函数进行实现，当然是用TCP传文件。一番编写和调试之后，文件可以传送了。传了歌曲，听着歌声，那感觉好极了。感觉从未听过这么好听的歌曲了。不过，中间咯噔一下，卡顿了一下，心里有点不舒服，不过好在就那么一下，暂且可以先放着，心情还是很不错的。今天上午来上班，然后就用UDP进行文件传送，思路是一样的。然后调试，传送歌曲文件，可是接收方始终无法退出，强制关掉程序，播放了歌曲，依然能够播放。可是短短几分钟之内卡顿跳跃二十多次，并且接收端程序还无法正常退出。这样问题就大了。开始我以为是数据丢失，因而导致循环条件不满足，就强行将每次接受的设置成为发送的字节数。然而还是不能正常退出，这样的话就不是这个问题了。无奈之下，启动调试模式执行，设置了断点，几下子调到一次循环后，停在那里了，结果发现时recvfrom()函数阻塞了，导致程序一直阻塞在那里。问题在哪里呢？分析了一下，因为从得到的文件里分析，文件数据有丢失，而我用本机测试的，网络传送的丢失率是非常小的。正是由于丢失了数据，导致后来的数据是空的，接收函数没接到数据就一直在那阻塞等待。那造成阻塞的原因是什么呢？结合网络课程里介绍的，接收方来不及接收的话，数据就会被丢弃掉，从而造成数据丢失。也对，就现在的传输线路来说，基本不会出现大幅度的数据丢失，况且是本机。也就是数据能够正确传送到对方，丢失发生在接收时，正是因为数据在接收方的缓存满了放不下而丢掉，从而造成了丢失。根据这个推断，就在发送端人为的延迟10毫秒，传送歌曲文件时，11M传送了好半天。不过最后，程序都正常结束传送。播放歌曲听听，结果歌曲完整的传送和接收了，从而证明了我的推测。不过延迟太大了，效率太低，然后就将延迟缩短为1毫秒。从人类来讲，1毫秒实在是太短了，感觉计算机还是来不及接收，不过，计算机就是计算机，一秒钟可以执行几百万条指令，对于它来说，1毫秒足够了。然后将这个想法应用到TCP传送中，然后文件也能完整的传送了。就这样两种协议都能够可靠的传送了。
    不过这里使用的是同步的文件传送，人为定了延时，不过真正在网络中传送时，谁也不知道何时文件接收完毕了，这样确定合适的延迟时间久太难了。这就需要使用异步通信了。通过异步应答机制进行确认，这样就完全保证文件的可靠传输了。这个星期的主要技术问题就基本解决了。
    路还很长，还需要不断的完善和深入了解，技术还有待不断的提升。

工作日记：TCP和UDP实现传输数据时部分数据丢失原因分析和解决方法

2013年8月21日 星期三 晴

2013年8月21日星期三晴