[JDEV] Jabber.org vs. commercial Jabber structure

[Jeremie]

> I just browsed the FAQ and the many post of this mailing list to see if
> my question was not already answered in the past.  I didn't find it but
> if somehow I missed it I would like to apologize to the group and,
> well...  invite you to throw the appropriate rocks at me.

Heh, don't worry, jabber rocks are soft and fun, and fully parseable :)

First, I just want to point out that "jabber.org" is the Jabber Software
Foundation and the community of developers contributing to building the
protocols and architecture for Jabber, not any particular server or
project.

In the past there was one primary open source server associated with
jabber.org, but now that is just one of the numerous server
implementations and can be found at it's new home of
http://jabberd.jabberstudio.org/.

> - Multithreaded,  supporting multiprocessor servers.

Although the jabberd-1.4.2 server has multithreading via it's use of pth,
it's not "real" threads and cannot take advantage of multiprocessors (1.5
will no longer rely on pth and have this limitation).

> - Added support for server farm architecture.

There have been a few attempts at adding farming to jabberd, but none of
them ever really caught on, possibly because the 1.4 generation of the
codebase and pth wasn't the easiest to work with for such things (again,
will likely be much easier to add to 1.5).

That said, you can sort of farm a server by having many socket managers
running on different servers, but they must all go back to a central
session manager.

> - Enhanced the number of simultaneous maintained sockets from 1,000 to
> up to 25,000.

As mentioned in the post just before this, there are a few other projects
like dpsm and jpolld that can help manage more sockets, and the jabberd
project has also moved to poll() for the future.

> - Redesigned the internal database from a flat file to an optional
> database

By default there is only flat file support with jabberd-1.4.2, but there
are numerous other contributions such as xdb_sql that move the internal
data to a database.

> - Enhanced reliability.
> 
> What is the experience of this group regarding the number of concurrent
> users that the Jabber.org server can serve?  And what is its
> reliability, Jabber Inc. claims that it is potentially poor needing
> frequent restarts versus their version which supposedly is a lot more
> reliable?

The reliability part may have been true in the past, for the 1.2 release
or earlier, but the 1.4 release and the recent 1.4.2 has been quite solid.
I just checked and it's been running on jabber.org continuously over over
a month now.

All of this is only a small part of the picture and purely on a technical
basis.  I know that Jabber, Inc. has put significant time into designing
and testing their server product, and has worked hard to make the setup,
administration, commercial database integration, and scaleability work
easily and with certian guarantees, they have done the hard part of the
work that many businesses require.  Meeting those same business needs with
the various open source projects would require a good deal of time and
expertise.

Jer