服务器与客户端模型SIGPIPIE信号

先了解下套接字的关闭

客户端调用close，或者就算客户端进程关闭，系统内核也会自动close(socket)，且注意，当socket引用为0时才会真正调用close()，close()总是立即返回的，然后由系统尝试发送完内核缓冲区内的所有数据，接着才发送FIN。

说到这里，不得不谈谈TCP连接关闭的四次握手。可以看成是2组FIN, ACK。主动关闭的一方先发送FIN，收到ACK后，进入FIN_WAIT2状态，此时也叫做“半关闭”状态，特别须要注意的是，此时客户端套接字依然可以接收数据包，但是不能发送数据包。 被动关闭的一方，此时收到FIN了，一般情况下都是由于read(socket)返回0，然后得知对方关闭，close(socket)后，另外一组FIN，ACK随之产生，此时主动方进入TIME_WAIT状态。即四次握手完成。

服务器端关闭，但是客户端要从标准输入读字符，这是阻塞方式，服务端关闭连接后，客户端无法知道，因为它阻塞在标准输入了，当我们再次输入字符，并发送，收到FIN或RST，此时客户端才关闭。总之，客户端由于某种原因，不能及时调用read()，返回0，所以无法得知服务器关闭了连接。

下面看看我们的问题

当对端已经关闭连接，己方如果read，发现接收缓冲区是0，则正常退出。但服务器先关闭，而客户端恰好read前先调用了write或者send函数，将会发生程序异常退出现象。因为TCP全双工，对端CLOSE，虽然本意是关闭整个两条信道,但本端只是收到FIN包. 按照TCP协议的语义, 表示对端值关闭了其所负责的单工信道, 仍然可以继续接收数据. 也就是说, 因为TCP协议的限制, 一个端点无法获知对端已经完全关闭.

对一个已经收到FIN包的socket第一次对其调用write方法时,如果发送缓冲没问题, 会返回正确写入(发送). 但发送的报文会导致对端发送RST报文, 所以, 第二次调用write方法(假设在收到RST之后), 会生成SIGPIPE信号, 导致进程退出.

 

结论：对一个对端已经关闭的socket先调用两次write或send, 第二次Linux内核将会主动调用SIGPIPE信号,该信号默认结束进程.而有些情况我们并不想让程序结束，或者说让程序这么意外的结束，那么

解決办法（避免程序退出）：

调用信号忽略函数signal（SIGPIPE，SIG_IGN），忽略内核调用的SIGPIPE信号；

或者重写信号处理函数signal(SIGPIPE， handler);

void handler( )

{

//do something…

}

 

整理 <http://www.cnblogs.com/549294286/p/5077237.html> 

     <http://www.cnblogs.com/549294286/p/5077237.html>