In network programming, there are always a variety of areas to be aware of, almost every API to do exception handling, to determine the return value and error code to locate whether the need to exit.
This paper summarizes the following error codes and their occurrence scenarios and general processing processes according to their own experience.
The general flow of network programming is as follows:
Client: Socket, connect, Write/read
Server: Socket---bind-Listen, accept
There are other changes that are caused by setting properties, such as non-blocking and socket options.
Eaddrinuse: If you are running the same or different programs on the same port, then bind will go wrong. Even if the SO_REUSEADDR is set, only one process is allowed to occupy the specified port at the same time, there is a very special case, that is, to allow full duplicate binding of the same address port, However, this particular situation requires the transport protocol support, and generally only applies to UDP. (Refer to UNP 7.5.11)
eintr: If you do not set non-blocking on the socket, all potentially blocked functions may encounter this error. For example, Connect,accept,read,write ... And so, in the face of this error, the general approach is to ignore it and continue to produce the wrong operation. For example, read a socket, if you encounter this error, ignore, continue to read the line.
einprogress: The timeout for one connect may be around 75s (refer to UNP 4.3), and sometimes we don't want to wait that long. There is a way to set the socket non-blocking before calling connect and then call Connect, where connect immediately returns, and will set errno to Einprocess, this is not a fatal error, just to tell you are already connected, you just have to judge it to continue to execute the following logic on the line, such as SELECT. Set timeout with select to achieve the purpose of setting timeout for connect.
Econnabort: After the arrival of a connection, accept will not return immediately, but first put this connection in the incomplete connection queue, and then do some processing later put to the completed connection queue, accept only from the completed connection queue to take this connection, if the connection before the accept, the disconnection, Accept will return this error, of course, this error is not fatal, but if you write like this, you will be miserable.
if (errno = = eintr/* | | errno = = econnabort*/) { continue;} else{ return-1;
The above code shows that when the accept error returns, not only to determine the interruption, but also to determine the termination of the connection.
Eagain: If you have a socket that is non-blocking, you need to read/write/recv/send ... Such a function to determine the return value, if it fails to return, and errno is Eagain, this is not fatal, you just ignore it, continue to handle the line, this error just tells us that the current socket is not data readable or there is no space to load the data to be sent.
Ewouldblock: In most TCP implementations, this error code is the same as Eagain. Refer to Baidu Encyclopedia <errno >
esrch: This error code means that the process or thread does not exist, and when you are dealing with a complex multi-process or multithreaded environment, you can do a lot of things around this error code.
econnreset: When we call connect connection server, if the server is returning the RST, we will receive such an error. This seems to be a fatal mistake, if encountered, either have been connected, or quit.
etimedout: If your socket is blocked, you may not be able to send data within a certain time period, and you will receive Etimeout
Ehostunreach: In the above scenario, if a router in the middle of the time triggers an ICMP-to-end unreachable error, then your function will return the error code.
Eperm : This error code is a bit unpopular, I also accidentally encountered. When you write a broadcast program, if you use a broadcast address, but do not set the broadcast properties, you will see this errno
Epipe : This error should be the most complicated one. The first thing we need to know is a special scenario in network programming.
When a socket has been closed, if we continue to write this socket, you will not be aware of anything unusual, the return value tells you that you write successfully, but if you capture the packet through Wireshark, you will find that the receiver has replied to a RST, You don't know this rst. The only way you can detect it is to read the socket, which will return 0, before you find out that the connection has been disconnected. Well, I suppose I don't care about it and continue to write, and then the program crashes. What caused the program to collapse, that is Sigpipe, The default behavior of this signal is to terminate the process.
Say back to the epipe, for Sigpipe, if you did not capture it, then the program will quit, there is no epipe, so the premise of this errno must be that you set up a signal capture. Then this error is fatal, see the situation, anyway, the connection is not, At least after you get the error, you should close the socket on this side.
Above...
Summary of common error codes in network programming
