

XMPP library for node.js - julien
http://github.com/astro/node-xmpp

======
hammerdr
How is this different than <http://github.com/mwild1/xmppjs> ?

~~~
Rauchg
"You like Strophe.js? You bought a copy of Professional XMPP Programming with
JavaScript and jQuery? You even want to use the same XMPP code for the web and
node.js? Then you're wrong here: go to xmppjs."

~~~
papachito
I don't find his explanation very clear. Could you explain what's the
difference?

~~~
aaronblohowiak
Objectives of node-xmpp:

Use node.js conventions, especially EventEmitter, ie. for write buffer control
Fast parsing, node-expat was written with this library in mind Support for
both XMPP clients and components After authentication, leave trivial protocol
bits to the user (later we could offer helpers for entity capabilities
hashing, etc)

The other library lets you connect as a component to a XEP-0114 compliant
server

~~~
papachito
Thanks, I read that part too, it still assumes you know what a component is in
XMPP which I'm sure most people don't. So it's basically an XMPP client and a
"component" (whatever that is)?

~~~
aaronblohowiak
a component is something that plugs into the server that can receive messages
on the domain and reply as anybody

------
mahmud
Gaah, that's like hitching a trailer to a Lamborghini.

The point of XMPP is to be fat and semi 'standard' complaint. The purpose of
node.js is to be _fast_ , at the expense of compatibility and compliance,
while maintaining the simplicity of javascript.

If you want XMPP, it might be better to speed up any of its existing servers,
instead of saddling Node with cruft.

~~~
frognibble
It looks like a nice library for writing non-blocking XMPP clients and
components in Javascript. This seems useful even if the goals of XMPP and Node
are different as you claim.

This library does not saddle Node with anything. It's a library for use with
Node. It's not part of Node

~~~
mahmud
The point of XMPP _clients_ is to work with a server/platform infrastructure
that someone else has built and has control over. Then, it makes sense to use
something like Strophe.js to talk to the server in its protocol of choice.

However, if the server you're talking with runs Node.js, there is a good
chance whoever behind it (if not _you_ ) is someone who is able to make sane
technical decisions, like _not_ using XMPP and opting for something light
weight.

The way I see, and to use another anology, is like writing a SOAP server in
assembly in the hopes of getting better results.

If you want to talk with the myriad of desktop jabber clients out there, use
something tried and true, and supports XMPP to the fullest (so Node is out.)
If you just want a serialization and pub/sub protocol, use something more
lightweight than XMPP. XML manipulation will defeat the purpose of Node, which
is performance and design hygiene, very quickly.

~~~
DennisP
Sometimes XMPP is a requirement. Maybe you want the federation, or you want
people to be able to use their gtalk accounts.

Call me crazy but I actually think a non-blocking server with good performance
and low memory usage would be a pretty nice foundation for an XMPP server.
(This project is a client though.)

~~~
jerf
You're going to have trouble beating ejabberd on its native turf, and JS
probably isn't going to let you beat its memory usage anytime soon, based on
what I've seen in my running servers. ejabberd is considered a memory hog of
an XMPP server, because it might use as much as a kilobyte for a connection's
state information, vs C or Java which can go smaller due to full control over
the memory. About 200 bytes is more common, though. JS would leave you with
even less control over the memory and make it very easy to go ever further
over 1KB/connection.

And actually, having experienced ejabberd and worked with its internals quite
a lot professionally (for about two years), this is where I think Node.js
would just fall down screaming. A serious XMPP server ends up having to do
some actual logic that can take some actual time, like working out who is on
the roster, which takes time when that may be a couple hundred people. It may
still be a fraction of a second, but Node.js is either going to choke and die
on the sheer overwhelming number of small little things that still have to be
done synchronously, or the XMPP server would have to be manually sliced into
tiny, tiny ribbons (instead of working out the roster, working out the next
roster item and pushing it out) in which case call overhead would still be a
problem too. And being stuck on one core is going to be really rough as you
try to scale.

You aren't going to get what the XMPP world would consider "low memory usage"
out of Node.js, and "non-blocking" will only get you to toy size. Which may be
enough for some tasks since "toy size" is still at least tens of users before
you really start hitting these problems, but based on my experience even at
the medium hundreds level you're going to start hitting problems.

(The steady-state of an IM server isn't too bad and if we just assume Node.js
has somehow made it to the steady state it could support several hundreds
relatively easily. The problem is that a real-world IM server ends up getting
these spikes that you might not anticipate if you've never worked with them,
because events like going online and offline are _not_ independent, and these
spikes are what will bring your server to its knees. In particular, there's
the case where your IM server itself lost its network connection, then it
comes back, and all the clients try to reconnect at once, hammering your
server with the full login process for every connected user, full presence
storms, complete reconnection of every S2S connection, every transport user
reconnecting, basically everything happening all at once, and this is an
enormous number of things to be stuck doing synchronously per-item. You will
experience the full hell that can be brought to you by cooperative
multitasking. The best part is, if your server can't take that process and
actually goes _down_ , when it comes back up it gets to start all over again,
probably just to crash again. To have a working IM server takes more than
being able to handle the steady state, if you can't deal with these spikes
your server will have trouble just getting to the steady state. There are some
other spikes you can get, too. Also, you'd be surprised at how quickly users
pick up on the fact that your instant messages are actually taking 2 seconds
to send.)

~~~
DennisP
I was actually thinking redis would handle roster duties. It's got native
queries that are a good fit to that sort of thing, and it's got replication in
case one instance isn't enough for the load.

There's a guy with a web chat system using Comet on node.js who claims 100K
simultaneous users on one server, with fairly modest memory usage. Of course
that's http. Is xmpp that much heavier?

(You've convinced me the problem is more difficult than I thought, btw.)

~~~
jerf
"Is xmpp that much heavier?"

Well, it depends. It is not commonly understood that XMPP is actually very
modular. What I was citing you was the requirements for what you might call
the "usual" XMPP server, what people tend to expect when they hook up Pidgin
or Adium to something claiming to be an XMPP server for dedicated-client use.
Huge rosters (in the hundreds is distressingly common, in the thousands not
unheard of), server-to-server connections, avatars, conferences, frequent
granular presence changes (some % of the users changing for every MP3 they
play due to plugins), logging, etc.

On the other hand, throwing together a "shitty" web chat where no one chat
room is expected to have more than, say, 20 users, where "chat rooms" are the
only communication concept and rosters are more limited or perhaps
nonexistent, no logging, sure, Node.js should definitely be able to scale to
100K no problem. Probably beyond with reasonable hardware.

I think you may be referring to Plurk's work, and please note I'm not calling
their stuff "shitty", I'm specifically describing a minimal chat client up
there. I actually don't think XMPP is all that much heavier than AIM or MSN
(some, yes, but not really that bad), it's that IM has evolved past the days
of ICQ. What kills you are the O(Roster Entry) elements; one guy with a 2,000
element roster (bidirectional) comes online. With XMPP, as part of the
connection process you shove down the 2,000 user roster to the guy logging in,
and have up to 2,000 other presence notifications to send out. And it's hard
to make that entirely async; even if you do just grab the roster as a lump out
of some data store, you still have to iterate over the 2000 elements of the
roster to send out the presence updates, and even with GHz to play with that
is going to take some time to formulate all the necessary messages. This is
what would really worry me at the startup flurry I mentioned.

But like I said, you could still carry hundreds, most likely. Although even
then I would observe that the value of having an XMPP server actually in-
context to a Node.js process is really pretty minimal. You can still be a
"part of the server" via the component protocol which is what you almost
certainly really want. Let a best-of-breed do all that for you, and just
implement the additional stuff you want in Node.js. Unless you're doing too
many O(roster entry) things in there (which in general you aren't in a
component), Node.js should scale quite well, and components can typically be
sharded cleanly too (by assigning users to shards).

~~~
DennisP
Ahh, ok I understand the roster issue better now, thanks. You're right, Plurk
is what I was referring to.

------
papaf
I imagine this could become part of a non-blocking google wave server...

