I'm currently developping an Android application which connects to a server through TCP. The server is written in Qt and runs on a computer.
In server side, I use a QTcpServer and the signal QTcpServer::newConnection() to get the QTcpSocket newly connected with QTcpServer::nextPendingConnection(). I have implemented a class I called SocketManager, which manages the data received by this socket.
In Android side, I use java Socket to connect to the server.
All work great. When the Android side disconnects from the server, my SocketManager object is well notified and destroys itself. But I would like to manage properly the case when for example the Android device goes to offline or is turned off. In that case, I'm not notified of the disconnection of Android. I connect these signals of my QTcpSocket:
QAbstractSocket::disconnected(),
QAbstractSocket::stateChanged(QAbstractSocket::SocketState)
QAbstractSocket::error(QAbstractSocket::SocketError)
QObject::destroyed(QObject*), thinking that perhaps the QTcpSocket is internally destroyed by the QTcpServer.
But no signal is received when the Android device goes offline or is turned off.
When the QTcpSocket will be released by the QTcpServer? Only when the socket is explicitely disconnected? So in my case, will it never be destroyed? Should I manage the disconnection in all cases in the Android side?
Thanks everyone.
TCP will not notify you of disconnections unless the remote peer explicitly sends disconnect request (by using close() or shutdown() methods) or you try to write to a disconnected socket (in which case you get a broken pipe signal)
The classical way to solve this problem is implementing a heartbeat messaging system where after a certain amount of heartbeat inactivity you close the socket concluding that the remote peer has died suddenly or there is a network problem.
Related
I am trying to make an app, that when it sees a specific bluetooth device to connect to it and send a command and before loose that connection to send another command.
The device is standard bluetooth serial device.
Is there a way to check when i am going to loose the connection?
No unfortunately Bluetooth doesn't work this way. You are usually notified that the remote device disconnected and you can even get the disconnection reason (e.g. BT_HCI_REMOTE_USER_TERMINATED_CONNECTION), but by then it is already too late and the link between your device and the remote device is already lost. Generally speaking, the way a disconnection works is that there are empty Bluetooth packets sent back and forth between the two devices (similar to an ACK) to indicate that the link is alive. If that packet does not arrive after a certain timeout, the BLE stack throws an event to the application notifying it that the connection has been lost (i.e. a disconnection event).
If you are using Bluetooth Low Energy, and if you are in control of both devices (your one and the remote one), then you could implement additional communication on the advertising channels. This is not as efficient as performing the communication through a connection, but you can advertise this additional command upon disconnection, and the remote device would scan for this new command upon disconnection as well.
I hope this helps.
I'm developing an app to receive data from C++ program every second. The app also need to send data to C++ program sometimes.
Is it suitable to use socket as communication between both instances?
For each instance, does it have to run socket server and client at the same time?
I think there would be different ways of accomplishing this depending on required timing behavior (does the device have to receive messages synchronously, should messages that cannot be delivered in time be cached till they can be delivered, etc.), public reachability of the android device (if they are connected over mobile networks they are behind NAT in many mobile networks) and if the devices could go into standby mode or not.
Using stream sockets (TCP) if the mobile device stays awake the whole time or processing has to happen always synchronously.
In this case one end would have to be the "server" and one end to be the "client". Because mobile devices tend to go into standby mode i'd use the C++ program (if it runs on a non-mobile device) to be the server - this would be the end that creates a socket, binds it and then uses listen to wait for incoming connections. Whenever the client connects to the server it has to accept the connection which then can be used bidirectionally by using the same handle for send and receive.
The mobile device then would create a socket and connect to the server and could transmit data to it (it does not have to bind or listen). Over the same connection the device could receive data from the server.
If the server is required to send data to the mobile device even when the mobile device has not established a connection and the mobile device is able to go into standby mode one could either periodically wake the device and poll the server or use the firebase cloud messaging system or even short message service or - if the device is not able to go into standby mode - simply create a listening socket too that accepts incoming connections from the C++ application.
Using datagram sockets (UDP)
In this case both the C++ application and the Android application would create and bind a socket to a specific port. Then they can both simply send packets (unreliable) to other clients or even multicast them in a local area network by sending them a multicast address. Of course the mobile device would miss packets that have been sent from the C++ application during periods where it's in standby mode and the C++ application would miss packets during times it's not running.
Using a message queue (if the mobile device may go to standby mode and has to receive messages asynchronously)
In this case both programs would not have to run at the same time if the queues are persistent, but a message broker would have to (for example RabbitMQ). The C++ application could simply push messages into the queue and any subscribed mobile device would receive them either immediately or (for persistent queues) later whenever the devices connects to the server.
Messaging from the mobile device to the server could also be realized over a message queue if synchronous behavior is not required or over a traditional webservice or even a socket.
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.
I'm working for an App Android and I need my phone was always connected to my server MQTT...
But my phone can lost his connection(Tel :[FIN;ACK]; Serv:[FIN;ACK];Tel:[ACK]); after that, when he send a [SYN] message for connect it to the server MQTT, the serveur send an [RST,ACK]... And this while the service of my app is in activity.
In my case , i MUST to re-launch my server if i want my phone can be reconnect, but, i can't reboot my server (multi-phone possible, and i need real-time performence).
There is there a possibility to connect my phone without reboot my server?
Thank's for time.
Best regard
Guillaume
I think your problem is similar to the one I had. The connection was half closed. See http://www.codeproject.com/Articles/37490/Detection-of-Half-Open-Dropped-TCP-IP-Socket-Conne for details.
The way I solved this was to i) add keep alive msgs, every 5 secs. from the phone to the server and ii) have the server close the connection if there was no incomming data for 15sec. See http://www.forward.com.au/pfod/CheapWifiShield/index.html and www.pfod.com.au
MQTT includes keepAlives (PING request msgs) so you only need to modify your client to specify a short keepAlive interval
see http://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over
to have the MQTT server to more quickly close the connection once it stops getting your data or keepAlive msgs.
Although the above link states
"The broker will close the previous connection to the same client (determined by the same client identifier) and establishes the connection with the newly connected client. This behavior makes sure that half-open connection won’t stand in the way of a new connection establishment of the same client."
So you should not be having this problem at all !!!
i'm writing a client-server application which uses TCP socket connection. In my android project, Service creates a thread for listening the TCP socket.
Everything seems OK. But i have got one problem.. My network service running in background fine; But some time later (10-15 min..), when i try to open my application (main activity) again, I can't get responses from the socket connection. It freezes or something?? i cant send or get TCP messages from the socket.. What can be the reason of this? I'm working on my phone, via 3G connection.
(Besides, the app running in the emulator hasn't got such this problem; I assume Its connection is stable, long-during )
Thank you for your answering.
Due to power optimizations and perhaps changes in connectivity (GPRS/HSDPA/Wifi) it's very likely your connection is being dropped.
In order to maintain a connection, your background service needs to claim a wakelock using the PowerManager class. This prevents the device from going to power-saving mode and thus disconnecting your socket. But beware, this significantly lowers the battery life of the device.
Also, you need to handle changes in connectivity which break your open connection. Android sends out a broadcast message named android.net.conn.CONNECTIVITY_CHANGE to notify of changes in connectivity.
Depending on your use-case I would poll with when the device is in the sleep-mode and only build a connection when the device is actively in use or just use C2DM push notifications
When I have experienced something like this in my apps, it has usually been because of power optimisations on the phone (which cant be overridden). If the socket has been idle for too long, it is automatically closed and needs to be reopened.
Are you sending data from time to time? Like implementing a heartbeat protocol ? if you are not, you should...or maybe it has to do with socket READ/WRITE TIMEOUT