[jdev] Help choosing the right technology

[Dave Cridland]

I'll chip in too, why not. :-)

So for the case of "user [device?] accidentally goes offline and comes
back", this could be dealt with by offline messages (which as Peter says
are available in every XMPP server), or by XEP-0198, depending on the
circumstances. XEP-0198 will handle the interesting case when the message
has already gone to the TCP buffer before the connection drop is noticed -
and do so in both directions - but offline messaging is usually used for
longer term cases from the server's perspective.

However, if XEP-0199 is actually good enough, you don't really have very
stringent reliability requirements, I suspect. :-)

As for scalability, my own observation (as an XMPP server developer) is
that different servers have wildly different scalability characteristics,
depending on whether compression, TLS, and so on are in play. As Kevin
says, the ideal case is to simulate the kinds of traffic you're intending,
but in general terms the scaling issues on most higher performance servers
are based on memory rather than outright numbers, which is convenient for
you because you can do those tests on smaller, more carefully simulated
runs and just ensure the scaling is roughly linear, and will fit your
server[s]. Tsung will, of course, tell you if a server can keep pace with
the traffic speeds.

XML is not an issue in the higher performance servers, most of which have
custom XML processors designed for XMPP specifically, or else use off the
shelf XML parsers in ways that are quite inventive in order to avoid most
of the overheads. In particular, if your experience of XML is from DOM
manipulation in Javascript, then I can assure you this is way different.

In terms of bandwidth, my employer has deployed XMPP over HF radio networks
running at 2400bps on really good days; while we do have to be fairly
careful (and it's running over S'5066 not IP), the stanzas themselves are
standard, if simple, XMPP. Over satellite at 9600bps, we can be
considerably less careful - even chat state notifications work OK. Latency
for connection is more of an issue at these speeds; we run S2S without the
traditional connection negotiation to handle this.

On mobile (high bandwidth!), things are pretty relaxed, C2S is entirely
viable, and your main concern will be battery life - XEP-0286 has some
information on this; I should really update that and give Peter another XEP
or two to publish...

{Disclaimer: I work for Isode, on M-Link, so I'm unashamedly biased toward
that, or Stroke/Swiften, too.}

HTH,

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20121113/36f5d8fd/attachment.html>