Need onClose event if internet connection turned off or interrupted

[timmolter]

Hi, I'm writing in regards to an inquiry on XChange here: knowm/XChange#109

Does Java-websockets have any internal mechanism to detect when the Interent connection goes down? Perhaps with a timeout parameter?

At XChange, we already have a way to reconnect, but it relies on receiving an onClose message from Java-Websockets.

Any idea how we can deal with this? Thanks in advance!

[Davidiusdadi]

The websocket protocol is build on top of tcp/ip . And if tcp says the connection is broken than that is an accomplished fact. You are either connected or not and thats all Java-Websockts can know.

The websocket protocol is a very minimalistic one - and except playing with some tcp/ip timeouts there is no elegant way to get the network error tolerance you desire without altering client AND server and therefore the protocol itself!

Just like you already do you can get the desired features by reconnecting which evolves storing your own extra connection/transaction information on a higher logical layer.

The only suggestion i have is:
Treat my beloved websocket objects as the unreliable throwaway objects that they( and all network-resource-handle-like objects ) are and do not store informations in them that you still need if your connection gets interrupted once more. In the design i would clearly distinguish between the lowlevel Java-Websocket connection object and your own high level connection object.

Finally i would just like to remark that clients can go offline for real without a way of reconnecting and even the coolest business api has to confess that to its user at some point. :D

[Sikerdebaard]

Davidiusdadi, in this case, with XChange, it seems that Java-WebSockets uses java.nio.SocketChannel in such a way that it blocks indefinitely on a read when, for example, the network cable is disconnected. It NEVER times out and in no way a signal from Java-WebSockets is generated that tells us the TCP/IP connection is actually destroyed. It just hangs indefinitely. A solution for the problem is a wrapper as discussed in this article. You can find some diff-files that implement this as an ugly quick fix in this issue: knowm/XChange#109
If you'd like I can see if I can send in a pull request that fixes this issue somewhere this weekend.

[timmolter]

@Davidiusdadi Thanks for getting back to us on this issue. I understand and agree that Java-websockets should just be unreliable throwaway objects, and that clients should have a higher-level logic to handle reconnects and such.

However, it would make implementing that higher-level logic much much easier, if there was a way to give java-websockets a timeout param. This would be a nice feature of the library. Perhaps the default could be infinite timeout as it is now, but it could be overridden/specified as @Sikerdebaard demonstrates. Adding this feature would be quite easy, it would help clients out tremendously, and it wouldn't make the library worse in anyway, as far as I can tell.

What do you think about that??

Cheers, Tim

[Davidiusdadi]

If physically disconnecting the form the network does not close all open connection in the software there is a bug in some immediate layer like the network library. The underlying api (provided by e.g. android) must always be able to tell whether a connection is open or not - that is e.g. what tcp/ip keepalive is for.

Its not the job of application layer software to verify if a tcp connection is still open. Timeouts are a dirty hack.

---

@Sikerdebaard i would like to know your approach on implementing timeouts.

Before using Channels.newChannel we have to make sure that it does not create new threads but even if it does not i dislike the idea of mixing old and new IO...
My way to implement timeouts would be by implementing it directly into the selectorthread - maybe a separate timeout thread would be evolved... BUT only if there are good reasons for a implementing a timeout at all.

---

On which platforms do some connections never get closed?

[Sikerdebaard]

@Davidiusdadi

Thanks for your reply, I'm sorry for not replying earlier. There was some personal stuff going on within my family.

As explained by the article:
"The only difference between “blocking NIO” and “NIO wrapped around IO” is that you can’t use socket timeout with SocketChannels. Why ? Read a javadoc for setSocketTimeout(). It says that this timeout is used only by streams. However, you can use a trick to make it working".

If we believe what is said in the article and the Javadocs, this blocking problem is not a bug or a platform limitation, it is the way it is supposed to work in Java and therefore we should assume that this problem exists on all platforms. This behavior makes sense though, as by my experience a recv-call on a native socket in C or C++ on Linux will block indefinitely under these same circumstances. The only way to prevent this is by setting a SO_RCVTIMEOUT and using select(..). This behavior kind of resembles the Java behavior, although it is on a lower level, and it is higly likely that this limitation within Java is because of the same limitation within C++ as the Oracle HotSpot VM is written within C++.

Due to this problem being a limitation of Java, we, the developers, have to find a way around this as it is very unlikely that Oracle will change this behavior. A solution would be an extra thread that monitors the sockets as you proposed yourself but you seem to dislike this option as it requires a bit of extra resources. The other solution is to use the Channels.newChannel method as discussed in the article. I agree that mixing old and new IO is a bit dirty, but since the new IO does not seem to have logic for handling this issue and since Java-WebSocket basically only uses the in the article proposed fix for in and output streams I think the damage is manageable. The API for both versions seems to be almost the same for this particular part. If this 'mixing old and new'-method uses additional threads is something to investigate. A quick google search does not yield results on this subject.

All in all, I hope it is possible to find a solution for this problem as currently the developers that use the Java-WebSocket library have to write additional code to monitor all of the used websockets as this situation often occurs on for example Android phones on 2G/3G or when walking around an office building with multiple wireless APs.

[perumal]

@Sikerdebaard

Please let me know if you have found any solution to this problem.

I have got this library working but facing the same problem on 2G/3G network.

Apart from this I have a very basic doubt.
If webscokets are suppose to be full duplex communication mechanism, then why does this particular websocket library depends on PING PONG mechanism for keeping the connection alive.
I am new to websockets, any kind of explanation on this will be greatly appreciable.

[marci4]

Closing this issue.
Will be released with 1.3.4

See #473