Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
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 particular socket or is it in OS directly? 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 faster. But thats a problem with the OS. If a OS looses the interface where the TCP connection is bound, it should signal the applications that those TCP connections are no longer valid, right? FYI, the last time I discussed Pings on a client context scenario, we decided on: * whitespace pings each 45 seconds (to keep NATs happy); * Requirement to have a XMPP ping sent if more than 45 seconds of inactivity is detected. The second point is worded like that because we don't immediately send the XMPP ping. We wait 5 minutes or until the user needs it (so the next time we send any stanza we also send the ping). Best regards, -- HIId: Pedro Melo SMTP: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED]
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
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 faster. b) use NetworkManager to get notifications about network environment changes (new networks, unplugged cables) and react to notifications accordingly. (IIRC Windows has a similar facility too.) That won't help, you can still be connected to your routeur / local network but jabber server is no more available. It helps the test scenario you presented us with, unplugging of ethernet cable.. Most OSs have some sort of notification for this. I know Mac OS X has, and I think Linux also. And Tomasz mentions windows too. Best regards, -- HIId: Pedro Melo SMTP: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED]
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
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. And Tomasz mentions windows too. For windows I don't know how to do. I haven't really serched though. For linux we use dbus to communicate with netowork manager. -- Yann
[jdev] Financial messaging via XMPP
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 plugin to our software to find out how it fits financial market's needs. However, being new to XMPP I have no idea where to start. Can you point me to some explanation of how a high-volume stream of asynchronous opaque binary messages can be passed via XMPP? Thanks for help. Martin
Re: [jdev] Financial messaging via XMPP
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.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Financial messaging via XMPP
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 file). It could also be useful for any kind of low-bandwidth activity, such as a chess game or a shell session. What we want to do is high-volume transfer. Martin Tomasz Sterna wrote: 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
Re: [jdev] Financial messaging via XMPP
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 that are already answered by other people - I've seen Maciek's reply but left my similar comments in - and I apologise if I've got bits of AMQP wrong - I've spent not much more than an hour learning it. On Fri Jan 25 15:02:32 2008, Martin Sustrik wrote: 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 Not really - assuming the binary message is incompressible to begin with, the base64 encoding is recovered through compression - XMPP gives you this both by XEP-0138 and by TLS. On the assumption that you care about bandwidth, you'll have compression on, and your messages will be compressed anyway. Equally, they'll potentially be end-to-end encrypted, too. Rather oddly, AMQP contains nothing about either compression nor encryption. I'd have thought the latter would be important in financials. (Oh, and that SASL profile is incomplete - SASL can negotiate encryption too, but there's no indication of where this might kick in, nor any MTI mechanisms). 3. There's no way to do zero-copy as the message has to be translated on both ends of the connection Sure. But then again, a lot of the data in AMQP needs to be copied anyway to circumvent alignment issues, handle buffering, queuing, etc. Unless you're sending really big chunks of longstr data about, the impact is likely to be low - and even if you are, it's just one more codec. For servers, where this would be the highest impact, it seems very unlikely that any data is going to be examined anyway - servers look at routing keys and topics, and more or less leave everything else untouched, so it'd seem reasonable to stick topics and routing keys in XML, and then leave the message payload as a blob. All this assumes that the messages can't be formatted as XML, of course. 4. All the messages have to be acknowledged. No no-acknowledge mode exists. message/ is unacknowledged, iq/ is acknowledged. (To put it another way, iq/ are like your Request/Response frames.) 5. There's no batch acknowledge functionality (acknowledging sequence of messages using single acknowledge). Depends what you mean by this. If you use iq/, then no, but then again, these can be acknowledged end-to-end out of order, just as Request/Response frames do in AMQP. If you mean across a connection, then look at XEP-0198, which provides precisely this, as well as several other useful features for reliability. (And much better than AMQP's heartbeat frames, too, IMO). 6. Pipelining of acknowledges is allowed, but discouraged. (The sender need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize possible rate-limiting penalties.) That's a RECOMMENDED - a SHOULD not a MUST - and only for bytestreams. If you're sending message/ stanzas with binary content, there's no need to concern yourself with whether the endpoint is acknowledging, since it won't be. Worth noting that bytestreams are for arbitrary length data - while AMQP does in principle allow frames of several G (assuming they're made up of multiple longstrs, for example), I'm under the impression that individual frames tend to be relatively small, and would map to a single XMPP stanza. I'd suggest sitting down and examining RFC3920bis, and familiarizing yourself with the general concepts. XMPP will not be as efficient as AMQP, but the difference need not be huge. On the other hand, the potential gains coming from using XMPP are very great indeed, giving you improvements in security and multiple sites to name but two. I hope this helps. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [jdev] last presence confusion
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) reply to the presence probe by sending to the user the full XML of the last presence stanza of type unavailable received by the server from the contact, or (2) not reply at all. So a nice server will return the last unavailable presence information (with a Delayed Delivery flag), thus obviating the need for a flood of jabber:iq:last requests. How about emphasizing the first option as a SHOULD? This would hopefully encourage new servers to always reply, while not causing existing servers to become non-compliant. 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. The price of avoiding a jabber:iq:last flood. Sounds like the caps discussion. :) -Justin
Re: [jdev] last presence confusion
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 presence stanza of type unavailable received by the server from the contact, or (2) not reply at all. So a nice server will return the last unavailable presence information (with a Delayed Delivery flag), thus obviating the need for a flood of jabber:iq:last requests. 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. The price of avoiding a jabber:iq:last flood. Sounds like the caps discussion. :) But jabber:iq:last flood is not obligatory ;) -- Maciek Niedzielski xmpp:[EMAIL PROTECTED]
Re: [jdev] last presence confusion
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 that as an objection to the modified text in rfc3921bis? Not an objection. But I am a bit worried by this change when I look at my roster. However, at the same time I know that my roster is most probably not a very typical one. Do we have any stats? What's the percent of offline contacts? And what's typical roster size? Maybe it doesn't matter that presence list increases 3 times if this means increasing from 3 to 9 presence stanzas? I have 1770 people in my roster, so yes I'm concerned. :) Other idea: even if this becomes a SHOULD, we can at the same time define a XEP that allows to control this behavior (because I don't think putting this into RFC itself is a good idea). -- Maciek Niedzielski xmpp:[EMAIL PROTECTED]
[jdev] XMPP user behavior
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 clients in real XMPP environments. Probably there are simulation programs that already implement XMPP users for stress testing purposes (except for tsung - I am not very familiar with erlang :)) ?! I would be very grateful for your information! Thanks in advance! - Matthias
Re: [jdev] last presence confusion
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: So a nice server will return the last unavailable presence information (with a Delayed Delivery flag), thus obviating the need for a flood of jabber:iq:last requests. How about emphasizing the first option as a SHOULD? This would hopefully encourage new servers to always reply, while not causing existing servers to become non-compliant. 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 that as an objection to the modified text in rfc3921bis? Not an objection. But I am a bit worried by this change when I look at my roster. However, at the same time I know that my roster is most probably not a very typical one. Do we have any stats? What's the percent of offline contacts? And what's typical roster size? Maybe it doesn't matter that presence list increases 3 times if this means increasing from 3 to 9 presence stanzas? I have 1770 people in my roster, so yes I'm concerned. :) I'll look up some stats on the jabber.org service to see what the average roster size is. It seems funny that it should be a concern if all of your contacts are available at the same time. It is possible for it to happen, and your client and internet connection shouldn't explode if it does. However, maybe it is best to optimize out the offline contacts, if a presence response from an offline contact isn't useful enough to justify the increase in traffic. My interest in having the server return a presence response for every contact was to aid in determining when a client login is complete. Right now there's really no way to know when a client is finished receiving an initial list of presence. Clients often want to give the user a notification when presence activity changes, but only for changes after the initial list. Psi considers the initial presence list to be received once 10 seconds have passed after the roster was received. This is, of course, not very accurate, and when Peter takes more than 10 seconds to login, probably 1000 contacts trigger sound events. However, maybe there's a better solution to the initial presence list problem. That clients may want jabber:iq:last information available for all contacts, and without polling for it, is valid, IMO. It relates very much to the desire to have jabber:iq:version information without polling. I smell a push-based solution ahead... -Justin
Re: [jdev] XMPP user behavior
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 statistics or other approaches that cover the behavior of XMPP clients in real XMPP environments. Probably there are simulation programs that already implement XMPP users for stress testing purposes (except for tsung - I am not very familiar with erlang :)) ?! I would be very grateful for your information! There's also JabSimul (http://ejabberd.jabber.ru/files/other/jabsimul.tar.gz) and The Jabber Test Suite (http://jabbertest.sourceforge.net/). I have not tried either of them--I just know that they exist. -Mark
Re: [jdev] last presence confusion
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 Delivery flag), thus obviating the need for a flood of jabber:iq:last requests. How about emphasizing the first option as a SHOULD? This would hopefully encourage new servers to always reply, while not causing existing servers to become non-compliant. 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 that as an objection to the modified text in rfc3921bis? Not an objection. But I am a bit worried by this change when I look at my roster. However, at the same time I know that my roster is most probably not a very typical one. Do we have any stats? What's the percent of offline contacts? And what's typical roster size? Maybe it doesn't matter that presence list increases 3 times if this means increasing from 3 to 9 presence stanzas? I have 1770 people in my roster, so yes I'm concerned. :) I'll look up some stats on the jabber.org service to see what the average roster size is. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Financial messaging via XMPP
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. Not really. The high-volume distribution scenarios tend to appear in closed environments where encryption is not required. I don't expect XMPP to be really well-performing here, but there's no much point of using XMPP is such an environment anyway. I'd agree with that. Slipping on a work hat for a moment, we - Isode - use a mostly binary messag passing protocol for internal messaging inside our applications, although the payloads often turn out to be XML. We have considered using XMPP directly, but dropped it for the same efficiency reasons you've cited, but equally, we are planning on using XMPP for various out-bound interoperability and integration issues. On the other hand, in low-volume over-the-internet messaging, XMPP may be interesting. Actually, I am starting to like the idea of the plug-in - not least because there is an active community around XMPP that may help with implementing particular features. The other way round, this may be an interesting toehold in financials for XMPP community. Absolutely - also there's considerable usage of XMPP within the financials anyway, so enabling various tie-in technologies makes sense. The latency increases of running over XMPP, for example, would be far outweighed by having a stock-ticker in Psi, say. You also need to define low-volume for this community - I suspect your low-volume equates to, or exceeds, our flood. :-) Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [jdev] Financial messaging via XMPP
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 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 both. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [jdev] Financial messaging via XMPP
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. 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. 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. Richard
Re: [jdev] Financial messaging via XMPP
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 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. 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. Martin Dave Cridland wrote: 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 that are already answered by other people - I've seen Maciek's reply but left my similar comments in - and I apologise if I've got bits of AMQP wrong - I've spent not much more than an hour learning it. On Fri Jan 25 15:02:32 2008, Martin Sustrik wrote: 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 Not really - assuming the binary message is incompressible to begin with, the base64 encoding is recovered through compression - XMPP gives you this both by XEP-0138 and by TLS. On the assumption that you care about bandwidth, you'll have compression on, and your messages will be compressed anyway. Equally, they'll potentially be end-to-end encrypted, too. Rather oddly, AMQP contains nothing about either compression nor encryption. I'd have thought the latter would be important in financials. (Oh, and that SASL profile is incomplete - SASL can negotiate encryption too, but there's no indication of where this might kick in, nor any MTI mechanisms). 3. There's no way to do zero-copy as the message has to be translated on both ends of the connection Sure. But then again, a lot of the data in AMQP needs to be copied anyway to circumvent alignment issues, handle buffering, queuing, etc. Unless you're sending really big chunks of longstr data about, the impact is likely to be low - and even if you are, it's just one more codec. For servers, where this would be the highest impact, it seems very unlikely that any data is going to be examined anyway - servers look at routing keys and topics, and more or less leave everything else untouched, so it'd seem reasonable to stick topics and routing keys in XML, and then leave the message payload as a blob. All this assumes that the messages can't be formatted as XML, of course. 4. All the messages have to be acknowledged. No no-acknowledge mode exists. message/ is unacknowledged, iq/ is acknowledged. (To put it another way, iq/ are like your Request/Response frames.) 5. There's no batch acknowledge functionality (acknowledging sequence of messages using single acknowledge). Depends what you mean by this. If you use iq/, then no, but then again, these can be acknowledged end-to-end out of order, just as Request/Response frames do in AMQP. If you mean across a connection, then look at XEP-0198, which provides precisely this, as well as several other useful features for reliability. (And much better than AMQP's heartbeat frames, too, IMO). 6. Pipelining of acknowledges is allowed, but discouraged. (The sender need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize possible rate-limiting penalties.) That's a RECOMMENDED - a SHOULD not a MUST - and only for bytestreams. If you're sending message/ stanzas with binary content, there's no need to concern yourself with whether the endpoint is acknowledging, since it won't be. Worth noting that bytestreams are for arbitrary length data - while AMQP does in principle allow frames of several G (assuming they're made up of multiple longstrs, for example), I'm under the impression that individual frames tend to be relatively small, and would map to a single XMPP stanza. I'd suggest sitting down and examining RFC3920bis, and familiarizing yourself with the general concepts. XMPP will not be as efficient as AMQP, but the difference need not be huge. On the other hand, the potential gains coming from using XMPP are very great indeed, giving you improvements in security and multiple sites to name but two. I hope this helps. Dave.
Re: [jdev] Financial messaging via XMPP
iq stanzas need a reply (and sometimes this reply is just an acknowledge). message stanzas are not acknowledged. Great! I've missed that. Martin
Re: [jdev] Financial messaging via XMPP
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 TCP stream, so probably it's not so interesting.. 4. All the messages have to be acknowledged. No no-acknowledge mode exists. iq stanzas need a reply (and sometimes this reply is just an acknowledge). message stanzas are not acknowledged. 5. There's no batch acknowledge functionality (acknowledging sequence of messages using single acknowledge). There are amore advanced acking extensions, but they are still being developed and are not really implemented. -- Maciek Niedzielski xmpp:[EMAIL PROTECTED]
Re: [jdev] Financial messaging via XMPP
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 to be translated on both ends of the connection 4. All the messages have to be acknowledged. No no-acknowledge mode exists. 5. There's no batch acknowledge functionality (acknowledging sequence of messages using single acknowledge). 6. Pipelining of acknowledges is allowed, but discouraged. (The sender need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize possible rate-limiting penalties.) Therefore, my feeling is that XMPP can be used for low-volume transfer (say 10,000 messages/second), but it is not suitable for high-volume transfer (millions messages/second). Anyway, even throughput of several thousands of messages a second is viable in some financial scenarios, so we'll dig into XMPP a bit more. Thanks! Martin
Re: [jdev] Financial messaging via XMPP
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 cannot paste binary data directly into XML, so you also cannot put it directly into XMPP. -- Maciek Niedzielski xmpp:[EMAIL PROTECTED]
Re: [jdev] Financial messaging via XMPP
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, and besides, any SSL/TLS transport will nullify that with compression automatically. There's also always CDATA and #-style encoding for binary data, but that doesn't let you send \0. -- Jefferson Ogata [EMAIL PROTECTED] NOAA Computer Incident Response Team (N-CIRT) [EMAIL PROTECTED] Never try to retrieve anything from a bear.--National Park Service
Re: [jdev] Financial messaging via XMPP
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, 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? Martin
Re: [jdev] Financial messaging via XMPP
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, jingle, etc). How opaque are the messages? Could they be reformatted as XML? -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] Financial messaging via XMPP
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 candidate for high-volume messaging, right? Martin
Re: [jdev] last presence confusion
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 obviating the need for a flood of jabber:iq:last requests. How about emphasizing the first option as a SHOULD? This would hopefully encourage new servers to always reply, while not causing existing servers to become non-compliant. 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 that as an objection to the modified text in rfc3921bis? Not an objection. But I am a bit worried by this change when I look at my roster. However, at the same time I know that my roster is most probably not a very typical one. Do we have any stats? What's the percent of offline contacts? And what's typical roster size? Maybe it doesn't matter that presence list increases 3 times if this means increasing from 3 to 9 presence stanzas? -- Maciek Niedzielski xmpp:[EMAIL PROTECTED]
Re: [jdev] last presence confusion
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 the full XML of the last presence stanza of type unavailable received by the server from the contact, or (2) not reply at all. So a nice server will return the last unavailable presence information (with a Delayed Delivery flag), thus obviating the need for a flood of jabber:iq:last requests. How about emphasizing the first option as a SHOULD? This would hopefully encourage new servers to always reply, while not causing existing servers to become non-compliant. 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 that as an objection to the modified text in rfc3921bis? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Financial messaging via XMPP
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 disposal, there is nothing stopping high-volume messaging over XMPP if you control the infrastructure. Richard
Re: [jdev] Financial messaging via XMPP
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 tend to appear in closed environments where encryption is not required. I don't expect XMPP to be really well-performing here, but there's no much point of using XMPP is such an environment anyway. On the other hand, in low-volume over-the-internet messaging, XMPP may be interesting. Actually, I am starting to like the idea of the plug-in - not least because there is an active community around XMPP that may help with implementing particular features. The other way round, this may be an interesting toehold in financials for XMPP community. Martin
