XMPP library for node.js
github.com
github.com
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
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.
This library does not saddle Node with anything. It's a library for use with Node. It's not part of Node
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.
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.)
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.)
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.)
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).