tcp程序SIGPIPE退出

这两天在整tcp的服务端程序异常退出问题。gdb调试发现是收到SIGPIPE信号导致的。

收到SIGPIPE信号原因：

如果尝试send到一个已关闭的 socket上两次，就会出现此信号，也就是用协议TCP的socket编程，服务器是不能知道客户机什么时候已经关闭了socket，导致还在向该已关 闭的socket上send，导致SIGPIPE。而系统默认产生SIGPIPE信号的措施是关闭进程，所以出现了服务器也退出。

下面分析TCP协议的缺陷以至于服务器无法及时判断对方socket已关闭：

具体的分析可以结合TCP的"四次握手"关闭. TCP是全双工的信道, 可以看作两条单工信道, TCP连接两端的两个端点各负责一条. 当对端调用close时, 虽然本意是关闭整个两条信道, 但本端只是收到FIN包. 按照TCP协议的语义, 表示对端只是关闭了其所负责的那一条单工信道, 仍然可以继续接收数据. 也就是说, 因为TCP协议的限制, 一个端点无法获知对端的socket是调用了close还是shutdown.（此段网上抄来的）

为避免这种情况，可以选择忽略SIGPIPE信号，不执行任何动作。（也可以signal(SIGPIPE,SIG_IGN)）

#include <signal.h>

//SIGPIPE ignore

struct sigaction act;

act.sa_handler = SIG_IGN;

if (sigaction(SIGPIPE, &act, NULL) == 0) {

    LOG("SIGPIPE ignore");

}

signal 与 sigaction 区别：
signal函数每次设置具体的信号处理函数(非SIG_IGN)只能生效一次,每次在进程响应处理信号时，随即将信号处理函数恢复为默认处理方式.所以如果想多次相同方式处理某个信号,通常的做法是,在响应函数开始,再次调用signal设置。

sigaction:
1.在信号处理程序被调用时，系统建立的新信号屏蔽字会自动包括正被递送的信号。因此保证了在处理一个
给定的信号时，如果这种信号再次发生，那么它会被阻塞到对前一个信号的处理结束为止
2.响应函数设置后就一直有效,不会重置
3.对除S I G A L R M以外的所有信号都企图设置S A _ R E S TA RT标志，于是被这些信号中断
的系统调用(read,write)都能自动再起动。不希望再起动由S I G A L R M信号中断的系统调用的原因是希望对I / O操作可以设置时间限制。 所以希望能用相同方式处理信号的多次出现,最好用sigaction.信号只出现并处理一次,可以用signal

所以在TCP套接字上发送数据的任何程序都必须显示处理SIGPIPE，以便保持健壮性。

以上，这篇文章总结不错：http://blog.sina.com.cn/s/blog_4888f88101016xr9.html