I have a java.nio.channels.ServerSocketChannel which I initialised as follows:
while(true)
{
ServerSocketChannel channel = ServerSocketChannel.open();
InetSocketAddress serverSocket = new InetSocketAddress(host,port);
channel.bind(serverSocket);
SocketChannel ch = channel.accept();
// Later on when I have read off data from a client, I want to shut this
// connection down and restart listening.
channel.socket().close(); //Just trying to close the associated socket
// too because earlier approaches failed
channel.close();
}
When I send the first message from client it is successfully delivered to server and the client program exits. Then trouble begins. When I initialise the client again and try to
establish at the same port and address of the server as I did the first time, I get a
java.net.BindException: Address already in use: connect
exception even though I closed the associated channel/socket.
I have been renewing the ServerSocketChannel and InetSocketAddressobjects because as my client instance has to shut down after a write, I have to disengage that channel and since I cannot reuse a channel after it has been closed, I have to make a new object everytime. My theory is since the channel reference is reassigned each time, the orphaned object becomes GC meat, but since the close() method apparently is not working properly, the channel is still alive and until GC collects it my port will be hogged.
Nevertheless I tried keeping the initialisation of ServerSocketChannel and InetSocketAddress objects before the while loop, but this did not help, and the same exception occurred after the first write, as before.
ServerSocketChannel channel = ServerSocketChannel.open();
InetSocketAddress serverSocket = new InetSocketAddress(host,port);
channel.bind(serverSocket);
while (true)
{
SocketChannel ch = channel.accept();
//read from a client
}
For clarity , here is how I connect from the client:
SocketChannel ch=SocketChannel.open();
ch.bind(new InetSocketAddress("localhost", 8077));
InetSocketAddress address=new InetSocketAddress("localhost",8079);
//the address and port of the server
System.out.print(ch.connect(address));
ByteBuffer buf=ByteBuffer.allocate(48);
buf.clear();
buf.put("Hellooooooooooooooooooooooooo".getBytes());
buf.flip();
while(buf.hasRemaining()) {
ch.write(buf);
}
ch.close();
It looks like you're confusing client and server. Normally, server starts only once and binds to s port. Usually, there's no need to close there anything as the port gets freed when the program exits. Obviously, you must close the Sockets obtained by ServerSocket.accept(), but that's another story.
I guess you've got confused by your variable names (just like it happened to me as I started with this). Try to call all things according to their type, here was Hungarian really helpful for me.
The code I wrote for testing this is long, stupid, and boring. But it seems to work.
It may also be helpful to do:
channel.setOption(StandardSocketOptions.SO_REUSEADDR, true);
Search for information about this option to learn more.
do ch.close() as well to GC the client socket.
Related
We are using a DatagramSocket to send messages over UDP. Currently we use the following code.
private void doSend() throws IOException, SocketException {
try (DatagramSocket clientSocket = new DatagramSocket()) {
byte[] messageBytes = message.getBytes(Charset.forName("UTF-8"));
DatagramPacket sendPacket = new DatagramPacket(messageBytes, messageBytes.length, address,
port);
clientSocket.send(sendPacket);
}
}
As you can see we re-create the DatagramSocket for each message. For performance reasons we are considering creating the socket only once instead of for each message. The code lives in a long lived object so this would mean the socket is alive for several days.
My question is whether the DatagramSocket can become invalid through some error and must be re-created or if we can simply create the socket one time and be done with it? If it can become invalid and must be re-created, how can we detect that?
The only things that invalidate a DatagramSocket are:
Closing it. Using it in this state will cause a SocketException: socket closed.
A bind failure. Using it in this state will probably cause a default bind() to happen, to 0.0.0.0:0, which will yield a system-allocated port, which may not be what you want.
Connecting it to an invalid address, in which case sends may fail and receives will do nothing: you can recover from that via disconnect().
I have following Socket server's code that reads stream from connected Socket.
try
{
ObjectInputStream in = new ObjectInputStream(client.getInputStream());
int count = 10;
while(count>0)
{
String msg = in.readObject().toString(); //Stucks here if this client is lost.
System.out.println("Client Says : "+msg);
count--;
}
in.close();
client.close();
}
catch(Exception ex)
{
ex.printStackTrace();
}
And I have a Client program, that connects with this server, sends some string every second for 10 times, and server reads from the socket for 10 times and prints the message, but if in between I kill the Client program, the Server freezes in between instead of throwing any exception or anything.
How can I detect this freeze condition? and make this loop iterate infinitely and print whatever client sends until connection is active and stable?
The problem is that the server side of the socket has no way of knowing that the client connection closed because the client code terminates without calling .close() on the client side of the socket, and therefore never sends the TCP FIN signal.
One possible way of fixing this would be to create a new Watcher thread that just periodically inspects the socket to see if it is still active. The problem with that approach is that the isConnected() on the Socket will not work for the same reason stated above so the only real way to inspect the connection is to attempt to write to it. However, this may cause random garbage to be sent to a potentially listening client.
Other options would be to implement some type of keep-alive protocol that the client should agree to (i.e., send keep-alive bits every so often so the Watcher has something to look for). You could also just move to the java.nio approach, which I believe does a better job at dealing with these conditions.
This thread is old, but provides more detail: http://www.velocityreviews.com/forums/t541628-sockets-checking-for-dropped-connections-and-close.html.
what will happen to the serversocket in my app when I suddenly change the wifi network? I guess it will shut down since my device will get a new IP, at least in TCP, is the UDP MulticastSocket prone to this as well? And how to end the previous Server socket thread and start a new one when the network changes? One solution is using time outs, another is using a flag that will indicate whether the infinite loop should end or not but since listening to a socket is a blocking function it will produce an exception/error anyways.
Any thoughts will be appreciated! :)
EDIT: sample of my server thread.
ServerSocket ss = new ServerSocket(4445);
while(true){
Socket socket = ss.accept();
ObjectInputStream in = new ObjectInputStream(socket.getInputStream());
Object obj = in.readObject();
Log.i("TAG", "Received: " + obj.toString());
in.close();
socket.close();
}
TCPIP connection will break. So client would have to connect again.
UDP will be ok provided your IP does not change after reconnection. Of course if you transmit UDP its not going to make a difference for that machine.
You should get an exception in case of TCPIP which you can handle.
UDP sockets that are not bound to the address will remain open, as they are stateless. TCP listening sockets not bound to the address will remain open as well.
Conntected TCP sockets may be severed (RST) or just linger until a timeout hits.
It is a little known fact that IP mandates it that a device by default will accept packets directed to any address it has configured on any interface, no matter on which interface the packet arrives. If this were not so, routing would be broken. One can use packet filters to filter out packets with non-matching addresses depending on the interface.
Before I post this I looked at some past questions on this exceptions but couldn't find an exact answar.
I have a client server app which is basically a socket program connects with TCP.
I got this Exceptions from client side after it runs fine for some time. But still, the client is sending data to the server even though it throws Exceptions.( may be as Event objects are passed continuously). But the server works fine as it receives the data. The Exception I get from the client side while sending data is
java.io.IOException: stream active .. This occurs from the "LINE 01" as mentioned in the code below.
Here is the client code I used.
// And "Event" objects are passed continuously to this method one by one.
SocketChannel socketChannel = null;
try {
socketChannel = SocketChannel.open(new InetSocketAddress(host, port));
oos = new ObjectOutputStream(socketChannel.socket().getOutputStream());
oos.reset(); -----------> LINE 01
oos.writeObject(event);
} catch (IOException e) {
throw new RuntimeException(e);
}
Here is the server code
ServerSocketChannel serverSocketChannel = null;
try {
serverSocketChannel = ServerSocketChannel.open();
serverSocketChannel.socket().bind(new InetSocketAddress(port));
SocketChannel socket = serverSocketChannel.accept();
ObjectInputStream ois = new ObjectInputStream(socket.socket().getInputStream());
do {
Object object = ois.readObject();
if(object instanceof Event) {
Event event = (Event)object ;
viewDetailsInUI(event);
}
} while (true);
Here is the stack trace I got from the client side.
java.io.IOException: stream active
at java.io.ObjectOutputStream.reset(ObjectOutputStream.java:478)
at org.demo.siddhi.server.EventSenderClient.sendEventToSubscriber(EventSenderClient.java:42)
at org.demo.siddhi.server.query.types.SimpleStockQuoteVWAPQueryProvider$3.callBack(SimpleStockQuoteVWAPQueryProvider.java:344)
at org.siddhi.core.OutputStreamHandler.run(OutputStreamHandler.java:61)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Can anyone please explain why is this ?
There are several problems here.
As Peter Lawrey has pointed out, calling reset() immediately you have constructed the ObjectOutputStream is completely pointless, and probably illegal. Remove it.
You are using SocketChannels in blocking mode via streams, i.e. you are just using the underlying Sockets in both cases. You would be much better off using a Socket and a ServerSocket. It's a lot simpler and clearer.
Your server loops reading an ObjectInputStream for multiple objects, but your client creates a new connection, sends one object, and then (I hope) closes it. These do not add up. Either your client should conserve the TCP connection and the ObjectOutputStream and use it to write multiple objects, in which case you may need to call reset() after writeObject(), and the server needs to break out of the loop when it gets EOFException, or your server can close its connection after reading one object, and the while (true) loop is unnecessary.
It appears to believe it is serializing an object already.
IOException if reset() is invoked while serializing an object.
You don't need to call reset() at the start as there is nothing to reset(). I would drop it and it may work fine.
If you want to call reset regularly, you can call it after writeObject().
You should also call flush() somewhere as the stream is buffered.
Look to OOS code:
493 if (depth != 0) {
494 throw new IOException("stream active");
495 }
I create a new thread that runs the following code:
public static void startServer() throws IOException {
serverSocket = new ServerSocket(55000);
Socket clientSocket = serverSocket.accept();
}
The above code is run in a thread. Now, in my main class, I successfully create a socket
connection to the server and I have checked it's integrity which is fine. here is the code:
Socket testServerSocket = new Socket("127.0.0.1", 55000);
assertEquals("/127.0.0.1", testServerSocket.getInetAddress().toString());
assertEquals(55000, testServerSocket.getPort());
This runs perfect. Then, again from my main, I kill the server connection that closes the connection on the server side. However the following code keeps failing:
assertEquals(false, testServerSocket.isBound());
It keeps returning true. Likewise, if I check the remote IP address for the connection, it doesn't return null, but rather '/127.0.0.1'. Any ideas why this might be happening? Many thanks for your help
I'm not an expert on sockets (I know what they are, but haven't ever used sockets on Java, only with C on Linux), but like JavaDoc for java.net.Socket states, 'A socket is an endpoint for communication between two machines'. So while closing server-side socket does destroy the connection between the two sockets (server- and client-side), your client-side socket is still bound, hence the isBound() is returning true. Maybe you meant to call isConnected() or isClosed()?