最近在做一个项目,在这之前,做了个验证程序.
发现客户端连续发来1000个1024字节的包,服务器端出现了丢包现象.
纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了.
有没有成熟的解决方案来解决这个问题.
我用过sleep(1),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能丢失.
希望大俠帮帮忙啊!
|
有两种方法解决楼主的问题：
方法一：重新设计一下协议，增加接收确认超时重发。(推荐)
方法二：在接收方，将通信和处理分开，增加个应用缓冲区；如果有需要增加接收socket的系统缓冲区。(本方法不能从根本解决问题，只能改善)
|
网络丢包，是再正常不过的了。
既然用UDP，就要接受丢包的现实，否则请用TCP。
如果必须使用UDP，而且丢包又是不能接受的，只好自己实现确认和重传，说白了，就是自己实现TCP(当然是部分和有限的简单实现)。
|
采用回包机制,每个发包必须收到回包后再发下一个
|
丢包的原因我想并不是“服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了”，而是服务器端的socket接收缓存满了(udp没有流量控制，因此发送速度比接收速度快，很容易出现这种情况)，然后系统就会将后来收到的包丢弃。你可以尝试用setsockopt()将接收缓存(SO_RCVBUF)加大看看能不能解决问题。
|
可以采用回包机制,但处理起来还是比较麻烦....服务器端可以加一个判断对数据是否接收进行重发.
但是我个人感觉LZ可以试试楼上所说用多线程去处理一下试试..
|
UDP是无连接的，面向消息的数据传输协议，与TCP相比，有两个致命的缺点，一是数据包容易丢失，二是数据包无序。
要实现文件的可靠传输，就必须在上层对数据丢包和乱序作特殊处理，必须要有要有丢包重发机制和超时机制。
常见的可靠传输算法有模拟TCP协议，重发请求(ARQ)协议，它又可分为连续ARQ协议、选择重发ARQ协议、滑动窗口协议等等。
如果只是小规模程序，也可以自己实现丢包处理，原理基本上就是给文件分块，每个数据包的头部添加一个唯一标识序号的ID值，当接收的包头部ID不是期望中的ID号，则判定丢包，将丢包ID发回服务端，服务器端接到丢包响应则重发丢失的数据包。
模拟TCP协议也相对简单，3次握手的思想对丢包处理很有帮助。
|
udp是不安全的，如果不加任何控制，不仅会丢失包，还可能收到包的顺序和发送包的顺序不一样。这个必须在自己程序中加以控制才行。
收到包后，要返回一个应答，如果发送端在一定时间内没有收到应答，则要重发。
|
UDP本就是不可靠连接，不能保证不丢包
UDP丢包除了上面说的，网络路由也有可能会发生丢包现象，TTL为0的时候这个包就会被丢弃，而不会给发送者任何信息，而TCP在这种情况下是有回复的。
