← Back to team overview

ubuntu-push-devs team mailing list archive

Ejabberd

 

Although i have a bias against erlang and xml i am looking into ejabberd
for this.

The first thing that one notices is how suited it seems to be to the
problem by the technical description and marketing material:


   - Push notification capability with alerts sent to end-user’s mobile
   device via push notification systems like APNS and Google respectively
   provided by Apple and Google. If end user’s mobile app is not running in
   the foreground/background, an alert is sent each time a message is received
   via push feature.
   - http://www.process-one.net/en/ejabberd/


But going deeper into the docs and specifications i've found two issues
that worry me: reliability of delivery and storage.

Storage: Ejabberd uses mnesia or odbc/mysql/postgres for storage of
messages. Scaling and balancing this is a pain point.

Reliability of delivery: The XMPP Core spec says:

3.4 <http://tools.ietf.org/html/rfc6120#section-3.4>.  Reliability

   The use of long-lived TCP connections in XMPP implies that the
   sending of XML stanzas over XML streams can be unreliable, since the
   parties to a long-lived TCP connection might not discover a
   connectivity disruption in a timely manner.  At the XMPP application
   layer, long connectivity disruptions can result in undelivered
   stanzas.  Although the core XMPP technology defined in this
   specification does not contain features to overcome this lack of
   reliability, there exist XMPP extensions for doing so (e.g.,
   [XEP-0198 <http://tools.ietf.org/html/rfc6120#ref-XEP-0198>]).


Ejabberd has no support for XEP-0198 (Stream Management) nor for XEP-184
(Message Delivery Receipts). It has support for XEP-0079 (Advanced Message
Processing), but even that just seems to generate a non-reliable message
when some conditions are met. So we would still need to keep state and
develop the ability to handle these notifications to ensure delivery. (and
schedule re sends if we don't get the notification and being able to de dup
sends from the client side)

If this is so, we end up bringing in a lot of infrastructure and we still
still need to solve most of the problem anyways.

A funny quote from XEP-0184 (Message Delivery Receipts):

"This protocol merely provides a building block that could be used in
conjunction with other protocols to asymptotically approach the eventual
goal of messaging reliability and guaranteed delivery."

And this presentation from Process One (
http://www.slideshare.net/mremond/processone-push-platform-xmppbased-push-solutions
)
seems to imply that the preceding analisys is correct when they say:
"Process One extensions go further [(than XMPP)] [by providing]: Reliable
Delivery and Mobile Optimizations."

Is there something i am missing? Would you guys agree that xmpp does not
look like a perfect fit and that ejabberd would not be the implementation
of choice?

Regards,

Lucio.

Follow ups