The anomaly of network programming and its processing

Network programming is not only to write the network, the host, the process is normal when the process of good work, more important is the client host crashes, the client process crashes the network exception when handling.

accept interrupted by signalThe I/O on the accept and socket may be interrupted by a signal and return eintr as a result, the return value must be processed and called again when appropriate. for (;;)            {if (CONNFD = Accept (LISTENFD, (struct sockaddr*) addr, sizeof (addr)) < 0) {if (CONNFD = = eintr) {        Continue        } else {printf ("Accept error\n"); }    }}

Connect is interrupted by signalConnect is interrupted by a signal, returns EINTR as a result, cannot call connect again on the socket and needs to use Select to wait for the connection to complete.

connection aborted before accept return

The connection of the estiblished state is aborted before being accepted by the accept, for this kind of error, different systems have different processing, most of them return an error result to the process, SVR4 return Eproto (protocol error), POSIX indicates that you must return econnaborted (software-induced connection errors) and call accept again when returning a econnaborted error. Also some operating systems will directly remove this aborted connection, the server process will not find a premature connection.

Echo-echo program handles server-side exception terminationWhen the client process blocks the terminal input, the server process terminates abnormally and the three handshake terminates the connection, and the client appends fin to the end of the read buffer of CLIFD. The client enters characters from the terminal, sends it to the server via CLIFD (because the server is closed, it replies to a RST to the client) and calls read to get the results. At this point, fin is already reading the buffer, and the RST is still in the process of network transmission, so read returns 0, which means that the peer is closed instead of reading the reset message to the RST. To avoid the RST message for this scenario, the client needs to use multiplexing to listen for multiple inputs simultaneously: the socket interface and the terminal input. This allows you to get a fin message earlier, to avoid sending a message to the peer after the connection is terminated.

SigpipeWhen a process writes a message to a socket that receives an RST, the kernel sends a SIGPIPE signal to the process. The complete process is that the process writes a message to a socket that receives a fin, receives an RST reply, writes again, and the kernel sends a SIGPIPE signal to the process. The default action for this signal is to terminate the process without producing a core file. The write operation returns a epipe error regardless of whether the process captures the signal.

Treatment of SigpipeSigpipe the default is to terminate the process and not produce a core file, which is no way to track and discover problems. The processing of the Sigpipe can be: 1. Set the sig_ign, ignore the signal, and default write will handle the Epipe error. 2. Processing the error in the signal processing function, it is necessary to know that the signal processing function cannot determine which socket is wrong, and if you really want to know which socket has an error, you still need to handle the Epipe error after write returns.

Server host crashesWhen a connection is made between the client and the server, the server host crashes, and the message sent to the server host over the network does not receive any response. There are two types of errors that may be returned at this time 1. The client continues to retransmit data in a sub-section that has not been answered and should return a etimeout error. 2. If the intermediate router determines that the server host is unreachable and returns an ICMP error, the error is Ehostunreach or Enetunreach. The return value of write lets you know the cause of the error, but it usually takes a long time to wait.

fast detection of server host crashesAdd a time-out to the socket

detects server host crashes when not actively sending messagesHeartbeat message

Server host crashes after restartingIf the server host crashes and restarts, and the client does not send a message to the server during the crash, the clients are unaware that the server has crashed (if the socket option so_keepalive is not used) and the client sends a message to the server. After the server crashes and restarts, all connection information is lost, and the received message is in RST response, causing the client to receive a econnreset error. If the client detects a host crash error on the server, the so_keepalive should be set.

Server main Office machineWhen the UNIX system shuts down, the INIT process sends a sigterm signal to all processes (we can capture this signal), then waits for a period of time and then sends a sigkill signal to all processes. When the process terminates, all open descriptors are closed. For the server host machine, it is best for the customer to use multiplexing to detect the closure of the socket in a timely manner.

Network data Format1. Convert data in all formats to String message 2. Specify the byte order explicitly, using the same byte order on the server and the client.

The anomaly of network programming and its processing