这两天在整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