[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