探讨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 <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,0);
if(sockfd==-1)
{
printf("socket error\n");
return -1;
}

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==-1)
{
printf("connect error\n");
return -1;
}

printf("connect with server...\n");

send(sockfd,sendline,strlen(sendline),0);

close( sockfd );

printf("already close...\n");

return 0;
}

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

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

Reading symbols from ./sock_s...done.
(gdb) b 68
Breakpoint 1 at 0x400b7b: file sock_s.cpp, line 68.
(gdb) r
Starting program: /home/xzc/code/test/sock_s
listen the port:6666
waiting for client...
recv return 10
recv data is:hello baby

Breakpoint 1, main (argc=1, argv=0x7fffffffded8) at sock_s.cpp:68
68                int ret = send(cli_sockfd,sendline,strlen(sendline),0);
(gdb) c
Continuing.
send return 12
waiting for client...
recv return 0
recv data is:

Breakpoint 1, main (argc=1, argv=0x7fffffffded8) at sock_s.cpp:68
68                int ret = send(cli_sockfd,sendline,strlen(sendline),0);
(gdb) c
Continuing.

Program received signal SIGPIPE, Broken pipe.
0x00007ffff7b104fd in __libc_send (fd=4, buf=0x400c74, n=12, flags=-1)
at ../sysdeps/unix/sysv/linux/x86_64/send.c:27
27    ../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        0      0 localhost:58651         localhost:6666          FIN_WAIT2
tcp        0      0 localhost:6666          localhost:58651         CLOSE_WAIT
...

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

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

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