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 :-)
Related
I have an Android TCP Server and a Python TCP Client socket. I am trying to send data/messages from the Python Client to the Server, where the Android app displays it on the screen.
However, the message is displayed only after the Client closes. I can't seem to have the message displayed before the Client Socket is closed so that I can have multiple messages sent between the Server and Client. I asked a question for the same issue, which is still unanswered -> Android TCP Server only displays messages from Python Client after Client is closed
So what if I attempt to have the Client Socket Open and Close multiple times just for the sake of sending and receiving data? What are the drawbacks of doing this over a wifi network?
P.S. - If someone is willing to offer more help - I am trying to have buttons on the Android App which upon being pressed/clicked send a individual messages (always the same) to the Client, and after each message the Client sends an acknowledgment message back. Any design tips to implement this for a complete newbie who is trying to have an app communicate with a robot would be extremely helpful. Thanks!
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).
Before ask my question, I want to let you know what stage I am on. I have already implemented TCP/IP socket on my android app, it works fine(so far...).The connection between client(my android app) side and server side is short connection which is when a user submit information, a new thread will be created to send the message out, on the server side, once the server got the message, the server will respond "RCVD", after that the socket will be closed and then the connection is closed. My app has a lot of interactions between user side and server side, therefore it does many connect and disconnect between clients and server, so I always worry about the socket communications will drain phone battery and the performance will be affected.
Recently I find OkHttp on github and a lot of people suggest using it. Im not quite familiar with Http, only knows it is a higher level network protocol.
Can anyone tell me which way is better? which is more efficient for exchanging data(Object/Json/String) and media(Images)? Which is more faster and which use less battery?
Many thanks.
Basically, the comparison between Http and tcp socket is meaningless, But in your situation it really matters.
As you described, in your tcp socket way, you may create new connection each time receiving new push from server, which is not that efficient, If you use OkHttp, when your client exchange message with the same server, the same tcp socket is reused each time rather than make a new one.
By the way, As for the push service, use XMPP(over tcp) may be better cause Http is not optimized for such short message exchange model(You should use some extra strategy on the server side to keep the connection from being closed), but you may have to handle some implements about XMPP server and client.
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 !!!
As part of an Android app I'm developing there is a chat room feature. We have a server which can process the incoming messages and store the messages. Is it better to keep a socket connection open between the phone and the server so the server can send any new messages to the phone, or is it better for the phone to poll the server for new chat messages?
It is bad solution with poll for app that have randomly posting data. What I want to say is that polling data is useful when you have something that is happening discrete like every 5 minutes or something like that. this is not the case with chat, some user can post something ones in a hour , some can post 30 times in 2 minutes
so keep your sockets open
Polling lacks real-time connection and a persistant connection is battery draining. I think that what you are looking for is a combination of "push"-ing and persistant connection. You would wake your phone via push, and then establish a connection via sockets to handle chat.
I suggest reading this article.
I'm not sure if it mentions c2dm, the google push service.
I would keep the socket open if you are worried about instant messaging, it takes time to setup the socket connection especially if you are using the GSM connection. I have seen it take 10 secs or more to open up a socket on 3G, much less if on WiFi.