On Fri, 2008-01-25 at 11:52 AM, Matthias Stiller wrote:
> I am currently writing my bachelor thesis about performance measurings
> concerning XMPP. One chapter will deal with the simulation of user
> (clients) behavior. Due to this fact I would like to know if someone of
> you is aware of statistic
Hi,
I am currently writing my bachelor thesis about performance measurings
concerning XMPP. One chapter will deal with the simulation of user (clients)
behavior. Due to this fact I would like to know if someone of you is aware
of statistics or other approaches that cover the behavior of XMPP clien
On Friday 25 January 2008 11:09 am, Peter Saint-Andre wrote:
> Maciek Niedzielski wrote:
> > Peter Saint-Andre wrote:
> >> Maciek Niedzielski wrote:
> >>> On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
> On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
> > S
Peter Saint-Andre wrote:
Maciek Niedzielski wrote:
Peter Saint-Andre wrote:
Maciek Niedzielski wrote:
On the other hand, usually just 1/3 of my roster is online. So if
server starts sending presence for all contacts,
initial "presence flood" from the server increases 3 times.
So do I take th
Maciek Niedzielski wrote:
Peter Saint-Andre wrote:
Maciek Niedzielski wrote:
On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
So a nice server will return the last unavailable presence information
(with a Delayed D
Peter Saint-Andre wrote:
Maciek Niedzielski wrote:
On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
So a nice server will return the last unavailable presence information
(with a Delayed Delivery flag), thus obviati
Maciek Niedzielski wrote:
On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
2. Else, if the contact has no available resources, the server MUST
either (1) reply to the presence probe by sending to the user
Justin Karneges wrote:
On Friday 25 January 2008 7:06 am, Maciek Niedzielski wrote:
On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
(1) reply to the presence probe by sending to the user
the full XML of the last pr
On Fri Jan 25 17:07:48 2008, Martin Sustrik wrote:
Richard,
Base64 is trivial to compute and as far as TLS is concerned surely
being financial information you would be required to have it
encrypted? The encryption rather than the compression part is
likely to be the most CPU intensive part.
On Fri Jan 25 16:38:37 2008, Martin Sustrik wrote:
Thanks for extensive clarification.
No problem.
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 p
Richard,
Base64 is trivial to compute and as far as TLS is concerned surely
being financial information you would be required to have it
encrypted? The encryption rather than the compression part is likely
to be the most CPU intensive part.
Not really. The high-volume distribution scenarios ten
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.
Compression will solve much of this.
2. Co
Dave,
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.
The issues that still may be performance bottlenecks are:
1. Size of XMPP wrapper of the binary mess
I was going to wade in on this one sooner, but I wanted to read the
AMQP specification first. It strikes me that the bulk of the
specification actually maps onto XML (and, by inference, XMPP) quite
well, so I'm a little surprised by the conclusion you draw.
I apologise for answering points
On Friday 25 January 2008 7:06 am, Maciek Niedzielski wrote:
> On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
> > On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
> > >2. Else, if the contact has no available resources, the server MUST
> > >either (1) re
stanzas need a reply (and sometimes this reply is just an
acknowledge). stanzas are not acknowledged.
Great! I've missed that.
Martin
On Fri, Jan 25, 2008 at 04:02:32PM +0100, Martin Sustrik wrote:
> 2. Binary content has to be translated into Base64, adding 1/3 of
> overhead to message size
You can do "real" binary using direct p2p connections, they way we do
file transfers. But then you'd turn XMPP into a tool to negotiate a T
On Sat, Dec 22, 2007 at 12:23:38PM -0800, Justin Karneges wrote:
> On Thursday 20 December 2007 2:52 pm, Peter Saint-Andre wrote:
> >2. Else, if the contact has no available resources, the server MUST
> >either (1) reply to the presence probe by sending to the user the
> >full
Thanks for prompt resposes everyone.
So, as I understand it :
1. XMPP can be used for sending opaque messages, however, there are
several limitations:
2. Binary content has to be translated into Base64, adding 1/3 of
overhead to message size
3. There's no way to do zero-copy as the message has
Messages are user-defined. It may be XML, but often it's highly
compressed binary data.
So AFAIU, XMPP is not a serious candidate for high-volume messaging,
right?
No, wrong, as with anything it will all depend on the capacity of your
servers and the bandwidth you have available at your disp
On Fri, Jan 25, 2008 at 02:24:27PM +0100, Martin Sustrik wrote:
> Not using public servers is ok. However, base64 means not only that the
> message is longer, but also that is has to be transformed from binary to
> base64. No way around that? No binary data in XMPP?
XMPP is based on XML. You cann
On 2008-01-25 13:24, Martin Sustrik wrote:
Not using public servers is ok. However, base64 means not only that the
message is longer, but also that is has to be transformed from binary to
base64. No way around that? No binary data in XMPP?
The added length of base64 encoding is not a big deal,
Even in the XMPP world, high-volume binary streams are preferably done
out-of-band (socks5, jingle, etc). How opaque are the messages? Could
they be reformatted as XML?
Messages are user-defined. It may be XML, but often it's highly
compressed binary data.
So AFAIU, XMPP is not a serious
Some servers on the public jabber network throttle high-bandwidth connections.
Since you'd probably not be using public servers this would not be a problem.
Also note that the base64 encoding used in this spec increases the payload
size by one third.
Not using public servers is ok. However,
On Jan 25, 2008 1:10 PM, Martin Sustrik <[EMAIL PROTECTED]> wrote:
> Can you point me to some explanation of how
> a high-volume stream of asynchronous opaque binary messages can be
> passed via XMPP?
Even in the XMPP world, high-volume binary streams are preferably done
out-of-band (socks5, ji
On Friday January 25 2008, Martin Sustrik wrote:
> Hm,
>
> Any idea why does the specification insist on low-bandwidth data transfer?
Some servers on the public jabber network throttle high-bandwidth connections.
Since you'd probably not be using public servers this would not be a problem.
Also n
Hm,
Any idea why does the specification insist on low-bandwidth data transfer?
"It is likely to be useful for sending small payloads, such as files
that would otherwise be too cumbersome to send as an instant message
(such as a text file) or impossible to send (such as a small binary
image fi
On Pt, 2008-01-25 at 12:10 +0100, Martin Sustrik wrote:
> Can you point me to some explanation of how
> a high-volume stream of asynchronous opaque binary messages can be
> passed via XMPP?
http://www.xmpp.org/extensions/xep-0047.html
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.
Hi all,
We are a company making financial messaging (www.zeromq.org). As for
now, we were mostly focused on AMQP, however, I've noticed several
discussions where the bottom line was: "What's AMQP good for, given that
we can do the same thing via XMPP?"
So, we would actually like to make XMPP
Pedro Melo wrote:
It helps the test scenario you presented us with, unplugging of ethernet
cable..
Indeed, but we already have notwork manager implementation. This senario
was just an example.
Most OSs have some sort of notification for this. I know Mac OS X has,
and I think Linux also. An
On Jan 23, 2008, at 6:36 PM, Yann Leboulanger wrote:
Tomasz Sterna wrote:
On Śr, 2008-01-23 at 17:21 +0100, Yann Leboulanger wrote:
Why do you want to tune it?
Because currently if I unplug my internet cable, my client detect
connectut after several minutes, and I'd like it to detect it
f
On Jan 23, 2008, at 4:21 PM, Yann Leboulanger wrote:
Tomasz Sterna a écrit :
On Śr, 2008-01-23 at 17:12 +0100, Yann Leboulanger wrote:
So is it really possible to find reasonable values for all those
parameters that I don't know what they really do?
Is it tunable from python for a particula
32 matches
Mail list logo
