环境:Linux
语言:c++
38 个解决方案
#1
Keep-Alive很重要,研究一下心跳包了~~~
#2
帮顶,我也遇到类似问题~
#3
Mark
#4
Keep-Alive的问题,设置为true,
#5
按道理一直连接的话,只要双方不closesocket,发送应该没问题。这个可能是丢包了。
#6
TCP不该丢包的!
试试在发送方
int flag = 1;
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag))
试试在发送方
int flag = 1;
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag))
#7
你可能需要发一个东西当作心跳,要不windows可能认为掉线了?
#8
试了,好像还是不行啊
#9
试了用Keep-Alive还是丢包啊
#10
mark一下,这个对我有用
#11
永远不要指望send(什么什么),就recv(什么什么)!
因为send(什么什么),recv(什)recv(么什)recv(么)是很正常的现象。
所以send必须打包,recv必须缓冲和拆包。
因为send(什么什么),recv(什)recv(么什)recv(么)是很正常的现象。
所以send必须打包,recv必须缓冲和拆包。
#12
围观 顶一个
#13
顶了。
#14
mark
#15
TCP是不会丢包的
只是你没有收到数据罢了
只是你没有收到数据罢了
#16
没显示出来??
#17
自己实现心跳代码吧。
系统默认的心跳代码太漫长了,甚至对方都认为你掉线,已经关闭连接了。
系统默认的心跳代码太漫长了,甚至对方都认为你掉线,已经关闭连接了。
#18
接收端的代码,贴个框架出来吧,尤其是把所有的sockopt设置贴出来。应该不是keep-alive问题。应该不是丢包问题。TCP_NODELAY也不太象。
感觉还是代码处理上的问题。
#19
Socket连接保持一段时间后也会释放吧.
加上心跳检测包或者握手相关的消息,发送成功对方应该是收到了,
加上心跳检测包或者握手相关的消息,发送成功对方应该是收到了,
#20
应该是没有保持连接的问题了
#21
《TCP-IP详解卷一:协议》第17到23章
#22
你这样泛泛的说 实在不知道哪里出问题了
不过TCP是可靠的连接 不会出现丢包的情况 这是可以肯定的
不过TCP是可靠的连接 不会出现丢包的情况 这是可以肯定的
#23
up^
#24
TCP 包怎么会丢呢?
#25
服务器端不能有效的判断客户端是否在线也就是说,服务器无法区分客户端是长时间在空闲,还是已经掉线的情况
#26
服务器端不能有效的判断客户端是否在线也就是说,服务器无法区分客户端是长时间在空闲,还是已经掉线的情况
#27
DDDDD
#28
mark~~~~~~~
#29
up,围观学习中
#30
这样说太笼统了,下一次再发送,客户就能接到,说明连接没有断开。
lz还是考虑其他方面原因
lz还是考虑其他方面原因
#31
这个问题应该不是心跳的问题。
应该是接收端处理程序问题的可能性比较大。
检测方法是抓包。看第一次send的时候,网络上是不是走了send的数据。我觉得应该是走了数据。
应该是接收端处理程序问题的可能性比较大。
检测方法是抓包。看第一次send的时候,网络上是不是走了send的数据。我觉得应该是走了数据。
#32
可以抓包分析下,看数据包究竟有没发送成功;或者对方有没收到数据包。
#33
#34
发心跳啊
#35
会不会是在Client::recv()的时候,没有WaitSingleEvent(),导致文件接收的顺序错误?
#36
心跳包,学习了
#37
抓包看下失败发生在什么地方
#38
#1
Keep-Alive很重要,研究一下心跳包了~~~
#2
帮顶,我也遇到类似问题~
#3
Mark
#4
Keep-Alive的问题,设置为true,
#5
按道理一直连接的话,只要双方不closesocket,发送应该没问题。这个可能是丢包了。
#6
TCP不该丢包的!
试试在发送方
int flag = 1;
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag))
试试在发送方
int flag = 1;
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag))
#7
你可能需要发一个东西当作心跳,要不windows可能认为掉线了?
#8
试了,好像还是不行啊
#9
试了用Keep-Alive还是丢包啊
#10
mark一下,这个对我有用
#11
永远不要指望send(什么什么),就recv(什么什么)!
因为send(什么什么),recv(什)recv(么什)recv(么)是很正常的现象。
所以send必须打包,recv必须缓冲和拆包。
因为send(什么什么),recv(什)recv(么什)recv(么)是很正常的现象。
所以send必须打包,recv必须缓冲和拆包。
#12
围观 顶一个
#13
顶了。
#14
mark
#15
TCP是不会丢包的
只是你没有收到数据罢了
只是你没有收到数据罢了
#16
没显示出来??
#17
自己实现心跳代码吧。
系统默认的心跳代码太漫长了,甚至对方都认为你掉线,已经关闭连接了。
系统默认的心跳代码太漫长了,甚至对方都认为你掉线,已经关闭连接了。
#18
接收端的代码,贴个框架出来吧,尤其是把所有的sockopt设置贴出来。应该不是keep-alive问题。应该不是丢包问题。TCP_NODELAY也不太象。
感觉还是代码处理上的问题。
#19
Socket连接保持一段时间后也会释放吧.
加上心跳检测包或者握手相关的消息,发送成功对方应该是收到了,
加上心跳检测包或者握手相关的消息,发送成功对方应该是收到了,
#20
应该是没有保持连接的问题了
#21
《TCP-IP详解卷一:协议》第17到23章
#22
你这样泛泛的说 实在不知道哪里出问题了
不过TCP是可靠的连接 不会出现丢包的情况 这是可以肯定的
不过TCP是可靠的连接 不会出现丢包的情况 这是可以肯定的
#23
up^
#24
TCP 包怎么会丢呢?
#25
服务器端不能有效的判断客户端是否在线也就是说,服务器无法区分客户端是长时间在空闲,还是已经掉线的情况
#26
服务器端不能有效的判断客户端是否在线也就是说,服务器无法区分客户端是长时间在空闲,还是已经掉线的情况
#27
DDDDD
#28
mark~~~~~~~
#29
up,围观学习中
#30
这样说太笼统了,下一次再发送,客户就能接到,说明连接没有断开。
lz还是考虑其他方面原因
lz还是考虑其他方面原因
#31
这个问题应该不是心跳的问题。
应该是接收端处理程序问题的可能性比较大。
检测方法是抓包。看第一次send的时候,网络上是不是走了send的数据。我觉得应该是走了数据。
应该是接收端处理程序问题的可能性比较大。
检测方法是抓包。看第一次send的时候,网络上是不是走了send的数据。我觉得应该是走了数据。
#32
可以抓包分析下,看数据包究竟有没发送成功;或者对方有没收到数据包。
#33
#34
发心跳啊
#35
会不会是在Client::recv()的时候,没有WaitSingleEvent(),导致文件接收的顺序错误?
#36
心跳包,学习了
#37
抓包看下失败发生在什么地方