Step 1 (normal jabber is used to negotiate):
+------+ +------+
+---+ |Server| |Server| +----+
|Joe| <---> | | <---> | | <---> |Fred|
+---+ +------+ +------+ +----+
Step 2 (a proxy route is established):
+------+ +------+
+---+ <---> |Server| |Server| <---> +----+
|Joe| <-----+------+-------+------+-----> |Fred|
+---+ +------+ +------+ +----+
Or (jingle):
+------+ +------+
+---+ |Server| |Server| +----+
|Joe| <---> | | | | <---> |Fred|
+---+ +------+ +------+ +----+
^ ^
+------------------------------------------+
Which seems like huge overkill. Firstly, the first solution isn't what
jabber was designed for, so it is a poor idea. It would, theoretically,
work as follows:
<payload stream="proxy1"> [...b64 of original data...] </payload>The server wouldn't even look at it, it would just forward it to the next entity that is registered with that 'stream'. What's nice about it is that the server can use relatively weak (and therefore fast) compression algorithms, and leave the strong compression to the clients, who can afford it.
The second way: Jingle, seriously, c'mon, speaking of overkill! But it is nice because the server gets a LOAD off of it's shoulders.
Yep, it was a terrible idea. All I was trying to get at is that there is room left for improvement as far as compression goes, especially in terms of the impact on the performance of servers.
In terms of the 'make it work -> make it right -> make it fast' idiom, I think we are moving to the 'make it fast' stage, because XMPP is pretty good at being 'right' atm. As jabber becomes more popular is see servers falling over, just because they have so much unnecessary data to process.
Tobias Markmann wrote:
Therefore we would need a XMPP-over-Jingle XEP. ;) On 9/5/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:Jonathan Chayce Dickinson wrote:Has anyone thought of using end-to-end compression? Look at the following example: john-->myserver.org-->hisserver.org-->fred Now if we look at what happens when a message is sent: john-->compress-->myserver.org-->decompress-->interpret--> compress-->hisserver.org-->decompress-->interpret-->compress--> fred-->decompress As opposed to (with e2e compression): john-->compress-->myserver.org-->interpret-->hisserver.org--> interpret-->fred-->decompress Obviously only the payload would be compressed, the stanza would need to stay intact. Much simpler algorithms could then be used on the servers that explicitly deal with compressing XML efficiently. I know this has the potential to be a terrible idea...Not necessarily. But if people really need this, it seems better to negotiate a direct TCP connection between the two entities (via Jingle), encrypt that connection using TLS, agree to compress it using TLS or XEP-0138 compression, and then exchange whatever data is desired over that connection. Peter -- Peter Saint-Andre https://stpeter.im/
-- jonathan chayce dickinson ruby/c# developer cell: +27741863698 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] <some profound piece of wisdom>
smime.p7s
Description: S/MIME Cryptographic Signature
