Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Solutions to the four major anomalies of java.net.SocketException

2025-03-30 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/03 Report--

In this issue, the editor will bring you solutions to the four major anomalies of java.net.SocketException. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

How can java.net.SocketException be better used? This requires us to first understand the relevant questions about the language. I hope you can help. So let's take a look at the relevant knowledge about java.net.SocketException.

The first exception is java.net.BindException:Address already in use: JVM_Bind.

This exception occurs when the server performs a new ServerSocket (port) (port is an integer value of 0meme65536). The reason for the exception is that a port like port has been started and listened. At this point, with the netstat-an command, you can see a port in the Listending state. Just find a port that is not occupied to solve this problem.

The second exception is java.net.SocketException: Connection refused: connect.

This exception occurs when the client performs a new Socket (ip, port) operation. The exception occurs because either the machine with the ip address cannot be found (that is, the machine does not exist from the current machine to the specified ip route), or the ip exists but the specified port cannot be found to listen. When this problem occurs, first check whether the ip and port of the client are written incorrectly. If it is correct, check from the client ping to see if the server can communicate with ping. If you can ping it (if ping is disabled on the server side, you need another way), then see whether the program listening on the specified port on the server side is started. This will definitely solve this problem.

The third exception is java.net.SocketException: Socket is closed

This exception can occur on both the client and the server. The reason for the exception is that the user actively closes the connection (the close method of Socket is called) and then reads and writes the network connection.

The fourth 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. There are two reasons for the exception. * is that if the Socket on one side is closed (either actively or because of the exception exit), the other end still sends data, and the * packets sent raise the exception (Connect reset by peer). The other side exits, but does not close the connection when it exits, and the other end throws the exception (Connection reset) if it reads data from the connection. To put it simply, it is caused by the read and write operations after the connection is disconnected.

The fifth exception is java.net.SocketException: Broken pipe.

This exception can occur on both the client and the server. In the case of the fourth exception (that is, after SocketExcepton:Connect reset by peer:Socket write error is thrown), if you continue to write data, the exception is thrown. The solution to the first two exceptions is to ensure that all network connections are closed before the program exits, and then to detect the closing operation of the other party and to close the connection himself after finding that the other party closes the connection.

Problems that should be paid attention to when writing network programs

The first problem is to correctly distinguish between long and short connections. The so-called long connection is maintained as soon as it is established. Short connection is to prepare data-> establish a connection-> send data-> close a connection in the following scenarios. Many programmers have been writing network programs for many years, but they don't know what a long connection is and what a short connection is.

The second problem is the maintenance of long connections. The so-called maintenance includes two aspects, the first is to detect the other party's active disconnection (both calling the close method of Socket), and the second is to detect the other party's downtime, abnormal exit and network failure. This is a robust communication program must have. It is very simple to detect the other party's active disconnection. The main party is actively disconnected, and if the other party is doing a read operation, the return value is only-1. Once the other party is disconnected, it should actively close its own connection (call the close method of Socket).

The common method to detect each other's downtime, abnormal exit and unusual network is to use "heartbeat", that is, both sides send data to each other periodically and receive "heartbeat" from each other at the same time. If you do not receive the heartbeat of the other party for several consecutive cycles, you can judge that the other party is either down or abnormal or the network is not connected, and you also need to take the initiative to close your own connection. In the case of a client, the connection can be reinitiated after a certain delay. Although Socket has a keep alive option to maintain the connection, it usually takes two hours to discover the other party's downtime, abnormal exit, and network failure.

The third problem is the efficiency of handling. Whether it is the client or the server, if it is a long connection, a program needs at least two threads, one for receiving data, one for sending heartbeats, and no special thread for writing data. Of course, another kind of thread (commonly known as worker thread) is needed for message processing, that is to say, the receiving thread is only responsible for receiving data, and then distributing it to Worker for data processing. If it is a short connection, there is no need for a thread to send a heartbeat, and if it is a server, a special thread is required to listen for connection requests. These are the overall requirements of a communication program, how to design your program depends on your own design level.

The above is the solution to the four major java.net.SocketException anomalies shared by the editor. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report