I am implementing a feature to push real-time updates to clients (web, android, ios). Instead of implementing my own websocket solution, I use OpenFire. I am not sure if this is how people normally push live update, or XMPP server is for messaging only. Please give me feedback on my approach.
In all three mentioned platforms you are not allowed to maintain socket(or websocket) connection to your server, as typical XMPP connection works. You should forward updates to platform "push service" (APNS, GCM, MPNS) and it will push updates to registered clients.
"Push updates" are just notifications about new content available on server, they are not guaranteed to be delivered and not reliable to transfer large amounts of data. Your client still need to connect and fetch new content from server. In this case you can reuse XMPP or any other suitable protocol for exchanging data with your server and clients.
If you are familiar with XML and it is not a problem for you to serialize your data in XML-based form - XMPP may be a good choice, otherwise you can choose much simpler data transfer format.
Related
I've been working through a bunch of WebRTC examples, and they all require a custom Websocket server for exchanging the signalling data. OTOH, every WebRTC doc states that you can use anything for signalling, including carrier pidgeons.
So I've been wondering, just out of curiosity: why isn't signalling usually done using a boring old REST API (or similar)? It's not as if the setup process has realtime requirements, for which using Websockets would make sense...
Because you want the setup process to be as quick as possible—usually—and there can be quite a few messages to exchange, especially if you use ICE trickling. Using AJAX you'd have to use repeated polling, which is certainly slower. If that's good enough for you and you see some advantage in doing it that way vs. web sockets, more power to you. But typically you'd want to forward messages to the other peer as soon as you get them, not whenever the other peer happens to poll the server next. And the only practical option to push data from the server to the client are web sockets.
You could use server-sent events for the server-to-client push and AJAX for the client-to-server sending… but why, when web sockets already provide duplex communication?
I'm willing to use ejabberd / mongooseIm in a microservice network. XMPP should be our chat protocol aside from a REST API network. I want to send messages incoming at the xmpp server downstream to worker services. Has anybody done this or could lead me into the right direction?
My first thoughts are using RabbitMQ for sending the new incoming messages to the workers.
There are basically two choices to giving your workers access to the messages routed by ejabberd / MongooseIM. I'll focus on MongooseIM, since I know it better (DISCLAIMER: I'm in the dev team).
The first is to scan the message archive in an async / polling fashion. The Message Archive Management describes XMPP level protocol for accessing it, but for your use case the important part is message persistence - so just making sure the relevant module (mod_mam) is enabled in server config and the messages will hit the database. The databases supported for MAM are PostgreSQL and Riak, though there was also some work on a Cassandra backend (YMMV). This doesn't require tinkering with the server / in Erlang for as long as there's a DB driver for your language of choice available. Since PR#657 it's possible to store the messages in raw XML or even some custom format if you're willing to write the serialization module.
The second option is to use the server mechanism of hooks and handlers (also available in ejabberd), which can trigger a server action on events like "user sent a message", "user logged in", "user logged out", ... This, however, requires a server side extension written in Erlang. In the simplest case the extension could forward any interesting event (with message content and metadata) via AMQP or just call some external HTTP/REST API - that way the real work is carried out by the workers giving you the freedom with regard to implementation language. This options also doesn't require to enable mod_mam or set up a database for message persistency (which you could still have with a persistent message queue...).
In general, the idea is perfectly feasible.
Generally, the most common XMPP extension use to build messaging systems for machines-to-machines, internet of things, microservices, etc is PubSub, as defined in XEP-0060.
This is a module you can enable in ejabberd. It is API based, so you can even customize the behaviour of that module to your application specific.
Pubsub basically allows to decouple senders and receivers and is especially designed for that use case.
Helo, I'm working on a mobile game which needs realtime communication from client to server.
Usually I'll implement a TCP socket server and use some private binary protocol to enable bidirectional communication, and now I also looking into XMPP server like Ejabberd which is based on standard. But XML in some way it's really redundant and inefficient, especially for mobile app it could means more traffic and memory consumption.
Is it a MUST that XMPP use XML?
Is there any XMPP implementation that uses binary as low level data format instead of using XML? (or I shouldn't choose XMPP and start with other standard or technology.)
Any strategy to reduce overhead of sending complex data object (not big file object) using XMPP?
XML is required by the XMPP specification, so there are no binary implementations. It does indeed contain much more overhead, but you have to keep in mind the problem XMPP is designed to solve - an active chat connection can be expected to transmit maybe one message per second.
As for the Google talk api: they use a non-xml protocol for client - Google server connections. When I send a message in the Gmail client, the request body just contains a bunch of post data:
count=1&ofs=16&req0_type=m&req0_to=my.friend%40gmail.com&req0_id=6A8466CBC59CBB0C_0&req0_text=test&req0_chatstate=active&req0_iconset=classic&req0__sc=c
That part is not XMPP. The server which accepts this request then does the job of creating and sending out the XMPP requests. The XMPP is still in XML, they just use a different protocol between the client and Google server.
We are building a proprietary system involving a client and a server linked over TCP/IP. Occasionally, the server will have some new expected or unexpected information that would be of interest to the client. My understanding is that SOAP and REST are query/response systems that require the client to request something and the server responds back. We need the client to register and the server to respond back if and when the new information is available. Are these protocols capable of such behavior? In addition, we need standard database-like queries requiring immediate response.
If you are in the Microsoft world, take a look at WCF, it is capable of this type of communication.
Whether you are in the Microsoft world or not, I would suggest looking into XMPP and AMQP.
First, REST isn't a protocol, it's more of an architecture style.
Second, neither of these are designed for push data delivery.
You could use either for the query-type messages, but you'll need to devise an out-of-band communication protocol to use for push notifications. If your data is fairly simple you could just use a basic TCP socket.
Beside the obvious person to person instant message chat, What else have you used a Jabber server's functionality to enable?
Edit: links to working code to really show it off are particularly useful - and will be more likely to be voted up.
There are unlimited uses for XMPP/Jabber.
Take any message/data you want to send somewhere else and you can use jabber. Run a centralised logging service for distributed services? You can jabber the massage.
You want to check if your services/programs are running? XMPP presence will tell you. If you add custom status messages you can see exactly what is going on.
This is why Cisco has got into the game. Picture a server farm where each blade has a built in mini jabber client. On boot up it will register it's presence to the central server as awaiting work. The central server fires off some work in it's direction and it then changes it's status to "Busy". Another blade finished it's work and changes it's status back to "Available"... rinse and repeat.
When you combine the actual jabber messages with it's Out Of Band abilities, these servers can post where the results of the job can be found.
Anything you can think of needing to pass a message can be done with XMPP to some degree. Be this person to person, program to program, or any combination.
You could use a Jabber server to handle/broker messages between a client application and another server application.
It can actually be pretty effective.
Not me but Martin Woodward used jabber to control a "build bunny" that displays the current status of the build server.
http://www.woodwardweb.com/gadgets/000434.html
XMPP is good for sending messages back and forth between computers that don't need to be broken into chunks. They also can't be terribly big. If you use the right library, it can be pretty easy to set up.
Sending messages to a web page. Proof-of-concept: esagila.com
I plan to use it to receive notifications from my system, such as:
Process did not finish
Report was not generated on time
User needs help
I already receive many of these messages as email. But receiving an IM could be much more effective.
You might want to look at Vertebra which is...
a framework for orchestrating complex processes in a Cloud. It is designed with an emphasis on security, fault tolerance, and portability.
From the knowledge base:
Why was XMPP chosen for Vertebra?
XMPP based instant messaging can be a good alternative to search engines for information that is small, complete in itself and required frequently and repeatedly. For example, your daily horoscope - you require it daily and it is not large.
To see an example of this add astro#askme.im to your list of contacts in your jabber client (Gmail Chat/Gtalk/or any other Jabber client) and then initiate chat with this contact by sending the word "help".
Also see www.askme.im for a whole list of chat based solutions.
I've used Jabber in the past to get email notifications. Nowadays I use it for low-priority nagios notifications, it is very useful and way cheaper than SMS:
We use xmpp as both a 'bus' and a real-time API at http://superfeedr.com
Iowa State University Department of Agronomy has created this with Jabber: http://mesonet.agron.iastate.edu/iembot/
If you're a weather freak like I am, this is VERY cool stuff!
Apple implements mobileme's push service using Jabber/XMPP's subscription services to send push notifications. That is the most widespread use of Jabber for non-IM purposes I know of. This article has more details.
My friends have also built a Jabber python bot, which is kinda cute but not all that useful :-)
Edit
The most recent Next Big Thing, Google Wave, uses Jabber under the hood. Further illustrates the power of the protcol.
We have used XMPP and BOSH to enable users to communicate with a webbrowser directly and in realtime from their phone.
For example Code you can view our open source API
The vooices site also has live examples where you can control a map and play a game using your phone via your web browser: http://www.vooices.us/
I've always thought XMPP would be a good way to deliver SNMP data. OIDs are really painful, much of the system is insecure, and the SNMP traps never work quite like you want them to. With an XMPP server in the middle and a smart component to make some choices, you can use it to send out jabber or other notifications, kick off restart jobs, update web pages, or whatever else you need.
The XML data is pretty small in this case, and you can have the one XMPP server both talk to humans in message stanzas, or computers with the same protocol.