Please correct me: Possible key points of the problem: A client only does accept() once and does not close the output stream
1. The client maintains a clientSocket instance (connect is called only once), and the server maintains a ServerSocket instance. Only maintaining one client socket and hoping for a second input processing seems to be preparing for long connections.
When the output stream is closed, the socket corresponding to the output stream will also be closed - "Crazy Java Lecture Notes (Third Edition)" p786
2. Let’s look down at the server. ss.accept() is placed in a loop, which is to handle multiple client connections; by the way, there is a read operation for each client, and there are no subsequent read operations, which may be the problem.
Short connection or long connection? For multiple communications that you want to have continuously, you can use one connection, read and write multiple times(long connection), or you can use multiple connections, read and write once per connection(short connection) What your client wants to do Long connection, the server seems wants to make a short connection. Suggestion:
Long connection: The client remains unchanged, and the server only performs accept() once for each client, processes multiple input communications in a loop, monitors the stream, but does not close the socket.
Short connection: Each time the client initiates a new socket connection (creates a new socket instance), each time the operation is completed, closes the stream and closes the socket. The server loop body remains unchanged, the stream is closed in the loop body, and the socket returned by accept() each time is closed. Because you don’t know your business, you don’t know the true intent of the code. Other points worth expanding on are:
Multi-client connections, multiple connections, session management, concurrency and more.
Please correct me:
Possible key points of the problem: A client only does accept() once and does not close the output stream
1. The client maintains a clientSocket instance (connect is called only once), and the server maintains a ServerSocket instance. Only maintaining one client socket and hoping for a second input processing seems to be preparing for long connections.
2. Let’s look down at the server. ss.accept() is placed in a loop, which is to handle multiple client connections; by the way, there is a read operation for each client, and there are no subsequent read operations, which may be the problem.
Short connection or long connection? For multiple communications that you want to have continuously, you can use one connection, read and write multiple times(long connection), or you can use multiple connections, read and write once per connection(short connection)
What your client wants to do Long connection, the server seems wants to make a short connection. Suggestion:
Long connection: The client remains unchanged, and the server only performs accept() once for each client, processes multiple input communications in a loop, monitors the stream, but does not close the socket.
Short connection: Each time the client initiates a new socket connection (creates a new socket instance), each time the operation is completed, closes the stream and closes the socket. The server loop body remains unchanged, the stream is closed in the loop body, and the socket returned by accept() each time is closed. Because you don’t know your business, you don’t know the true intent of the code. Other points worth expanding on are:
Multi-client connections, multiple connections, session management, concurrency and more.You can take a good look at your code. You close it every time in the while loop.