I'm getting different results while trying to read from a socket while the other socket is closed.
I have two sockets A and B.
1)B sent some data to A --> A has read the data --> A closes --> When B tries to read some data from A, it is getting -1(or EOF).
2)B sent some data to A --> A closes even before reading the data --> Now B tries to read from A, an exception is thrown(java.net.SocketException "Software caused connection abort.")
please excuse me, if you can't understand my question. Please see the code
Server.java
import java.io.*;
import java.net.*;
class SocketCloser extends Thread
{
private Socket c;
public SocketCloser(Socket c) {
this.c = c;
}
public void run() {
try{
this.c.close();
} catch (Exception e) {}
}
}
public class Server
{
public static void main(String argv[]) throws Exception {
ServerSocket listen = new ServerSocket(6789);
Socket socket = listen.accept();
SocketCloser sc = new SocketCloser(socket);
InputStream is = socket.getInputStream();
// uncomment below line to get "Software caused connection abort" on client
//sc.start();
try {
Thread.sleep(1000);
int i = is.read();
System.out.println("read returned: " + i);
socket.close();
} catch (Exception e) {
System.out.println(e.toString() + " thrown");
}
}
}
Client.java
import java.io.*;
import java.net.*;
public class Client
{
public static void main(String argv[])
{
Socket cSocket;
try {
cSocket = new Socket("localhost", 6789);
InputStream is = cSocket.getInputStream();
OutputStream os = cSocket.getOutputStream();
Thread.sleep(1000);
os.write(200);
Thread.sleep(1000);
int i = is.read();
System.out.println("read returned: " + i);
cSocket.close();
} catch (Exception e) {
System.out.println(e.toString() + " thrown");
}
}
}
Can someone please help me figure out why there is an exception in one case and -1 in another. Interestingly on linux both the cases resulted in -1.
1) Because B established a connection, A goes to CLOSE_WAIT. It will be in that state until B closes the connection. There is nothing to read, so the read() call on B's InputStream returns -1.
2) A is blocked in the accept call. The other thread is trying to close the socket, but it can't because accept is blocking it. When B connects, accept unblocks and the socket closes outright. When B tries to read, the socket is not there anymore so you get the exception.
I'm simplifying a bit, but that's the gist of it.
1)B sent some data to A --> A has read the data --> A closes --> When B tries to read some data from A, it is getting -1(or EOF).
I agree. What did you expect? This is the expected behaviour.
2)B sent some data to A --> A closes even before reading the data --> Now B tries to read from A, an exception is thrown(java.net.SocketException "Software caused connection abort.")
I agree. This is one of the expected behaviours in this incorrect situation. What did you expect?
please excuse me, if you can't understand my question.
There is no question here to understand. You haven't asked a question. You close a socket without sending any data and the peer gets EOS without receiving any data. You close a socket while the peer is sending and the peer gets an exception. System is working as designed.
Related
I have a client program that sends messages typed in console to the server. Following some advices, I introduced a check for a closed socket with Socket.checkError(). Nevertheless, for some reason it indicates error only after second failed attempt to send a message.
My code:
BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in));
while (true)
try (
Socket clientSocket = new Socket(hostname, port);
PrintWriter socketOut = new PrintWriter(clientSocket.getOutputStream(), true);
) {
String input;
while ((input=stdIn.readLine())!=null) {
socketOut.println(input);
if (socketOut.checkError()) {
System.out.println("Got socket error");
break;
}
}
} catch (IOException e) {
try {
Thread.sleep(5000);
} catch (InterruptedException e1) {}
}
I shut down (manually) my server side after receiving 'message1'. Therefore, I expect to get the error while trying to send the very next message. Nevertheless it occurs only one message after:
message1
message2
message3
Got socket error
Can anyone explain this behavior and advise me a method to get notification right on the first attempt to send a message in void?
Following some advices, I introduced a check for a closed socket with Socket.checkError().
There is no such method. Clearly you are referring to PrintWriter.checkError().
Nevertheless, for some reason it indicates error only after second failed attempt to send a message.
The reason is that there is both a socket send buffer at the sender and a socket receive buffer at the receiver, and that sending is asynchronous: it therefore isn't possible for the first send to detect an error.
Can anyone explain this behavior and advise me a method to get notification right on the first attempt to send a message in void?
There isn't one. That's the nature of TCP. What you are attempting indicates an application protocol error, and the answer lies in the realm of the application protocol as well: don't have the peer close the socket while this end could still be sending data, OR don't allow this end to send data after the peer has indicated, via the application protocol, that it won't be reading any more data.
Don't use PrintWriter over the network. It suppresses the actual exception. Use BufferedWriter and the write() and newLine() methods.
In ths java library there is no method to check if connection is opened or not. Method like isConnected() and isClosed() check only one side of the connection (where you invoked the method).
From javadoc:
Note: Closing a socket doesn't clear its connection state, which means
this method will return true for a closed socket (see isClosed()) if
it was successfuly connected prior to being closed.
To check if the connection has been really closed simply invoke the read() method (or equivalent) and check if it returns -1.
Note: also if isConnected will work as you like (giving false if the other side of the socket closed the connection or if there is a network problem or similar) the sequence:
if (socket.isConnected()) {
int x = socked.read();
}
will not grant that the x has a value different from -1 or throws an IOException, because the connection could be closed after the isConnected test and before the read operation.
The following code to show how any kind of check on the socket cannot guarantee that a subsequent read will give a valid result.
// Return true because socket communication is enabled
if (myFunctionToCheckIfSocketIsOpen(socket)) {
// Here the peer closed the socket or the network shutdown
// This read will give -1 or throws IOException also if the previous check returned true
int x = socket.read();
}
From the answer of #Davide Lorenzo MARINO I got the idea of employing read(). The only problem that it is blocking. However, one can always run it in another thread, which would modify a class global variable, when read() finally returns -1:
static boolean socketIsAlive;
...
BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in));
while (true)
try (
Socket clientSocket = new Socket(hostname, port);
PrintWriter socketOut = new PrintWriter(clientSocket.getOutputStream(), true);
) {
socketIsAlive=true;
new ConnectionChecker(clientSocket).start();
String input;
while (true) {
if ((input=stdIn.readLine())!=null)
socketOut.println(input);
if (!socketIsAlive) {
System.out.println("Got socket error");
break;
}
}
} catch (IOException e) {
try {
Thread.sleep(5000);
} catch (InterruptedException e1) {}
}
}
...
static public class ConnectionChecker extends Thread{
Socket socket;
public ConnectionChecker(Socket socket) {
this.socket=socket;
}
#Override
public void run() {
try {
if (socket.getInputStream().read()==-1)
socketIsAlive=false;
} catch (IOException e) {}
}
}
I'm trying to make a simple text editor which can be shared accross multiple terminals at the same time. I have a Server waiting for new users, when a user enters the shared editor it just starts waiting for input characters.
public class Server {
public static final int PORT = 8080;
public static void main(String[] args) throws IOException {
ServerSocket ss = new ServerSocket(PORT);
while (true) {
Socket socket = ss.accept();
System.out.println("A new user entered the sever");
new Thread(() -> serve(socket)).start();
}
}
private static void serve(Socket socket) {
try {
while (!socket.isClosed() && !socket.isInputShutdown()) {
System.out.println("hey " + socket.isClosed() + " " + socket.isInputShutdown());
System.out.print(new String(SocketUtil.receiveBytes(socket,1)));
}
} catch (IOException e) {
e.printStackTrace();
}
}
}
When a user closes the editor, the socket is closed on client side. However, the socket on the server side does not get closed and the server starts looping infinitly in the "wait for input" loop.
The Client is a singleton containing the following methods, called at the openning and closing of the editor.
public static void init() {
try {
if (socket == null) socket = new Socket(HOST,Server.PORT);
} catch (IOException e) {
e.printStackTrace();
kill();
throw new Error(e.getMessage());
}
}
public static void kill() {
Check.notNull(socket);
try {
SocketUtil.terminateCommunication(socket);
System.out.println(socket.isClosed());
} catch (IOException e) {
e.printStackTrace();
}
}
Finally, here are utilitary methods (in SocketUtil) used in both classes :
public static void terminateCommunication(Socket socket) throws IOException {
socket.shutdownInput();
socket.shutdownOutput();
socket.close();
}
public static char[] receiveBytes(Socket socket, int nBytes) throws IOException {
char[] bytes = new char[nBytes];
InputStreamReader isr = new InputStreamReader(socket.getInputStream());
isr.read(bytes);
return bytes;
}
Any idea of why the socket on server side is not closed after the Client gets killed ?
It is not quite clear from the Javadoc, but isClosed() only returns true when you have explicitly called close() on the socket (see the sources to confirm that). You should check for exceptions and the return value of read() instead. If you read -1 or catch an IOException while trying to read (or write, for that matter), it essentially means that the other side has closed the connection, so you should close your socket as well (better to it in a finally block) and you're done with that particular connection. You don't check for -1 in receiveBytes(), but you really should. Perhaps throw a EOFException() if you want to merge these two possibility into one, so that the code up the stack (in serve()) doesn't have to figure out what exactly happened:
public static char[] receiveBytes(Socket socket, int nBytes) throws IOException {
char[] bytes = new char[nBytes];
InputStreamReader isr = new InputStreamReader(socket.getInputStream());
if (isr.read(bytes) == -1)
throw new EOFException();
return bytes;
}
One exception from the IOException rule (sorry for the pun) is the SocketTimeoutException. If you get this, the connection is still alive, and you may just as well retry your read(). But I believe that in order to get these, you must call Socket.setSoTimeout() somewhere, and if you haven't, then you probably shouldn't worry about SocketTimeoutException.
You should also note that read() may sometimes return partial reads (that is, less than bytes.length). If it's important that receiveBytes() reads exactly nBytes (which probably is, since you never return the number of actual characters read), then you should call it in a loop, like this:
int pos = 0;
while (pos < bytes.length) {
int l;
if ((l = isr.read(bytes, pos, bytes.length - pos)) == -1) {
throw new EOFException();
}
pos += l;
}
I know this is cumbersome, which is exactly why many developers create utility methods like your receiveBytes().
The proper way to detect that the client has closed its connection is by checking the reception of 0 bytes.
System.out.print(new String(SocketUtil.receiveBytes(socket,1)));
just check if the string is empty should do the trick.
Note that I am not that familiar with java, but I do know socket programming.
Receiving 0 bytes, checking for that, and closing the socket if you do is a good solution.
You can use exception handling too, but you'll detect that the peer closed it socket an iteration later. Receiving 0 bytes is not really an error condition it is just a signal from the peer that he has closed its end of the socket and won't send anymore data. If you ignore this, and keep using the socket, you'll receive an exception in the next iteration because there is nothing to receive anymore.
This is driving me insane!
I'm trying to implement TCP holepunching and as part of this I have a socket trying to connect continuously.
For some reason, after the first mobileSocket2.connect call times out, the second time a socket closed exception comes up. I have no idea why. As far as I can tell, a connection timeout shouldn't close the socket. so why does it say socket closed the second loop?
I bind a socket to the same local IP address and local port earlier on but close that socket.
Any help would be greatly appreciated.
Socket mobileSocket2 = new Socket();
try {
System.out.println("105");
mobileSocket2.setReuseAddress(true);
System.out.println("109");
mobileSocket2.setSoTimeout(50);
mobileSocket2.bind(new InetSocketAddress(myIPAddress.getHostAddress(), myPort));
System.out.println("bound");
}
catch (Exception e) {
System.out.println("caught 104: " + e.toString());
}
while(true){
Thread.sleep(5000);
try{
System.out.println("124");
mobileSocket2.connect(new InetSocketAddress(mobileAddress.getHostAddress(), mobilePort));
System.out.println("connection made: " + mobileSocket);
}
catch(Exception e){
System.out.println("exception 2 caught " + e.toString());
}
}
Your code is invalid.
You can't reconnect a connected Socket. When the connect succeeds you need to add a break statement.
You can't reuse a Socket when a connect() has failed. You have to close it and create a new one.
Either reopen the socket when the first exception is caught, or set the timeout to 0, which the javadoc says it is interpreted as 'infinite'. I didn't look at the Socket and SocketImpl code, but I'm fairly confident that, since Socket is a Closeable (and also an AutoCloseable), the implementation is along the lines of
public void connect(InetAddress address, int port) throws IOException {
try {
// connect to the other endpoint
} catch(/*any relevant exception*/) {
throw new IOException(/* ... */);
} finally {
this.close();
}
}
I've created a client-server connection, something like a chat system. Previously I was using a while loop on the client side, and it was waiting to read a message from the console every time (of course server has a while loop as well to serve forever). But now, I'm trying to first create a connection at the beginning of the session, and then occasionally send a message during the session, so to maintain a permanent and persistent connection.
Currently, without the while loop, the client closes the connection and I don't know how to find a workaround.
Here is the client code:
import java.net.*;
import java.io.*;
public class ControlClientTest {
private Socket socket = null;
// private BufferedReader console = null;
private DataOutputStream streamOut = null;
public static void main(String args[]) throws InterruptedException {
ControlClientTest client = null;
String IP="127.0.0.1";
client = new ControlClientTest(IP, 5555);
}
public ControlClientTest(String serverName, int serverPort) throws InterruptedException {
System.out.println("Establishing connection. Please wait ...");
try {
socket = new Socket(serverName, serverPort);
System.out.println("Connected: " + socket);
start();
} catch (UnknownHostException uhe) {
System.out.println("Host unknown: " + uhe.getMessage());
} catch (IOException ioe) {
System.out.println("Unexpected exception: " + ioe.getMessage());
}
String line = "";
// while (!line.equals(".bye")) {
try {
Thread.sleep(1000);
//TODO get data from input
// line = console.readLine();
line="1";
if(line.equals("1"))
line="1,123";
streamOut.writeUTF(line);
streamOut.flush();
} catch (IOException ioe) {
System.out.println("Sending error: " + ioe.getMessage());
}
// }
}
public void start() throws IOException {
// console = new BufferedReader(new InputStreamReader(System.in));
streamOut = new DataOutputStream(socket.getOutputStream());
}
}
And here is the Server code:
import java.awt.*;
import java.io.*;
import java.net.ServerSocket;
import java.net.Socket;
public class ControlServer {
private Socket socket = null;
private ServerSocket server = null;
private DataInputStream streamIn = null;
public static void main(String args[]) {
ControlServer server = null;
server = new ControlServer(5555);
}
public ControlServer(int port) {
try {
System.out
.println("Binding to port " + port + ", please wait ...");
server = new ServerSocket(port);
System.out.println("Server started: " + server);
System.out.println("Waiting for a client ...");
socket = server.accept();
System.out.println("Client accepted: " + socket);
open();
boolean done = false;
while (!done) {
try {
String line = streamIn.readUTF();
// TODO get the data and do something
System.out.println(line);
done = line.equals(".bye");
} catch (IOException ioe) {
done = true;
}
}
close();
} catch (IOException ioe) {
System.out.println(ioe);
}
}
public void open() throws IOException {
streamIn = new DataInputStream(new BufferedInputStream(
socket.getInputStream()));
}
public void close() throws IOException {
if (socket != null)
socket.close();
if (streamIn != null)
streamIn.close();
}
}
I would like to summarize some good practices regarding the stability of TCP/IP connections which I apply on a daily basis.
Good practice 1 : Built-in Keep-Alive
socket.setKeepAlive(true);
It automatically sends a signal after a period of inactivity and checks for a reply. The keep-alive interval is operating system dependent though, and has some shortcomings. But all by all, it could improve the stability of your connection.
Good practice 2 : SoTimeout
Whenver you perform a read (or readUTF in your case), your thread will actually block forever. In my experience this is bad practice for the following reasons: It's difficult to close your application. Just calling socket.close() is dirty.
A clean solution, is a simple read time-out (e.g. 200ms). You can do this with the setSoTimeoutmethod. When the read() method timeouts it will throw a SocketTimeoutException. (which is a subclass of IOException).
socket.setSoTimeout(timeoutInterval);
Here is an example to implement the loop. Please note the shutdown condition. Just set it to true, and your thread will die peacefully.
while (!shutdown)
{
try
{
// some method that calls your read and parses the message.
code = readData();
if (code == null) continue;
}
catch (SocketTimeoutException ste)
{
// A SocketTimeoutExc. is a simple read timeout, just ignore it.
// other IOExceptions will not be stopped here.
}
}
Good practice 3 : Tcp No-Delay
Use the following setting when you are often interfacing small commands that need to be handled quickly.
try
{
socket.setTcpNoDelay(true);
}
catch (SocketException e)
{
}
Good practice 4 : A heartbeat
Actually there are a lot of side scenario's that are not covered yet.
One of them for example are server applications that are designed to only communicate with 1 client at a time. Sometimes they accept connections and even accept messages, but never reply to them.
Another one: sometimes when you lose your connection it actually can take a long time before your OS notices this. Possibly due to the shortcomings described in good practice 3, but also in more complex network situations (e.g. using RS232-To-Ethernet converters, VMware servers, etc) this happens often.
The solution here is to create a thread that sends a message every x seconds and then waits for a reply. (e.g. every 15 seconds). For this you need to create a second thread that just sends a message every 15 seconds. Secondly, you need to expand the code of good practice 2 a little bit.
try
{
code = readData();
if (code == null) continue;
lastRead = System.currentTimeMillis();
// whenever you receive the heart beat reply, just ignore it.
if (MSG_HEARTBEAT.equals(code)) continue;
// todo: handle other messages
}
catch (SocketTimeoutException ste)
{
// in a typical situation the soTimeout is about 200ms
// the heartbeat interval is usually a couple of seconds.
// and the heartbeat timeout interval a couple of seconds more.
if ((heartbeatTimeoutInterval > 0) &&
((System.currentTimeMillis() - lastRead) > heartbeatTimeoutInterval))
{
// no reply to heartbeat received.
// end the loop and perform a reconnect.
break;
}
}
You need to decide if your client or server should send the message. That decision is not so important. But e.g. if your client sends the message, then your client will need an additional thread to send the message. Your server should send a reply when it receives the message. When your client receives the answer, it should just continue (i.e. see code above). And both parties should check: "how long has it been?" in a very similar way.
You could wrap a thread around the connection and have it periodically send a status to keep the line open, say every 30 seconds or whatever. Then, when it actually has data to send it would reset the keep alive to be 30 seconds after the last transmission. The status could be helpful to see if the client is still alive anyway, so at least it can be a useful ping.
Also, you should change your server code, you appear to only handle one connection at the moment. You should loop and when a socket connection comes in spawn a thread to handle the client request and go back to listening. I may be reading to much into what may just be your test code, though.
Make the client socket connection wrapped around a thread. Use a blocking queue to wait for messages. There should only be a single sender queue throughout your application, so use a singleton pattern.
e.g.
QueueSingleton queue = QueueSingleton.getSenderQueue();
Message message = queue.take() // blocks thread
send(message); //send message to server
When you need to send a message to the server, you can use the blocking queue to send the message.
QueueSingleton queue = QueueSingleton.getSenderQueue();
queue.put(message)
The client thread will wake up and process the message.
For maintaining the connection, use a timer task. This is special type of thread that calls a run method repetitively at specified periods. You can use this to post a message, a ping message, every so often.
For processing the received message, you could have another thread, waiting for messages on another blocking queue (receiver queue). The client thread will put the received message on this queue.
I have a class implementing serversocket class and there is another class implementing the client 1. Socket class.
So what I am trying to do is that. After getting the streams I want client to send a number to server and server will in turn respond to client whether it's prime or not. Which is display in an awt.Label.
But I am not able to receive any response.
Here is the code for client's constructor:
public ClientIsPrime()
{
setLayout(new GridLayout(2,2));
add(new Label("Enter a number: "));
add(numEntry=new TextField(10));
add(checkPrime=new Button("Check if number is Prime"));
add(result=new Label("Result is shown here"));
try
{
Socket client = new Socket(InetAddress.getLocalHost(), 5959);
in=client.getInputStream();
out=client.getOutputStream();
}catch(UnknownHostException e)
{
result.setText("Local Host cannot be resolved");
}catch(IOException e)
{
result.setText("IOException occured");
}
checkPrime.addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent ae)
{
try
{
int num;
num=Integer.parseInt(numEntry.getText());
out.write(num);
out.flush();
int c;
result.setText("");
String s="";
while((c=in.read())!=-1)
s+=((char)c);
result.setText(s);
}catch(IOException e)
{
result.setText("IOException occured");
}catch(NumberFormatException e)
{
result.setText("Please enter a valid number.");
}
}
});
}
Code for Server:
public static void main(String args[])throws IOException
{
server=new ServerSocket(5959);
socket=server.accept();
System.out.println("connected");
InputStream in=socket.getInputStream();
OutputStream out=socket.getOutputStream();
int c; String numStr="";
while((c=in.read())!=-1)
numStr+=((char)c);
int num=Integer.parseInt(numStr);
if(num==3)
out.write("Number is Prime".getBytes());
else
out.write("Number is not Prime".getBytes());
out.flush();
in.close();
out.close();
}
It isn't a real app. I am learning.
A few problems.
First your server implementation will never exit the while loop. The API for InputStream.read() states that it will block until data is received or the stream is closed. The stream is never closed so the reading will block forever after reading the initial data.
To solve this problem you must decide what your protocol is. See below.
The other problem is that you are writing from the client as a parsed int of text. So say 13 (as an int). But you are then reading it as if it were a sequence of characters. 13 on the wire will be read as some control character. You need to be consistent with how you write data and read data.
My suggestion would be to have a basic protocol. Use DataOutputStream on the writing side and DataInputStream on the reading side and then match the read/write calls on both sides to ensure you are consistent.
If you want to sent integers across the wire it is infinitely easier to layer a DataOutputStream/DataInputStream on top of the raw socket streams and just do writeInt() and readInt()