I. Common anomalies and their handling during the operation of network programs
The 1th exception is java.net.BindException:Address already in Use:jvm_bind.
This exception occurs when the server side operates on a new ServerSocket (port is an integer value of 0,65536). The exception is due to the fact that a port is already being started and is listening. At this point, with the Netstat–an command, you can see a port with a listending status. Just find an unoccupied port to solve this problem.
The 2nd exception is Java.net.ConnectException:Connection Refused:connect.
This exception occurs when the client makes a new Socket (IP, Port) operation because the exception occurs because either the machine with the IP address cannot be found (that is, the current machine does not exist to the specified IP route), or the IP exists, but the specified port is not found for listening. This problem occurs, first check the client's IP and port is wrong, if it is correct to ping the server from the client to see if it can ping, if you can ping (the service server to ping off the need for another method), the server-side listening to the specified port program is started, This will certainly solve the problem.
The 3rd exception is the Java.net.SocketException:Socket is closed,
This exception can occur on both the client and the server. The reason for the exception is that you have actively closed the connection (called the Close method of the socket) and read and write the network connection.
The 4th exception is java.net.SocketException: (Connection reset or connect reset by Peer:socket write error).
This exception can occur on both the client and the server side, causing the exception to be two, the first of which is if the socket on one end is turned off (or closed by an unexpected exit), the other end still sends the data, and the first packet that is sent throws the exception (Connect reset by Peer). The other is one end exiting, but the connection is not closed when exiting, and the other end throws the exception if the data is read from the connection (Connection reset). The simple thing is that the read and write operations are caused by the disconnection of the connection.
The 5th exception is the Java.net.SocketException:Broken pipe.
This exception can occur on both the client and the server. In the first case of the 4th exception (that is, after you throw socketexcepton:connect reset by Peer:socket write error), the exception is thrown if you continue to write the data. The solution to the first two exceptions is to first ensure that all network connections are closed before the program exits, followed by detection of the other's closed connection operation, and that the other person closes the connection after closing the connection.
Two Issues to be aware of when writing network programs
The 1th problem is to correctly distinguish between long and short connections. The so-called long connection is permanently maintained once established. A short connection is a close connection in the following scenario, prepare data, send data, and so on. Many programmers write for years of Web programs, incredibly do not know what is a long connection, what is a short connection.
The 2nd issue is the maintenance of long connections. The so-called maintenance includes two aspects, the first is to detect each other's active disconnection (both call the Close method of the socket), followed by the detection of each other's downtime, abnormal exit and network is not connected. This is a robust communication program that must be available. Detection of the other side of the active disconnection is simple, the main side of the active disconnection, the other side if the read operation, the return value at this time only-1, once the other side of the detection of the disconnection, you should actively shut down their own connection (call the socket's Close method). And the detection of the other side of the outage, abnormal exit and network is commonly used by the "Heartbeat", that is, the two sides periodically send data to each other, but also from the other side to receive the "Heartbeat", if a few consecutive cycles have not received the other heartbeat, you can judge the other party or down or abnormal launch or network, You also need to actively shut down your own connection at this time, if the client can re-initiate the connection after a certain amount of delay. Although the socket has a keep alive option to maintain the connection, if this option is used, it typically takes two hours to discover the other party's outage, abnormal exit, and network connectivity.
The 3rd issue is dealing with efficiency issues. Whether it is a client or a server, if it is a long connection to a program requires at least two threads, one for receiving data, one for sending heartbeat, writing data does not need a dedicated thread, of course, also need a class of threads (commonly known as worker threads) for the processing of messages, that is, the receiving thread is only responsible for receiving data , and then distribute the data to the worker for processing. If it is a short connection, you do not need to send the heartbeat of the thread, if the server also needs a dedicated thread responsible for the connection request listening. These are the overall requirements of a communication program, specifically how to design your program, depends on your own design level.
Java Network Programming FAQs