Develop Reference

Detect WebSocket connection closed

I'm using node.js and WebSocket-Node to build a simple chat websocket server.
The client is an Android app.
The server have to communicate with the clients in two way:
websocket message when the client is connected (app open in foreground)
Push notification using Google GCM else
But there is a little problem that i need to figure out..
When the client is connected to the server and the internet connection drops, the server is not notified about that because the client did not send the closing frame.. So for like 10 seconds, the server thinks that the connection is still alive.
If in those 10 seconds the server send the message over the socket.. the message can never reach the client.
I need to detect when the connection is closed, or another way to send the message using GCM when the connection it's closed.
Is there a way?

From the side of the server an unclean disconnect (no disconnect messages sent) is indistinguishable from a very slow connection.
What you need to do is have some sort of heartbeat. WebSockets has pings on the protocol level for this. If your library exposes this, then set the ping to a delay you are willing to accept, and add a handler for when this fails/doesn't complete after a timeout.

Answering my own question, because: It is not possibile, and I have found another better way to handle my specific case.
When the server send a message to the client, the client reply to the server, to let the server know that the message has been delivered to the client.
If the server do not receive the response from the client after a timeout, the connection is considered closed.
Proceed to send the message over GCM (or store it to be sent again when the client reconnect).

Jabber user going offline: Why the two different scenarios?

I have an Android client working in tandem with ejabberd XMPP server.
Observations:
Scenario 1: When I swipe-right the app (kill the app), the user goes offline on the server immediately. Its status is changed to offline at that very instant.
Scenario 2: However, when I simply shut-down the Wi-fi connectivity (data) of my Android Jabber client, there is a noticeable lag of a few minutes for the user to be marked offline on the server.
I can’t figure out what is the fundamental difference in the two processes.
What could be done in Scenario 2 to make it go offline immediately?

Scenario 1: When I swipe-right the app (kill the app), the user goes offline on the server immediately. Its status is changed to offline at that very instant.
In above case your Android xmpp client is sending presence as unavailable before closing your Android application, maybe your Android XMPP client is maintaining a background service which in turn maintains a persist XMPP connection (TCP socket) to XMPP server, when you close your application onDestroy() method of service will be called and in that one can check if XMPP connection is still connected. If yes then send presence as unavailable which will safely make user as offline on server and then disconnect XMPP connection (socket).
Scenario 2: However, when I simply shut-down the Wi-fi connectivity (data) of my Android Jabber client, there is a noticeable lag of a few minutes for the user to be marked offline on the server.
As I mentioned earlier, Android devices can maintain a persist XMPP connection in a service, when you turn off wifi and your XMPP connection (TCP socke) to server is still connected, there is no safe removal of user from XMPP server [client can't send presence as unavailable] means connection is just-hang up and Android client/XMPP server doesn't have knowledge of it. In such case now server will figure out client is hangup by client ideal time period [i.e there is no communication on socket for a fixed interval], and make user as offline. This process is time consuming so that you are seeing lag of a few minutes.
What could be done in Scenario 2 to make it go offline immediately?
You can configure XMPP server and make client
As this problem can be handled from XMPP client and server, from client you can fixed interval time ping, if you keep ping duration small enough you can detect lost connection (like broken pipe on socket), same way on server side if you keep ping inter [remember this is server to client ping] small you can detect loss of connection.
As I can see you are using ejabberd as your XMPP server, details given on this link says,
How to detect a dead connection?
One way to detect a dead connection is to ping the client periodically
and to kill the connection if the client doesn't respond. This can be
done using mod_ping. However, these ping packets might wake up the
client's radio, so a short ping interval might drain mobile batteries.
Therefore, it's not generally recommended to use an interval of less
than a few minutes. Either way, there's always some time window where
messages can be lost.

Android - How to know if a TCP connection is still opened

I'm doing an application that will comunicate with a TCP server. I based my work on the following example http://myandroidsolutions.funcode.ro/2013/03/31/android-tcp-connection-enhanced/.
Right now I'm looking how to verify if there is a connection between Client and Server. The mBufferOut.checkError() only give an error after 2/3 tries. I need to know if my message was sent or not.
Thank you

In network communications, you are never sure when (or if) the remote party received the message in full, in part, or at all.
If the connection is broken, then you know for certain that message was not received in full.
But if you need a timely confirmation, the server should send some confirmation message. Your application protocol needs to support this, though.
The same is valid to know if the connection is "up" or "down": TCP does not exchange any packets when idle, unless you activate keep-alive (which is not normally recommended). It may well happen that the party thinks it has a connection, only to send a message and then it fails (perhaps because a router was reset while the connection was idle).

To solve the problem we need to look at the return value of readLine(). If it return null so our tcp connection was closed.

Android socket stable communication

I am working on Android project which communicates over TCP/IP. Communication works on specific protocol - this protocol is message oriented.
android device sends message to server via socket
server sends answer message to android device
It is not problem but I have a few parlous questions.
I don't have any idea how to solve connection interrupts (wifi, edge, change wifi to edge over open socket, ...) and connection timeouts? If android device sends 1 message and in this moment are connection problems - then android device sends different message (other request) - it is guaranteed that answers will be delivered in correct sequence?
I tried set timeout for socket object but it didn't work. I dont know why but if I set timeout to 5 seconds and I turned off the server before I sent message - it took more than 5 second before she came exciption.
I didn't found any articles on internet about this problems.
Thank you very much.

For TCP sockets the way you can get timeouts is by using select() or poll(),in Android you have to use SocketChannel() (java.nio) class to deal with non-blocking sockets. They both can query a socket for a specific period (10 or 20 seconds for example) and can tell you if it is writeable (you can use send()) or readable (there is data to be read recv()). Also the select() command will tell you if the socket has an error, most probably a broken connection. When you get such an error (except an interrupted signal, this one should be ignored and reissue the select), all you can do is close the socket and reopen a new one with the server, there is no way, as far as I know, to recover a broken connection, although, if you've implemented in the protocol, you can resume where you left off when the socket was broken. I don't know how you've implemented the protocol, but most of them will required a positive ACK (acknowledge) from the receiver before going on with another message. Also, when establishing a connection the client should specified if it a brand new connection or a broken one and act accordingly.
The idea is:
The sender sends a header specifying the command to process and the length of the data it's going to send after the header, the receiver receives the header and the data, once it process it, it sends a response ACK packet to the sender with a positive value to acknowledge the message, optionally with some data in case it's necessary. If after a reasonable period of time you don't receive the ACK packet then you may resend the same data again until you receive the positive ACK.
There could be the situation where the client sends a message, the server receives it and processes it, but when the server sends the positive ACK packet the connections breaks and the client never receives the packet, so it will resend the same message again once the connections is reestablished. To avoid this situation, it's necessary to send a message ID (an int which increments for every message sent) in the header to identity it.
I know it sounds difficult and it's in fact. If the connection is on the same network (intranet) it works nicely but, when the communication is on the internet, you may face a lot of problems and situations which you can't control, so it's necessary a well defined protocol where you can recover from broken connections and the transactions/messages won't be duplicated.

Android - How to keep connection with server for a long time

I wrote a chat application for Android using SocketChannel. It connects successfully with the server and all features work. But after a long time since I logged in (about 2-3 hours), I try to send a chat message again and it fails. In log file, SocketChannel, selector still open and connect to server, message already write successful. What's the problem? What am I missing?
Thanks in advance for your help.

I have had a same kind of problem with SocketChannel. I have used SocketChannel based library to connect to a websocket from andoird application (The library is Autobahn websocket). I can successfully connect to web socket and can send/receives messages through the websocket. But After sometime(may be after 30 mins, 1 or 2 hours) the the websocket connection hangs. As your scenario, logs seems socket connection is still open and connect to server, message already write successful. But server won't receives the messages.
In my scenario problme is not with the SocketChannel. Problem is with TCP time out. In order to keep the connection alive I'm sending peroidic ping message from server to client. Web socket default support this messages call PING/PONG messages. This ping message need to be send to clients in periodic time, in order to keep the connection alive. When ping message receives client automatically replies PONG message to server. By using this approach I was able to keep the socket connection for a long time.
More information about this approach
Solution for websocket hanging, Websockets. Loss of internet, keep-alive messages, app architecture etc, websocket protocol and ping/pong messages
Hope this would help to you(even though you are not using websocket). The approach could be same in websocket as well as your chat application.

if you want to create a Chat for android or something else with push from a server, try it with MQTT
http://tokudu.com/2010/how-to-implement-push-notifications-for-android/
its is a very cool thing, just take a look at it :-)