[JDEV] Jabber in the real world.

[dlb]

Hi Micheal;

    I haven't worked on the Jabber server , and can't adequately address
most of your points. I'm sure a member of the server team can give you a
more thurough run-down.

It sounds like you guys have done some interesting work in developing
the proxy you mention. Is there any chance of you releasing the code
surrounding these solutions ?

* access control
* session stats
* faux http encapsulation
* clustering !!




Michael Wilson wrote:

> We're just about to deploy the beta of a Jabber-based IM system
> (initially for customer support) and I thought I might as well
> share some of the server issues that came up. My apologies if
> there are fixes for these that I'm not aware of; if this is the
> case please do let me know!
>
> * 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. Solution; filter all
>   connections through a proxy that removes all dangerous syntax
>   (discovered by some source peeking and a lot of trial-and-error).
> * 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.
> * 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).
> * Lack of broadcast/multicast message support (other than
>   groupchat, which is overkill). Fixed by implementing in proxy
>   (also put in a management console that allows most of the same
>   operations as IRC network operator privilidges).
> * Lack of session statistics reporting and conversation content
>   capture. Implemented in proxy (user-specific logging levels)
>   with optional per-domain connection quotas; the data goes into
>   MySQL (which also holds applet config details for each domain)
>   and is viewed by a HTML/PHP reporting and management interface.
> * Lack of any kind of clustering/high availability. Solution; run
>   two Jabber servers and mirror the spool directories with a
>   replication script. Run three proxy servers with cluster
>   synchronisation and use high-availability code to load-balance
>   connections across the two Jabber servers (and stop using one
>   that goes down).
>
> On the client side we're using a skinnable applet with a
> definable level of functionality which defaults to sending
> Jabber XML over port 80 (port-translated by the switches to the
> proxies, filtered then forwarded to Jabber). Since some of our
> users are sitting behind firewalls that don't allow anything
> through except email and valid HTTP, there's also a secondary
> mode that encapsulates all upbound messages in a fake HTTP post
> request; this allows the applet to work from anywhere that can
> can see the world wide web. This was somewhat complicated by the
> fact that the proxies are behind load balancing switches; since
> the main HTTP download connection and the HTTP message posts may
> be routed to different servers they have to be identified and
> sent over the peer connections (if neccessary) before being
> amalgamated and sent to Jabber.
>
> --
> | Michael Wilson               "Smart Applications - Tools for life"
> | Java Developer                           available @
> | Insight ASP LTD                   http://www.myopenapps.com
> +----------------------Open Source Innovation-----------------------
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev