[jdev] Financial messaging via XMPP
dave at cridland.net
Fri Jan 25 11:12:07 CST 2008
On Fri Jan 25 16:38:37 2008, Martin Sustrik wrote:
> Thanks for extensive clarification.
> I believe I have some idea of how XMPP plugin can be implemented
> now. When we have something working I'll post the performance
> figures on this list.
I'd recommend outlining what you're proposing - ideally as a XEP -
and discussing it on the standards@ list, where you'll be most
welcome, and get a lot of useful feedback.
> The issues that still may be performance bottlenecks are:
> 1. Size of XMPP wrapper of the binary message - 360 bytes in the
> example in the article - with financial protocol like FIX/FAST the
> binary data tend to be quite small (30-40 bytes) thus 360 bytes of
> wrapping XML can extend the message size tenfold.
Well, you're probably talking about bytestreams when you say "the
article", but you only need something like:
<message from='N' to='M'><amqp xmlns='http://www.amqp.org/fix'
e='base64'>[40-50 octets of base64-encoded binary
data]</amqp></message>. Less than 360 bytes there, more than likely.
There would be more if you use PubSub, of course, which may well
prove useful. I'm not entirely sure how well topics might map to
PubSub, though routing keys should map fine.
Bytestreams themselves aren't useful to you, I think.
> 2. Compression and decompression (binary->base64->TLS
> compression->TLS decompression->base64->binary data) may cause
> latency to be worse. However, I am not sure what exactly the impact
> would be.
Well, the compression certainly introduces a throughput/latency
tradeoff, although in extreme cases it can actually be positive to
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the JDev