[jdev] Help choosing the right technology

[andy nes]

Thank you guys for your suggestions. Decided to go ahead with XMPP. Now I'm
trying to figure out a good enough architecture for my application (plan is
to structure it as a component and connect to XMPP). I have put my thoughts
and questions in a separate mail, love to pick your brains on those
questions.

@Abhinav
I did look at MQTT. But lack of open source implementations pushed us more
towards XMPP.

@StPeter
Will look into the XEPs 0198 and 0184. Thank you. My application might
start with 10,000 concurrent sessions and might scale to 100,000 in six
months. That's Scalability for me. I am going ahead with XMPP choosing it
over AMQP and MQTT. Hope the decision pays off.

@Dave
Thank you for the inputs. The only reliability requirement that we have is
not to miss the data sent over XMPP for a particular user as the data can
be part of business workflow and missing that can disrupt the work flow
itself. Will look into the XEPs though. As for Scalability, as mentioned my
starts with 10,000 concurrent sessions and might scale to 100,000 in six
months.

@All
Thank you for helping me choose a technology. It might help me further if
you can suggest an architecture for a Component that needs to connect to
XMPP Server which has business logic and database IO operations. I have
written a detailed mail asking suggestions.

/andy


On Wed, Nov 14, 2012 at 4:37 AM, Dave Cridland <dave at cridland.net> wrote:

> 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.
>
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20121116/0c5582af/attachment.html>