探讨socket引发SIGPIPE信号的问题

时间:2023-03-09 22:39:23
探讨socket引发SIGPIPE信号的问题

  我写socket相关的程序也不是一天两天了,在我的记忆中,只要处理好recv(或read)的返回值中<0,==0,>0三种情况,程序便不会有什么问题。但最近在看公司的源代码时,发现代码中直接将SIGPIPE设置为SIG_IGN。而且附上一段注释:往一个已经关闭的socket写入数据会触发SIGPIPE。我心中顿时一惊,我以前从来没这样做过,虽然没出问题,难道只是我运气好?

  周末,决定验证一下。

  首先,socket的读事件中,返回0表示socket已关闭。如果已经关闭,再往里面写东西肯定会出问题的,肯定不是这么低级的问题。那么有一种情况,即假如服务端的epoll在一次loop中检测该socket正常,然后去处理其他逻辑。恰好这时客户端这时关闭了socket。接着服务端要往socket写数据。那么,这时是否会出现SIGPIPE呢?于是在网上随便拷贝了几份代码来验证(偷懒...)。

  服务端代码

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<sys/socket.h>
#include<sys/types.h>
#include<unistd.h>
#include<netinet/in.h>
#include <errno.h>
#define PORT 6666
int main(int argc,char **argv)
{
int ser_sockfd,cli_sockfd;
int err,n; struct sockaddr_in ser_addr;
struct sockaddr_in cli_addr;
char recvline[];
const char *sendline = "hello client"; ser_sockfd=socket(AF_INET,SOCK_STREAM,);
if(ser_sockfd==-)
{
printf("socket error:%s\n",strerror(errno));
return -;
} bzero(&ser_addr,sizeof(ser_addr));
ser_addr.sin_family=AF_INET;
ser_addr.sin_addr.s_addr=htonl(INADDR_ANY);
ser_addr.sin_port=htons(PORT);
err=bind(ser_sockfd,(struct sockaddr *)&ser_addr,sizeof(ser_addr));
if(err==-)
{
printf("bind error:%s\n",strerror(errno));
return -;
} err=listen(ser_sockfd,);
if(err==-)
{
printf("listen error\n");
return -;
} printf("listen the port:%d\n",PORT); while()
{
socklen_t addlen=sizeof(struct sockaddr);
cli_sockfd=accept(ser_sockfd,(struct sockaddr *)&cli_addr,&addlen);
if(cli_sockfd==-)
{
printf("accept error\n");
}
while()
{
printf("waiting for client...\n");
n=recv(cli_sockfd,recvline,,);
printf( "recv return %d\n",n );
if(n==-)
{
printf("recv error\n");
}
recvline[n]='\0'; printf("recv data is:%s\n",recvline); int ret = send(cli_sockfd,sendline,strlen(sendline),);
printf( "send return %d\n",ret );
}
close(cli_sockfd);
} close(ser_sockfd); return ;
}

  客户端代码

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<sys/socket.h>
#include<sys/types.h>
#include<unistd.h>
#include<netinet/in.h>
#include <arpa/inet.h> #define PORT 6666 int main(int argc,char **argv)
{
int sockfd;
int err,n;
struct sockaddr_in addr_ser;
const char *sendline = "hello baby"; sockfd=socket(AF_INET,SOCK_STREAM,);
if(sockfd==-)
{
printf("socket error\n");
return -;
} bzero(&addr_ser,sizeof(addr_ser));
addr_ser.sin_family=AF_INET;
inet_aton( "127.0.0.1",&addr_ser.sin_addr );
addr_ser.sin_port=htons(PORT);
err=connect(sockfd,(struct sockaddr *)&addr_ser,sizeof(addr_ser));
if(err==-)
{
printf("connect error\n");
return -;
} printf("connect with server...\n"); send(sockfd,sendline,strlen(sendline),); close( sockfd ); printf("already close...\n"); return ;
}

  这个测试很简单,服务器打开端口监听,客户端连接上服务器后马上发送数据,接着直接关闭socket并退出程序。服务器在收到消息后,断点等待客户端退出,然后往socket写数据,看是否会出现SIGPIPE。

  服务器编译为sock_s,客户端编译sock_c,先用gdb运行sock_s,下好断点,然后运行sock_c。

Reading symbols from ./sock_s...done.
(gdb) b
Breakpoint at 0x400b7b: file sock_s.cpp, line .
(gdb) r
Starting program: /home/xzc/code/test/sock_s
listen the port:
waiting for client...
recv return
recv data is:hello baby Breakpoint , main (argc=, argv=0x7fffffffded8) at sock_s.cpp:
int ret = send(cli_sockfd,sendline,strlen(sendline),);
(gdb) c
Continuing.
send return
waiting for client...
recv return
recv data is: Breakpoint , main (argc=, argv=0x7fffffffded8) at sock_s.cpp:
int ret = send(cli_sockfd,sendline,strlen(sendline),);
(gdb) c
Continuing. Program received signal SIGPIPE, Broken pipe.
0x00007ffff7b104fd in __libc_send (fd=, buf=0x400c74, n=, flags=-)
at ../sysdeps/unix/sysv/linux/x86_64/send.c:
../sysdeps/unix/sysv/linux/x86_64/send.c: 没有那个文件或目录.

由上面的调试结果可以看出,客户端连接上后发了hello baby然后直接退出。这时服务器在发送数据之前断点停下。我故意等了很久,确认客户端已真正退出,再continue,可以看到,send函数没有异常,返回了12,说明数据正常写到了socket缓冲区。这时socket会再次收到recv,长度为0,表示socket关闭。我故意不处理,继续send,这次gdb捕捉到了SIGPIPE。

  在recv返回0之前用netstat查看网络状态:

...
tcp localhost: localhost: FIN_WAIT2
tcp localhost: localhost: CLOSE_WAIT
...

在recv返回0之后,虽然服务器依然没有调用close,连接在网络状态已经查询不到,说明已关闭。但如果在recv返回0之前,断点很久,客户端的socket已关闭,服务端则仍然是CLOSE_WAIT,结果依然如上。

  后来又用了epoll模型来测试,结果不变。

  因此,recv返回0则认为程序已经知道socket关闭,socket底层将会正常执行TCP的断开流程,跟你是否调用close无关。是否调用close只是是否释放文件描述符等资源。所以,处理好socket的断开事件,则无需理会SIGPIPE.