1.原因
对一个对端已经关闭的socket调用两次write,第二次将会生成SIGPIPE信号, 该信号默认结束进程。
具体的分析可以结合TCP关闭的”四次握手”。TCP是全双工的信道, 可以看作两条单工信道, TCP连接两端的两个端点各负责一条。当对端调用close时, 虽然本意是关闭整个两条信道,但本端只是收到FIN包。 按照TCP协议的语义, 表示对端只是关闭了其所负责的那一条单工信道, 仍然可以继续接收数据。 也就是说, 因为TCP协议的限制, 一个端点无法获知对端的socket是调用了close还是shutdown。
对一个已经收到FIN包的socket调用read方法, 如果接收缓冲已空, 则返回0, 这就是常说的表示连接关闭。但第一次对其调用write方法时,如果发送缓冲没问题,会返回正确写入(发送)。但发送的报文会导致对端发送RST报文,因为对端的socket已经调用了close,完全关闭,既不发送,也不接收数据。所以,第二次调用write方法(假设在收到RST之后), 会生成SIGPIPE信号,导致进程退出。
在linux下写socket的程序的时候,如果尝试send到一个disconnected socket上,就会让底层抛出一个SIGPIPE信号。
这个信号的缺省处理方法是退出进程,大多数时候这都不是我们期望的。
2.方法
为了避免进程退出, 可以捕获SIGPIPE信号,或者忽略它,方法有:
(1)间接忽略
static void SignalHandler(int nSigno)
{
signal(nSigno, SignalHandler);
switch(nSigno)
{
case SIGPIPE:
printf("Process will not exit\n");
break;
default:
printf("%d signal unregister\n", nSigno);
break;
}
}
atic void InitSignalHandler()
{
signal(SIGPIPE , &SignalHandler);
}
int main()
{
InitSignalHandler();
........
return 0;
}
(2)直接忽略
signal(SIGPIPE,SIG_IGN);
(3)重载signaction
struct sigaction sa;
sa.sa_handler = SIG_IGN;
sigaction( SIGPIPE, &sa, 0 );
3.其他
正常情况下,(1)(2)(3)都是可以的。
如果(1)(2)(3)收到SIGPIPE之后依然进程退出,可能的一个原因如下:
查询SIGPIPE这个信号的特性:
如果在写到管道时读进程已终止,则产生此信号。当类型为SOCK_STREAM的套接字已不再连接时,进程写到该套接字也产生此信号。 ——《UNIX环境高级编程》中10.2节
客户端是用send()进行发送数据的,通过man手册查看send()函数,看到有一条这样说:
MSG_NOSIGNAL Requests not to send SIGPIPE on errors on stream oriented sockets when the other end breaks the connection. The EPIPE error is still returned.
于是将send()最后一个参数flags改为MSG_NOSIGNAL,再次启动客户端测试。SIGPIPE成功被忽略,客户端没有因为该信号退出。
【参考:http://blog.sina.com.cn/s/blog_502d765f0100kopn.html
http://blog.youkuaiyun.com/woxiaozhi/article/details/40624033】