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.