数据量太大接收有时会丢包的有关问题求教
数据量太大接收有时会丢包的问题求教
我写的C/S socket通信程序需要一字不错的发送和接收，使用TCP。在网络良好的局网内使用一切正常，也无出现丢包现象。但如果通过公网，网速不稳定，收发较大量数据就有时会丢包，接收方收不到预期数量的数据而超时返回，调试显示每次缺的总是后面的部分。如果发送的数据数量不大，则很少出现丢包问题，即使是在公网。这种故障请高手支招。
有时收发的数据量较大，通过增加缓冲区的方法可能不太合适。
------解决方案--------------------
tcp不存在丢包的,发送的都是一个流的方式粘包的情况很大,注意接收的方式,要根据接收到的数量(recv返回),来判断是否是一个完整的包,否则就需要根据协议进行拆包处理了.
------解决方案--------------------
使用循环接收,不是很好的方法.
应该使用非阻塞io模型,select检测缓冲区.直到连接断开
------解决方案--------------------
讨论挺激烈，来学习一下
------解决方案--------------------
TCP如果重复一次以上出现丢包这个问题
99.99%以上是代码存在问题
其中最大的可能
1 协议定义存在问题
2 接收或者发送函数存在问题
先看协议，你定义ASCII [15]为结尾字符，请问，你的数据流中是否可能也存在ASCII [15]？
然后我们看一下你的发送函数，哦，SORRY，找不到
你是否采用了阻塞模式发送？如果是，你是否一次性发送，例如 send(s,buffer,10*1024*1024,0)
例如这样的数据量？如果是，那么很遗憾，你将在窄带网络上碰到问题，因为TCP本身有个超时机制，如果在指定时间内，无法将全部数据发送完毕[实际上是先写到SOCKET内部缓冲]，它将返回失败，即使它返回了成功，但是也不能保证接收方就肯定接收成功，因为你的SEND只是从缓冲拷贝到SOCKET内部缓冲，除非你设置SOCKET缓冲是0，但是这将导致CPU开销偏高
如果你是用非阻塞模式发送，那么，请注意你是否每次都检查返回值？这是非常重要的，另外应该放宽，如果本次发送字节为0的情况下，可以持续的时间，一般30秒比较合适
还有最后一点，如果你是用STRUCT结构，请注意字节对齐，服务器端和客户端必须保持相同，一般建议采用64位对齐模式
最后，请尽量不要在接受端对接收超时限制过于严厉，如果你想到INTERNET上去运行的话
------解决方案--------------------
从你的现象是粘包加接收问题。
我写的C/S socket通信程序需要一字不错的发送和接收，使用TCP。在网络良好的局网内使用一切正常，也无出现丢包现象。但如果通过公网，网速不稳定，收发较大量数据就有时会丢包，接收方收不到预期数量的数据而超时返回，调试显示每次缺的总是后面的部分。如果发送的数据数量不大，则很少出现丢包问题，即使是在公网。这种故障请高手支招。
有时收发的数据量较大，通过增加缓冲区的方法可能不太合适。
------解决方案--------------------
tcp不存在丢包的,发送的都是一个流的方式粘包的情况很大,注意接收的方式,要根据接收到的数量(recv返回),来判断是否是一个完整的包,否则就需要根据协议进行拆包处理了.
------解决方案--------------------
使用循环接收,不是很好的方法.
应该使用非阻塞io模型,select检测缓冲区.直到连接断开
------解决方案--------------------
讨论挺激烈，来学习一下
------解决方案--------------------
TCP如果重复一次以上出现丢包这个问题
99.99%以上是代码存在问题
其中最大的可能
1 协议定义存在问题
2 接收或者发送函数存在问题
先看协议，你定义ASCII [15]为结尾字符，请问，你的数据流中是否可能也存在ASCII [15]？
然后我们看一下你的发送函数，哦，SORRY，找不到
你是否采用了阻塞模式发送？如果是，你是否一次性发送，例如 send(s,buffer,10*1024*1024,0)
例如这样的数据量？如果是，那么很遗憾，你将在窄带网络上碰到问题，因为TCP本身有个超时机制，如果在指定时间内，无法将全部数据发送完毕[实际上是先写到SOCKET内部缓冲]，它将返回失败，即使它返回了成功，但是也不能保证接收方就肯定接收成功，因为你的SEND只是从缓冲拷贝到SOCKET内部缓冲，除非你设置SOCKET缓冲是0，但是这将导致CPU开销偏高
如果你是用非阻塞模式发送，那么，请注意你是否每次都检查返回值？这是非常重要的，另外应该放宽，如果本次发送字节为0的情况下，可以持续的时间，一般30秒比较合适
还有最后一点，如果你是用STRUCT结构，请注意字节对齐，服务器端和客户端必须保持相同，一般建议采用64位对齐模式
最后，请尽量不要在接受端对接收超时限制过于严厉，如果你想到INTERNET上去运行的话
------解决方案--------------------
从你的现象是粘包加接收问题。