Do XMPP Servers such as Openfire require implementation of their own in order to handle messages. Do I need a web language such as PHP in order to handle messages with Openfire?
Because according to posts such as this How to make Chat Application in Android Using XMPP and GCM, I do not need to write PHP scripts in order to handle messages, Openfire (it being a XMPP server) will do all the heavy lifting. So when creating a messaging program is the only thing I need to worry about the client side code?
I've also run into contradictory information that I hope someone can clarify on. It was to my knowledge that one needed to use a XMPP server along side GCM; as GCM is not reliable in delivering messages by itself and requires an XMPP server to fully be reliable. Is this true, the above link suggests that it isn't, but according to this it is https://www.youtube.com/watch?v=5wXGcu9H91s
Some clarification would be great, thanks.
GCM allows you to use both HTTP and XMPP to send messages down from your application server through GCM to your devices.
Only with XMPP though can you send messages from your device through GCM to your server. This allows your device to send acknowledgment messages back up to your server. This does not necessarily make GCM more reliable but it does allow you to have a better audit of what messages were actually received by devices.
Openfire is a server that supports XMPP so you will still have to implement the protocol maybe using Smack.
Note that you could skip GCM and have a connection directly between your app and your XMPP server, however this is not recommended since your app would have to be constantly connected to your server which would be very hard on the battery of the device. This is where GCM comes in, allowing your app to receive messages even when it is in the background but still being kind to the battery of the device.
Related
we have already implemented GCM over HTTP for our chat functionality, but after reading GCM XMPP xmpp document and google states below benefits offered by xmpp
Benefits :-
The asynchronous nature of XMPP allows you to send more messages with
fewer resources.
Communication is bidirectional—not only can your server send messages
to the device, but the device can send messages back to your server.
The device can send messages back using the same connection used for
receiving, thereby improving battery life.
we choose HTTP, since we are comfortable in developing using http rather than XMPP. but my concern is, will XMPP provides long term solution for our chat functionality?.
And i am not getting first two points, fewer resources (what exactly it is, when compared to HTTP), secondly, bi-directional messages, i see this can be achieved in HTTP either ,my flow diagram for http flow
i understand in http we need to create new connection when ever we need to invoke backend, so XMPP has advantage here. I would like to know is HTTP is right choice for chat functionality? for longer run..
XMPP should be used over HTTP for continuous communication.
XMPP supports upstream messaging, with HTTP your client (phone) has to make an HTTP call to your app server, you cannot send an upstream message to GCM without XMPP.
XMPP makes fewer connections so overhead (battery, data etc) is much less than with HTTP.
I need to implement a group chat server which can support more than 50 users at a time.
The users will be only on mobile clients which include Android/Windows Phone.
Sending push notifs to the apps will not be difficult, as the server needs to do a basic curl request. So "polling" is not an issue.
My current skill set includes.
Flask
Google App Engine( I intent to use it or a web hosting
server.)
Basic php
So from what I know, I can make http requests to the server with user specific information+chat msg.
The server processes this and sends a broadcast using push notifs to all the devices stored in database.The server identifies the device from the data in the http request.
How efficient will this be?
If this is not the correct approach, what all do I need learn(sockets programming?) and any framework which can make my work easier (it will help if it is also supported on GAE).
I think you need XMPP messaging. It's support by App Engine but not in PHP : https://developers.google.com/appengine/features/
XMPP permit to send and receive chat messages.
I want to know which protocol is used to send push notification to android devices and which to send push notification requests to GCM.
Whether it is HTTP, HTTPS or some thing else?
The protocols of the communication between the 3rd party server and GCM server (HTTP or XMPP) were already mentioned in the other answers.
The protocol of the communication between the device and GCM server is not discussed in the GCM documentation, since you never have to access it directly as an Android application developer, and therefore you don't need to know about it.
However, here's a quote from a Google developer from the team that created GCM, which says a few things about the connection. From what he says, you can only know that it's a long-lived TCP connection.
GCM maintains a long-lived connection - and reconnects if it knows the
connection was broken. A router/AP/NAT is supposed to send a FIN or
RST to terminate the TCP connection - so GCM and servers will know the
connection is dead.
However a number of routers and mobile operators don't do this, and
then GCM needs to rely on the heartbeat, ~15 min on Wifi, more on
mobile.
(The quote is taken from an answer by that person)
There are two protocols http and xmpp which you can use to send message to GCM server.
Now its up to you what you want to use. If you want to broadcast message then u should go with http.
you can broadcast 1000 message in a single http request. And only one message through xmpp in a request...
Http can be used only for down streaming(3rd party app server -gcm-mob device)
But gcm won't support up streaming using http.
for that you should use xmpp.Xmpp can be used for both up streamlining and down streaming.
Implementaction of push notification can be very easy if you are going with http and that much more hard if you are going with xmpp.but Google has provided detail tutorial how to implement xmpp.
So please have a look On Google developer site.
Looking at #user3523641's answer and further conversation, I'll try to explain further:
The way of delivering messages is based on the protocol that you've chosen, either HTTP or XMPP (i.e., it's the same). The magic and basic way of working is leaving a socket opened between the GCM server and the user's device.
This way, when an user should receive a message, this opened socket will be used and send the message through itself. This also helps the GCM server knowing which devices are connected or not. So this way, if your third party server says a message should be sent to a user and the GCM server knows the user is not connected, it won't send it at that time, but will try once the connection is again established, so it won't waste connection attempts in vain. The default timeout is 4 weeks, however, it can be changed.
As per the official GCM documentation:
If the device is not connected to GCM, the message will be stored until a connection is established (again respecting the collapse key rules). When a connection is established, GCM will deliver all pending messages to the device, regardless of the delay_while_idle flag. If the device never gets connected again (for instance, if it was factory reset), the message will eventually time out and be discarded from GCM storage. The default timeout is 4 weeks, unless the time_to_live flag is set.
Finally, when GCM attempts to deliver a message to the device and the application was uninstalled, GCM will discard that message right away and invalidate the registration ID. Future attempts to send a message to that device will get a NotRegistered error. See How Unregistration Works for more information.
You can find more info here.
It uses both HTTP and XMPP
When the message is processed successfully, the HTTP response has a 200 status and the body contains more information about the status of the message (including possible errors). When the request is rejected, the HTTP response contains a non-200 status code (such as 400, 401, or 503).
iOS however, requires a dedicated TCP connection on a proprietary port, and GAE environment doesn't allow any external protocol except HTTP over port 80.
The message size limit is 1024 bytes.
Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device
This is how these components interact:
Google-provided GCM Connection Servers take messages from a 3rd-party application server and send these messages to a GCM-enabled Android application (the "client app") running on a device. Currently Google provides connection servers for HTTP and XMPP.
The 3rd-Party Application Server is a component that you implement to work with your chosen GCM connection server(s). App servers send messages to a GCM connection server; the connection server enqueues and stores the message, and then sends it to the device when the device is online. For more information, see Implementing GCM Server.
The Client App is a GCM-enabled Android application running on a device. To receive GCM messages, this app must register with GCM and get a registration ID. If you are using the XMPP (CCS) connection server, the client app can send "upstream" messages back to the connection server. For more information on how to implement the client app, see Implementing GCM Client.
Check out this for more details -->
Google Cloud Messaging for Android (GCM)
Android Cloud to Device Messaging Framework
Cloud Messaging
Cloud to Device Messaging
I really tried to find a solution to this problem but didn't. There are some threads related to this concept, but I didn't find a comprehensive solution.
I have a server with Openfire which sends messages. When both users are online, there is no problem. However, when a user is offline I would like to send a push notification, as in Whatsapp. I heard that Whatsapp and other IM apps use a modified version of ejabber to send push notifications, but couldn't find out how.
One possibility is to use GCM, but I am not sure if this is the right way to go. Also I would like to avoid polling, for the sake of not draining battery life.
Does anyone know some solution to this or has an example?
I am studying the openfire and found some good options that I would like to share with you.
I found a plugin in github and i will test it this week. It seems that will be a good solution to your goal and to my: https://github.com/meisterfuu/Openfire-GCM/
Another option is to use CallbackOnOffline Plugin that calls a specified URL with To and From parameters. This url could be a endpoint in your web service, and with that data (To and From) you could get the associated Id for push in your base, and did a push.
https://www.igniterealtime.org/projects/openfire/plugins.jsp
Well, you could use GCM with XMPP.
The new GCM Cloud Connection Server allows you to use the XMPP protocol for a bidirectional (Cloud to Device and Device to Cloud) communication between your server and your Android application.
The GCM Cloud Connection Server (CCS) allows third party servers to
communicate with Android devices by establishing a persistent TCP
connection with Google servers using the XMPP protocol. This
communication is asynchronous and bidirectional.
In openfire its done automatically, messages will be recieved by the user when the user gets online. So no worries send message to an offline user and when the user comes online message will automatically pushed to the user.
I am trying to create a chat application. The communication is based on RESTful web services(Jersey). The client communicates with the server sending HTTP requests. My problem is how to send messages from server to client without the client send a request first. I read about C2DM notifications, I suppose using this way, when the client receives the notification from the server then (the client) has to send a request to the server in order to receive the data. I also was thinking about using sockets but I don't know if it is possible as I am using Rest. I mean in the server side can I also use sockets(sockets run in lower level) with the REST code? The only thing I have though that could work using sockets is to create another server with socket(two servers RESTful and socket), but is this a good solution? Also could I put some server code in the client side and some client code in the server side. Would it be correct and effective? What do you think? Which solution would be the best?
C2DM has been officially deprecated as of June 26, 2012 by google. Existing C2DM developers are encouraged to migrate to the new version of C2DM, called Google Cloud Messaging for Android (GCM).
Check out this link for more info
http://developer.android.com/guide/google/gcm/index.html
The scenario you describe sounds ideal for C2DM. If you build your own sockets set up you will drain battery and CPU resources doing something the phone is already doing - maintaining an open socket to receive messages.
C2DM is relatively straightforward to set up, and in my experience is pretty reliable.
This is the best tutorial I have seen on it:
http://www.vogella.de/articles/AndroidCloudToDeviceMessaging/article.html
But you also need to read the official docs:
http://code.google.com/android/c2dm/
Your server-side code will need to send an HTTP request to the C2DM servers to send a message to a device. To tell it where to send the message, your server needs to specify the Registration ID (which represents your app running on one specific device) and so when your app sets up on the Android device, it registers with C2DM, and then needs to send its C2DM Registration ID to your server to be stored, ready to be used to send messages to.