MonitorServer Code Reading Notes (1): Use sigaction (SIGPIPE, & sa, 0) to avoid process exit caused by writing a closed socket

Read the source code of monitorserver and record some experiences.

 

Start with the main function and start with the following code lines:

1 struct sigaction sa;
2 sa.sa_handler = SIG_IGN;
3 sigaction( SIGPIPE, &sa, 0);

I have never used it before. I don't know why I ignored the sigpipe signal, so I searched for it and explained it as follows:

When writing a socket program in Linux, if you try to send it to a disconnected socket, the underlying layer will throw a sigpipe signal.
The default processing method for this signal is to exit the process, which is not what we expect most of the time. Therefore, we need to reload the processing method of this signal. Call the above Code to safely block sigpipe.

 

Finally, the problem is determined that a socket that has been closed on the peer end is called twice for write. The second request will generate a sigpipe signal, which ends the process by default.

The specific analysis can be combined with TCP's "Four handshakes" to close. TCP is a full-duplex channel. It can be seen as two ticket channels. The two ends of the TCP connection are each responsible for one. when the peer calls close, although the intention is to close the entire two channels, the local end only receives the fin package. according to the semantics of the TCP protocol, the peer only closes the ticket channel in charge of it and can continue to receive data. that is to say, due to the restrictions of the TCP protocol, an endpoint cannot know whether the socket of the Peer side calls close or shutdown.

Call the read method for a socket that has received the FIN packet. If the receiving buffer is empty, 0 is returned. This is often said to indicate that the connection is closed. but when you call the write Method for it for the first time, if there is no problem with the sending buffer, the correct write (sending) will be returned ). however, the sent packets will cause the Peer to send the RST packet, because the socket at the peer end has already called close and is completely closed, neither sending nor receiving data. therefore, the second call to the write method (assuming that after receiving the RST) generates a sigpipe signal, causing the process to exit.

Http://blog.163.com/postmessage@126/blog/static/30614210201032321346143/