i have the project requirement in which i want to make an instant messaging app in android/iphone and may be in future it supports voip and video chatting.
Now i have 2 choices
1) xmpp - it is application layer protocol for IM, which is almost 10 year old, and it has lot of extensions which support voip or may be video chatting, online/offline status and lot of other features. It is accepted by all big companies like whatsapp,fb,Skype etc
Also I heard that google has moved away from this protocol because of vulnerability.
2) websocket - it is tcp layer protocol which provides a full duplex communication over a single tcp connection and it’s new and it was standardised by IETF in 2011.i don’t know whether this protocol is mainly used for IM. but i know that it can be done as it is in tcp layer. And i didn’t saw or heard any features/extensions of web socket other than the 4 methods(i.e onOpen, onClose, onMessage and onError). so it means if i choose this i have to make my own methods of online/offline status(may be sending a frame in every “x” seconds/minute), voip, message delivery information and other features etc.
I am confused, which one i choose, xmpp or web socket, in terms of development, server handling cost, security, session handling management, browser support etc.
If i am wrong anything about these 2 protocols then please correct me.
THANKS IN ADVANCE
Google didn't find a vulnerability in XMPP.
You can use XMPP over WebSockets using draft-ietf-xmpp-websocket, which will soon be an RFC.
Related
Currently I am planning to use Firebase Cloud Messaging with my Android and IOS APP.
In Firebase there are two type of protocol HTTP and XMPP, so my question is when to use which protocol. In which scenario which protocol performs the best.
Thank you all in advance.
From what source you have got that Firebase does not work in emulator!! I am developing an app using genymotion emulator and it works good. Also about HTTP and XMPP what protocol you use depending on the server you will be using. HTTP is simple to use and a lot of people go with it while XMPP is complicated to implement on the device and server as well.
But XMPP may be harder it supports downstream and upstream messages means you can also send a message from a device to your server. But XMPP is good as it does not take a lot of charge and battery.
But nearly everyone use HTTP. And implement upstream messages by your own implementation!!
IMO this does not matter a lot pick the one which u feel more comfortable with.
Only thing I can state is that XMPP is protocol created for communication so if your notifications consist of short frequent messages pick this one, otherwise pick HTTP, which is more commonly used
Sincerely I have experience just with HTTP and it works really well
According to my view, use HTPP. because XMPP requires HTTP more than HTPP requires XMPP.
XMPP is an open standard technology protocol used to presence indicator and instant messaging, while for HTTP had good features and the same time it works better than XMPP.
I am making a chat application for android. For that, I decided to use GCM (Google Cloud Messaging). But having researched a bit about it,I have read that it shouldnt be used for something like chat.
I will be implementing Upstream messaging (sending data from the device to the GCM directly, without a send-to-sync). Here are my concerns:
Will the messages transfer instantly? (will be fast enough that the user can see 'typing'/seen)
If all devices are online, what is the guarantee of the message from GCM reaching the client.
The main reasons I want to use GCM is
GCM uses the least amount of battery life
This is an android-only app.
If GCM is not what I should use, what should I use?
I am working on a similar requirement and Looking at the requirement of being able to show feedback such as typing/lastseen etc, as per my knowledge XMPP based solution would be appropriate.
you can try with available xmpp server like ejabberd/mangooseim (open source) by installing it on your server and use asmack or any other client side java library to communicate it with your server. (There are lot of tutorials available for this).
With this much setup you will be able to get to the stage where you are able to get status such as "typing", "gone" which whatsapp and also some chat clients like gtalk/pidgin shows.
It would roughly give an idea of how existing chat clients work.
Ejabberd is completely written in erlang and if you want to extend any functionality erlang knowledge is must. (it is specifically designed for highly concurrent fault tolerant and non-stop systems, which was helpful in chat applications.
GCM would be definitely able to communicate between the android phones 99.99%of times with not much delay but if you want to have roasters status like normal chat applications, you will have to reinvent the wheel completely.
Update:
Here are the considerations.
from client A to client B I want to send chat messages with roasters and dont require to store messages on any central server but just on the clients - XMPP (like whatsapp)
in case you require all the communication to be stored in server - XMPP with sql driver or mongodb driver / gcm (Depending on your time and resources)
in case you require communication between devices not necessarily chat, then gcm should be sufficient.
I am using this approach in my app currently which is live on playstore with beta version and it absolutely works fine in most of the cases. I havent seen much of bottle necks as of now.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
My aim right now is just to make an Android app that has WhatsApp-like capabilities (not necessarily a clone of WhatsApp; just has similar, perhaps not-so-good features). What's important I guess is group chat, online/offline presence, as well as offline messaging.
Right now I'm aware mostly of the possibility of having a WebSocket server (because I was introduced to it as a real-time solution that could open me up to endless possibilities), and I've tested it before--it looks good. However, I'm facing the following issues:
I don't know how to manage online/offline presences; do I have to implement that myself? Perhaps the Android client querying the server every 30s if his friends are still connected...
How about offline messaging? If a particular person is not connected, the message will not be delivered to him. Does the message then need to be stored somewhere (say MSSQL), and then when the person logs in the client will automatically retrieve all offline messages from the server?
What about group chats? I'm unsure how WebSocket is able to acheive that, do I have to implement that separately as well? That would mean a lot of biz logic to work on (and a whole lot of room for bugs to appear)...
I'm aware there is a protocol called XMPP (and that it's totally different from WebSocket) but I'm not sure how it relates to my problem. Is XMPP my silver bullet (i.e. are there .NET libraries out there that implement most of it there for me?). I've also heard of Comet, but I don't know how it relates at all...
There are so many missing pieces, I thought implementing my chat server/client would be a piece of cake, but apparently not so. Anyone with a l'il experience can give me some feedback?
You can and should be using WebSocket for presence and instant messaging functionality. In fact, instant messaging is the "Hello world" example of the WebSocket world.
Also, the WebSocket standard was designed to support higher level, richer business protocols (which ironically the standard calls sub-protocols). XMPP is one of such protocols, and there are several implementations out there with the exact features you're looking for.
If you'd like to try it out, Kaazing (the company I work for) has a free download available. It contains an open source XMPP server (OpenFire), along with the XMPP edition of a pre-configured Kaazing WebSocket Gateway. What Kaazing does is it extends the XMPP protocol to Web clients over WebSocket. It does so transparently, so from the XMPP server's perspective your (browser) client is just another XMPP client.
Another good resource is chapter 4 of The Definitive Guide to HTML5 WebSocket (of which I'm a co-author), titled Building Instant Messaging and Chat over WebSocket with XMPP. The book also comes with a free downloadable VM with open source software pre-installed and configured for your testing. Here you can see detailed screencasts of the VM - to get an idea.
Hope this helps.
let's go per parts:
first: Do not use sockets. That means you will need to keep a service running and maintain a connection at all times on each client device. That will drain the battery like crazy and no one will use it. What every-single-one of those apps use including WhatsApp, Hangout, Gmail, Facebook messenger is the Google cloud messaging (GCM) http://developer.android.com/google/gcm/index.html service.
maybe you want can send those status change via GCM at the moment they happen, or once the user enters the friend-list screen you do a one-off query with the status, the important thing here is that you will not query every 30 seconds in a mobile device.
Yes, if the device is not connected your server have to do the stuff. And I don't believe you'll use SQL, what a lot of companies are doing nowadays is noSQL approaches due to scalability, but it's not my expertise.
I'm not sure what you're asking here. You're mixing how you're going to send the data with how your application will treat the data. Those are two completely separate things, learn the difference. Example, Someone could create a group chat that works over WiFi-Direct over UDP (that's HOW the data will be sent) but what u do with this data doesn't matter, it could have arrived over Bluetooth that will be the same for the parser/interpreter. It's just data.
Good luck.
A mobile app I'm working on requires the server to communicate with it frequently over a short period of time, including real-time (or very close) things for the app to show (from other users).
It will be an iOS and Android app.
I was researching C2DM and on this page http://code.google.com/android/c2dm/quotas.html, at the bottom it recommends considering "implementing XMPP or your own protocol to exchange messages".
What I want to communicate between the server and the app does not fall easily into XMPP's usual chat roll, how would you go about actually implementing it?
Would it be a case of choosing appropriate XMPP libraries for the server and mobile app languages, then making a custom server (and client side)? Wouldn't this drain the battery on the phone? Can it be done over a RESTful architecture?
(If it helps, there are currently no decisions made for the server - other than it has to be highly scalable).
If what you want to communicate can be easily represented as XML and is not too large, then it can be easily done via XMPP. XMPP is very extensible. You will have to write the client side (to be expected) and use one of many available servers. Customization on the server usually means writing a component (generic and supported by the spec) or some sort of plugin (this will be server specific), but without more information I couldn't tell you if that would be required or not.
It is used for much more than just chat apps, although that would be the most common usage. Pretty much any text based instant messaging can be handled (as well as others). There are a huge number of extensions to the base protocol to support a wide variety of functionality.
I am an android developer and I made some board games. Now i want to make some of my board games multiplayer. I don't want to create and host my own web service, so i thought about P2P.
The first thing i found was the XMPP protocol, however it's not real P2P, but if i can use the existing google talk service, i'm ready to go. Is this possible while using your existing google account without interfering with the normal working of your google talk client?
Then i heard about JXTA, a real P2P solution, and it's already ported from J2ME to Android (http://code.google.com/p/peerdroid/).
Maybe i am overcomplexing things here (as i do sometimes)
I just want to know the easiest way to do simple P2P for a boardgame.
All your opinions are welcome! Thanks in advance
Kristof, Did you get an answer to your question? I've been working on a multi-player application recently as well, though I've chosen to host the server (originally). I'm now reconsidering my choice, though, but the library I'm using fully supports peer to peer communications. The underlying protocol is built on top of Google Protobuf. It's essentially a full duplex RPC stack built on top of Netty, which can use Protobuf. Here's the URL to the RPC protobuf stack: http://code.google.com/p/protobuf-rpc-pro/
The author has been very helpful and I've found a couple of bugs, nothing major. I also had very little issues getting these libraries working on my Android phone, but they're not terribly "compact." Nothing extraordinarily large, just not small :). So far, I've had no issues getting the communications working both synchronously and asynchronously. As such, I may be moving my game over to a "peer to peer" style, and just provide the necessary location/registration server that would be used to find existing games/server.
Using XMMP should be possible for you case. Look at smack from igniterealtime. They have a nice and active java api that helps to build you own jabber extension packets that can be used to transport the changes in game state.
I think that using two google talk clients at the same time with the same account could be difficult. But it would be great because you could invite all the friends from you list to play with you directly from your game. This way you could easily get more people to play your game.
You can't use the existing Google Talk Service/Connection from what we've seen. You should take Janusz's advice and check out the smack library, that's your best bet. To allow multiple non-interfering connections with the same GTalk login take a look at the resource component of the XMPP address, it's what allows you to be logged into two clients at the same time to the same account. You can effectively make your game another client. More here: http://code.google.com/appengine/docs/java/xmpp/overview.html#JIDs_and_Resources
Finally, there appears to be some new functionality in 2.2 relating to device push communication, but I haven't looked into it yet. 2.2 is not widely deployed yet either, so probably of limited use.
Basicly, if you want to write a multi user game or a game built on top of XMPP (Jabber), you should have a serious look at pubsub extension of XMPP. It's designed for pushing data from a server to clients, in the opposite way of HTTP. In HTTP the client has to pull information from the server all the time to be able to know when some new data is pushed. While XMPP is designed to push data to clients, when something happens. Less resources used on server and clients.
You should not use the Chat part of XMPP, as that will interfere with the users presence.
In pubsub you can create a tree of nodes, where clients can listen to any new data published in any node or subnod in the tree that the client subscribes to. So if some client publish data on one node, all clients that has subscribed to that node, or any parent, will be notified about this data.
The good part with XMPP is that it's extensible so you can extend the protocol with your own extensions. I also give you user authorization, authentification and encryption, and you don't need to debug that yourself.
You could use any XMPP-server with good support for pubsub or you can host one server yourself. There are plenty of servers usable for this. GTalk doesn't have support for PubSub last time I looked.