Socket error return code in Linux

Whether the description of the symbol name signal value complies with POSIX
Sighup 1 detected hanging up on the control terminal or the control thread died
SIGINT 2 interaction notice signal is
Sigquit 3 interaction stop signal is
Which of the following commands does sigill 4 detect illegal hardware?
Sigtrap 5 does not return from the trap
SIGABRT 6 abnormal termination signal is
Sigemt 7 command no
The incorrect arithmetic operation signal of sigfpe 8 is
Sigkill 9 termination signal is
Sigbus 10 bus error no
SIGSEGV 11 detected that invalid memory call is
Sigsys 12 system call error parameter No
Sigpipe 13 is written in a reader-less Pipeline
When sigalrm 14 is reported, the signal is
Sigterm 15 Termination signal is
Sigurg 16 I/O channel emergency signal No
Sigstop 17 pause signal is
Sigtstp 18 interaction pause signal is
Sigcont 19 if paused, continue to be
Sigchld 20 sub-thread termination or suspension is
A member of the background thread group of sigttin 21 tries to read
Sigttou 22 background thread group members try to write to the control terminal is
Sigio 23 allows I/O signal No
Sigxcpu 24 exceeds CPU limit no
Sigxfsz 25 exceeds the file size limit no
Sigvtalrm 26 virtual time alarm No
Sigprof 27 side time Alert No
Sigwinch 28 window size change no
Siginfo 29 message request no
SIGUSR1 30 reserved as user-defined signal 1 is
Sigusr2 31 is reserved as a user-defined Signal
Note: The Linux signal mechanism is basically inherited from UNIX systems. In early Unix systems, the signal mechanism was relatively simple and original, and some problems were exposed in practice. Therefore, the signals built on the early mechanism were called "unreliable signals ", signal value less than sigrtmin (red
In Hat 7.2, sigrtmin = 32, sigrtmax = 63) signals are all unreliable signals. This is the source of "unreliable signal. The main problem is that each time a process processes a signal, it sets the response to the signal as the default action. In some cases, it may lead to incorrect signal processing. Therefore, if you do not want such an operation, you need to call signal () again at the end of the signal processing function (), reinstall the signal.
In addition, I will make some supplements to generate an rst response so that the system sends a sigpipe signal, which can be divided into two situations:
1. The network between the client and the server is disconnected, or the server is powered off, and the physical connection is disconnected. In this case, the client will not exit, and the send function will be executed normally without any errors. Because the physical network is disconnected, the server does not respond to the error message from the client. If there is no rst response, it naturally does not generate a sigpipe signal. However, when the server returns to normal again, the RST response is generated for the messages sent from the client, and the client receives the sigpipe signal. The program exits, but the send function can return
-1. Exception Handling is supported.
2. The client can communicate with the server through the network. If the service program fails, the client program will immediately exit because the server can normally return an error message. When the client receives the message, the sigpipe signal will be generated. However, I am not sure that the RST response is returned by the server at this time. The packet capture result shows that there is no rst flag. The level is limited. Only this is the case.