[JDEV] Jabber in the real world.

Michael Wilson mwilson at myopenapps.com
Tue Jan 23 05:38:41 CST 2001


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-----------------------




More information about the JDev mailing list