Develop Reference

Android socket connects but cant write to it

I was trying to get some networking going in my app, but i encountered some issues. It seems that I cant write to the OutputStream object. Though my server recieves the connection, it does not recieve any data. I've tried using Writer, DataOutputStream among others. none seemed to work.
My app uses asynctasks that call this object with a Socket object and a message. (The socket object has already been used to set Streams after initialisation using the setStreams method.)
can someone please try and find the problem? I will be very thankful.
public class NetworkingUtils {
private OutputStream out = null;
private InputStream in = null;
//set streams
public void setStreams(Socket sock){
if (sock.isConnected()) {
try {
this.out = (OutputStream) sock.getOutputStream();
this.in = (InputStream) sock.getInputStream();
} catch (Throwable e) {
Log.d("SOCKET", "FAILED TO SET STREAMS");
e.printStackTrace();
}
}
}
//send \n terminated messages to pre defined socket
public void sendMessage(Socket sock, String message) throws Throwable {
if (sock.isConnected()) {
try {
this.out.write(message.getBytes());
Log.d("SOCKET","WRITING COMPLETE. " + message);
} catch (Throwable e) {
throw e;
}
}
}
public String recvMessage(Socket sock) throws Throwable {
//receives \n terminated message from pre defined socket
String answer = null;
if (sock.isConnected()){
try{
answer = this.convertStreamToString(this.in);
Log.d("SOCKET","READING COMPLETE");
}
catch (Throwable e){
Log.d("socket",e.getLocalizedMessage());
throw e;
}
}
else{
Log.d("socket","is not connected!!!");
}
if (answer.length() == 0){
//empty string answer from server
throw new IOException();
}
else {
return answer;
}
}
private String convertStreamToString(java.io.InputStream is) {
java.util.Scanner s = null;
try{
s = new java.util.Scanner(is).useDelimiter("\r\n");}
catch (Throwable e){
e.printStackTrace();
}
return s.hasNext() ? s.next() : "";
}
}

I can only see one client-side that might cause this ... and I'm doubtful about it. (That is to say: try this, just in case it makes a differences, but I don't think it will.)
this.out.write(message.getBytes());
Log.d("SOCKET","WRITING COMPLETE. " + message);
The potential problem is that if out is a "buffered" stream, then a write may only result in the bytes being written to the buffer. It may be necessary to call this.out.flush() to "push" to the server.
But I am doubtful it will help, because (to my knowledge) a socket output stream isn't buffered in Java. I think it is more likely that the real problem is on the server side.
If you are stumped with figuring out which side the problem is occuring, I suggest you try using a network monitoring / packet sniffing tool (on the server side) to check if the data is reaching the server host.
While I have your attention, your exception code is really, really bad.
Don't declare methods as throws Throwable (or throws Exception). That basically says "this method may throw ANY exception, and I'm not telling you which one". When you do that, the caller code has to cope with any exception, which is basically impossible to do intelligently.
What you should do is to declare the method as throwing the checked exceptions that the code can throw. For example, in your case, IOException is probably sufficient.
It is not a good idea to catch an exception, log it, and then rethrow it. Why? Because further up the stack there are probably other methods that will see the exception. They can't know if the exception has already been logged or not. So should they log it (possibly resulting in duplicate logs events for the same problem) or not (possibly resulting in the exception going unlogged.)
Don't throw exceptions without a message:
throw new IOException();
It is lazy. You should always include a simple message that can (at least) be grep'd or googled for.
In addition, your testing of Socket.isConnected() all over the place is unnecessary. According to the javadoc:
Returns: true if the socket was successfuly connected to a server
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.
So repeatedly testing isConnected is nugatory. If it returns true once, it will will always return true from then on.
Even the initial isConnected test in setStreams is doubtful. I'd just call getInputStream without testing, and rely on the Socket API throwing an IOException if the socket is in the wrong state.

You're effectively reading lines with that obscure Scanner usage, but you're not writing lines. So the scanner will block until a line terminator or EOS arrives.
You need to append a line terminator when sending.

How do I catch the SocketTimeoutException

Say I have a socket variable called SuperSocket is there any way that I can catch the timeout exception ?
SuperSocket.setSoTimeout(5000);
catch (SocketTimeoutException e){
System.out.println("Timeout");
System.exit(1);
}

You seem to not understand what setSoTimeout() does and when that exception would be thrown.
From the Javadoc: ( http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html )
public void setSoTimeout(int timeout)
throws SocketException
Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds.
With this option set to a non-zero timeout, a read() call on the
InputStream associated with this Socket will block for only this
amount of time. If the timeout expires, a
java.net.SocketTimeoutException is raised, though the Socket is still
valid. The option must be enabled prior to entering the blocking
operation to have effect. The timeout must be > 0. A timeout of zero
is interpreted as an infinite timeout.
The only time a SocketTimeoutException can be thrown (and then caught) is when you're doing a blocking read on the Socket's underlying InputStream and no data is received in the specified time (causing the read to ... time out).
superSocket.setSoTimeout(5000);
InputStream is = superSocket.getInputStream();
int i;
try {
i = is.read();
} catch (SocketTimeoutException ste) {
System.out.println("I timed out!");
}
Edit to add: There's actually one other time the exception can be thrown, and that's if you're calling the two argument version of Socket.connect() where you supply a timeout.

Interrupt/stop thread with socket I/O blocking operation

At some point of my server application I want to stop some threads that are performing I/O blocking operations.
For instance, one of them have the following run() method:
public void run() {
System.out.println("GWsocket thread running");
int len;
byte [] buffer = new byte[1500];
try {
this.in = new DataInputStream(this.socket.getInputStream());
this.out = new DataOutputStream(this.socket.getOutputStream());
running = true;
while (running){
len = in.read (buffer);
if (len < 0)
running = false;
else
parsepacket (buffer, len);
}
}catch (IOException ex) {
System.out.println("GWsocket catch IOException: "+ex);
}finally{
try {
System.out.println("Closing GWsocket");
fireSocketClosure();
in.close();
out.close();
socket.close();
}catch (IOException ex) {
System.out.println("GWsocket finally IOException: "+ex);
}
}
}
If I Want to stop a thread running this code, what should I do?
Here they show how to do (How do I stop a thread that waits for long periods (e.g., for input)?), but I don't understand what they mean with:
For this technique to work, it's critical that any method that catches
an interrupt exception and is not prepared to deal with it immediately
reasserts the exception. We say reasserts rather than rethrows,
because it is not always possible to rethrow the exception. If the
method that catches the InterruptedException is not declared to throw
this (checked) exception, then it should "reinterrupt itself" with the
following incantation: Thread.currentThread().interrupt();
Can anyone give me some hints? Some code examples would be very appreciated.

A solution, described by Peter Lawrey and also seen here is to close the socket.
With nio, You could also use a SocketChannel which is interruptible and would allow the application of the standard interrupt model of Java.
A call to the interrupt method of your Thread object would throw an InterruptedException which would stop even your blocking IO operation.

You can add a method like
public void close() throws IOException {
this.socket.close();
}
and any blocking IO operations will throw a SocketException.
You might like to set a flag like closed which you can check if an exception thrown was to be expected or not.
BTW: You cannot be sure that you will get discrete packets on a read. It is far better to read what you need and use BufferedInputStream for efficiency. Only read blocks if you don't need to parse the contents e.g. copying from a socket to a file.
e.g. your read could get just one byte or get the end of one packet and the start of another.

Killing a thread after socket closed

I wanna kill the TCP connection listener thread(serverside) after client closes the socket..
The thread waits in the loop in the readLine()..
How can i do it?
while(isconnected){
String msg = in.readLine();
//..
}

You have to call socket.close() method, if you are using it properly it should be fine. I don't know where readLine() is coming from, so I will assume its BufferedReader. If you look here in the documentation BufferedReader readLine()
you will see that it throws IOException if there is an error and if it is end of stream it will return null.
so you should basically do this:
try{
while(socket.isConnected()){
String line = in.readLine();
if(line==null){
//END OF STREAM
}
}
}catch(IOException e){
//deal with IOException here
}
otherwise, what I assume your currently doing is sitting in a tight loop as soon as the other end disconnects. If you try too print out msg in your above code you will see it print out null nonstop.

Perhaps extend your protocol so that the client sends a QUIT message before closing its socket.

First, you can't tell if the client is just taking a long time to respond, or if it is down.
What you can do is set some timeout period and have a thread in the server that calls clientSocket.close() after the timeout has elapsed. This will throw a SocketException in the receiving thread. It will take you out of the receiving loop and the thread will just terminate by itself if there is nothing after the receiving loop.

WalterM is basically right. The readLine call will return null is the stream is closed by the remote client, and will throw an exception if the connection "breaks" without a proper close, or the low-level socket read times out.
It is worth pointing out that it is simpler and more efficient to just do this:
try {
String msg;
while ((msg = in.readLine()) != null) {
// do stuff
}
} catch (IOException ex)
// report error
} finally {
// Close the socket under all circumstances to avoid potential
// resource leakage
try {
socket.close();
} catch (IOException ex) {
// ignore
}
}
Checking that the socket is still connected it redundant. The low-level socket read will be doing that anyway.

You'll need to interrupt the thread.

Checking if a ClientSocket has disconnected in java hangs

This is a follow up to:
this question
Basically, I have a server loop that manages a connection to one solitary client. At one point in the loop, if a ClientSocket exists it attempts a read to check if the client is still connected:
if (bufferedReader.read() == -1) {
logger.info("CONNECTION TERMINATED!");
clientSocket.close();
setUpSocket(); // sets up the server to reconnect to the client
} else {
sendHeartBeat(); // Send a heartbeat to the client
}
The problem is, that once a socket has been created the application will hang on the read, I assume waiting for data that will never come, since the client never sends to the server. Before this was OK, because this correctly handled disconnects (the read would eventually fail when the client disconnected) and the loop would attempt reestablish the connection. However, I now have added the above sendHeartBeat() method, which periodically lets the client know the server is still up. If the read is holding the thread then the heartbeats never happen!
So, I assume I am testing if the connection is still up incorrectly. I could, as a quick hack, run the bufferedReader.read() in a seperate thread, but then I'll have all sorts of concurrency issues that I really don't want to deal with.
So the question is a few fold:
Am I checking for a client disconnect correctly?
If not, how should I do it?
If I am doing it correctly how I do I get the read to not hold the process hostage? Or is threading the only way?

When you create your socket, first set a timeout:
private int timeout = 10000;
private int maxTimeout = 25000;
clientSocket.setSoTimeout(timeout);
With this, if a read times out you'll get java.net.SocketTimeoutException (which you have to catch). Thus, you could do something like this, assuming you've previously set the SO_TIMEOUT as shown above, and assuming that the heartbeat will always get a response from the remote system:
volatile long lastReadTime;
try {
bufferedReader.read();
lastReadTime = System.currentTimeMillis();
} catch (SocketTimeoutException e) {
if (!isConnectionAlive()) {
logger.info("CONNECTION TERMINATED!");
clientSocket.close();
setUpSocket(); //sets up the server to reconnect to the client
} else {
sendHeartBeat(); //Send a heartbeat to the client
}
}
public boolean isConnectionAlive() {
return System.currentTimeMillis() - lastReadTime < maxTimeout;
}
A common way of handling this is setting the timeout to some number (say 10 seconds) and then keeping track of the last time you successfully read from the socket. If 2.5 times your timeout have elapsed, then give up on the client and close the socket (thus sending a FIN packet to the other side, just in case).
If the heartbeat will not get any response from the remote system, but is just a way of ultimately generating an IOException earlier when the connection has fallen down, then you could do this (assuming that the sendHeartBeat itself will not throw an IOException):
try {
if (bufferedReader.read() == -1) {
logger.info("CONNECTION TERMINATED with EOF!");
resetConnection();
}
} catch (SocketTimeoutException e) {
// This just means our read timed out ... the socket is still good
sendHeartBeat(); //Send a heartbeat to the client
} catch (IOException e) {
logger.info("CONNECTION TERMINATED with Exception " + e.getMessage());
resetConnection();
}
....
private void resetConnection() {
clientSocket.close();
setUpSocket(); //sets up the server to reconnect to the client
}

You are checking correctly, you can should add a try catch with IOException in case it occurs.
There is a way to avoid threading, you can use a Selector with a non-bloking socket.
public void initialize(){
//create selector
Selector selector = Selector.open();
ServerSocketChannel acceptSocket = ServerSocketChannel.open();
acceptSocket.configureBlocking(false);
String bindIp = "127.0.0.1";
int bindPort = 80;
acceptSocket.socket().bind(new InetSocketAddress(bindIp, bindPort));
//register socket in selector for ACCEPT operation
acceptSocket.register(selector, SelectionKey.OP_ACCEPT);
this.selector = selector;
this.serverSocketChannel = serverSocketChannel;
}
public void serverStuff() {
selector.select(maxMillisecondsToWait);
Set<SelectionKey> selectedKeys = selector.selectedKeys();
if( selectedKeys.size() > 0 )
{
if( key.isAcceptable() ){
//you can accept a new connection
SocketChannel clientSk = serverSocketChannel.accept();
clientSk.configureBlocking(false);
//register your SocketChannel in the selector for READ operations
clientSk.register(selector, SelectionKey.OP_READ);
} else if( key.isReadable() ){
//you can read from your socket.
//it will return you -1 if the connection has been closed
}
}
if( shouldSendHeartBeat() ){
SendHeartBeat
}
}

You should add error checking in your disconnection detection. Sometimes an IOException may be thrown when the connection to the other end is lost.
I am afraid that threading is unavoidable here. If you don't want to block the execution of your code, you need to create a separate thread.