closesocket()之后对方send()不会出错?

Fabio 2000-12-05 02:12:00
为什么在一方closesocket()之后,对方的send()函数仍然不会报错!?
这究竟是为什么?
难道一定要用getpeername()才能知道对方是否已关闭呢?
...全文
385 19 打赏 收藏 转发到动态 举报
写回复
用AI写文章
19 条回复
切换为时间正序
请发表友善的回复…
发表回复
meifen 2001-07-13
  • 打赏
  • 举报
回复
s
Fabio 2000-12-08
  • 打赏
  • 举报
回复
问题暂时解决了.
我在server端最后再做一次recv(),WSAGetLastError()

在正常的情况下,连接关闭已经完成,WSAGetLastError()返回的是0或者10035;

如果client在server的上一个send()之前已经关闭,server会收到一个RST=1的包,WSAGetLastError()返回10058或者10054;

如果client掉线,server的WSAGetLastError()也不会返回0和10035,好象还是10058

lz_0618 2000-12-07
  • 打赏
  • 举报
回复
关注,本人也遇到类似问题,客户端正常关闭时,服务器能知道,但在拔网线或客户机掉电等意外事件时,服务器不知道。
Fabio 2000-12-07
  • 打赏
  • 举报
回复
我看了下TCP的包,是这样的:
client断开连接,server收到一个FIN,并发了个ACK
这时,server程序执行到send(),
server发出去的包是URG=1,Push=1,然后收到的是client送过来的RST

难道send()不是收到对方的ACK才返回字节数的吗?
难道是Nonblocking的问题? 可是我已经设成Blocking的了呀!
faint
坎坷的菜贩 2000-12-06
  • 打赏
  • 举报
回复
closesocket之前最好先shutdown。
Fabio 2000-12-06
  • 打赏
  • 举报
回复
setsockopt()返回0,没错啊
不如你也做做这个实验吧
server accept()一个连接,然后把client端的程序关掉,
server再send(),看会不会报错.
sxbyl 2000-12-06
  • 打赏
  • 举报
回复
对了,你用setscokopt的时候查错了没有?
sxbyl 2000-12-06
  • 打赏
  • 举报
回复
不是吧?难道世界末日到了?还是物质不灭定律除了问题……
Fabio 2000-12-06
  • 打赏
  • 举报
回复
真的是啊! 绝对是TCP的! sendto()才是UDP的
在连接建立后拔掉网线的情况下, Nonblocking的recv()会报Timeout, Blcoking的recv()会等到你心疼.
send()还是快乐的正常执行.
victorchen_2000 2000-12-06
  • 打赏
  • 举报
回复
那不太可能,UDP才会那样。
Fabio 2000-12-06
  • 打赏
  • 举报
回复
也不行啊
无论是Nonblocking还是SO_KEEPALIVE都没用
我在调试的时候,在send()之前把网线拔了,还是没有报错!
为什么我期待的错误总是不出现!!!!!!?????
jiujiejushi 2000-12-06
  • 打赏
  • 举报
回复
套接字的关闭可以是雅致的,也可以是强制的.
默认为雅致的,也就是所有正在进行中的数据完成之后才真正关闭,释放资源,这也是服务程序关闭后立即重启时有时会bind失败的原因.
我试过强制关闭,最后一个send返回之后立即closesocket,客户端发生连接被复位错误.

程序:STATE 是 int , s 是将要设为强制关闭的套接字
//设置套接字选项,强制关闭,仅用于程序强制退出时,否则将丢失数据
STATE SetSocketCloseHard(SOCKET s)
{
struct linger ling1;
int ret;

ling1.l_onoff=1;
ling1.l_linger=0;
ret=setsockopt(s,SOL_SOCKET,SO_LINGER,(char *)&ling1,sizeof(ling1));
if(SOCKET_ERROR==ret)return -1;
else return 1;
}
sxbyl 2000-12-06
  • 打赏
  • 举报
回复
这是我从讲Socket的电子书上摘下来的,要的话说信箱。
一个应用程序可以通过打开SO_KEEPALIVE选项,使得WINDOWS套接口实现在TCP连接情况下允许使用“保持活动”包。一个WINDOWS套接口实现并不是必需支持“保持活动”,但是如果支持的话,具体的语义将与实现有关,应遵守RFC1122“Internet主机要求-通讯层”中第4.2.3.6节的规范。如果有关连接由于“保持活动”而失效,则进行中的任何对该套接口的调用都将以WSAENETRESET错误返回,后续的任何调用将以WSAENOTCONN错误返回。
xlfrd 2000-12-06
  • 打赏
  • 举报
回复
不会报错,也许会出现异常,
用try{
send()}
catch(...){}
试试,看它跳进陷阱不
xlfrd 2000-12-05
  • 打赏
  • 举报
回复
sxbyl前辈能不能再详细一点点,谢过谢过。
sxbyl 2000-12-05
  • 打赏
  • 举报
回复
你可以用setsockopt设置SO_KEEPALIVE为真,这样,网络断掉程序可以马上知道。
Fabio 2000-12-05
  • 打赏
  • 举报
回复
是TCP的

会不会是用了nonblocking方式的缘故?
victorchen_2000 2000-12-05
  • 打赏
  • 举报
回复
用的哪个控件,是UDP吗?udp不会出错。
ddddh 2000-12-05
  • 打赏
  • 举报
回复
关注

对了,不知道用shutdown怎么样?这个据说可以很“优雅”的关闭:)

16,472

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧