[JDEV] Jabber in the real world.

[Michael Wilson]

Thomas Muldowney wrote:
>> * Server instability; the Jabber (1.2) server is fairly good as
>>   long as well behaved clients are logging on, but it's fairly
>>   trivial to crash by sending arbitary XML.
>
> What is the XML you are sending it?

The main problem with valid XML is the initial identification; if
you send a registration or logon request that fails followed by a
successful one, the socket hangs and the server stops accepting
new connections. We also tried throwing random characters and XML
fragments at the server which sometimes caused the same failure.

>  Have you tried CVS which will be 1.4 soon?

We usually only work with stable releases, but I do keep meaning
to set up and have a play with 1.4 when I get the time.
 
>> * Broken character entities and non-ASCII character handling.
>>   Fixed by escaping everything in the proxy then fixing the broken
>>   characters that come back from Jabber.
> 
> Could you be more specific?  I believe all our handling is per XML
> standards regarding CDATA and PCDATA sections.

What I suspect is happening is that Jabber is treating everything
as UTF-8. Jabber 1.2 won't accept non-ascii characters at all; it
drops the stream. This would be fine if it wasn't for the fact that it
unescapes most (but not all) escaped characters even if they're not
ascii. It also inserts a 196 character before the special character
(which I have to strip out since the client is expecting just
ISO-Latin 8 bit encoding). It would be far preferable if Jabber just
passed through escape and special characters without modification.

I logged these issues in Jaber's Bugzilla a couple of months ago, but
the
page seems to have dissappeared; I presume this has been discontinued?
 
> > * No concept of access control or virtual severs. Fixed these by
> >   implementing fine-gained (ACL) access control and messaging
> >   domains in the proxy (including presence information and
> >   per-domain connection quotas).
> 
> ACL is scheduled to be in 1.4, I'm not sure how far along it is.

Is this per user, per group or per server? Does groupchat have
IRC-style channel access control too? Certainly would be nice...

> Virtual Servers are already in and work fine.

Do they need to run on seperate port/IP combinations or will they
multiplex onto a single listening socket?
 
>> * Lack of broadcast/multicast message support (other than
>>   groupchat, which is overkill).
>
> Could you be more specific for what you are looking for?

Well, an example would be someone in the 'support' domain
sending a broadcast message of 'Anyone over there know anything
about the ADSL NAT setup?' to the 'networks' domain. Everyone
in the 'networks' domain would get this (in our client it pops
up in a seperate window). Our system also supports sending
broadcast messages to all logged in users in all domains for
things like 'Restarting all servers, please re-login in 5 mins.'
If this maps onto virtual servers in Jabber 1.4 this would mean
the ability to message all users on a particular virtual server
or the entire cluster.
 
>> * Lack of session statistics reporting and conversation content
>>   capture.
>
> There are some better statistics given by the 1.4 server, but more
> is always better in some environments =)

HR tend to say that they can never have too many metrics ;>

> > * Lack of any kind of clustering/high availability.
> 
> Have you played with jpolld at all?  This is a front end that handles TCP/IP
> multiplexing into jabber.

Nope; sounds good though. Does it hide the fact that there are actually
several back end servers from the users? Where would you run it in this
configuration (presumably on multiple machines)?

-- 
| Michael Wilson               "Smart Applications - Tools for life"
| Java Developer                           available @              
| Insight ASP LTD                   http://www.myopenapps.com       
+----------------------Open Source Innovation-----------------------