[Standards] e2e compression

[Jonathan Chayce Dickinson]

It won't work, without a lot of consideration. I suppose what needs to 
happen is:

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 <stpeter at stpeter.im> 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:  chayce.za at gmail.com
jabber: moitoi at inflecto.org

<some profound piece of wisdom>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070905/0cd69d86/attachment.bin