[Standards] dialback: piggybacking

Philipp Hancke fippo at goodadvice.pages.de
Thu Jun 21 01:50:17 CDT 2007


Mridul Muralidharan wrote:
> This would also be change of behavior from 3920.
> Either way, it looks like we are going to introduce incompatibility with 
> 3920.
> So it would be better to just remove support for piggybacking.
> I am not sure what sort of gain we get by having piggybacking around, 

It saves your server (and the receiving server) some sockets.
The cost is increased effort (on behalf of the receiving server) for
checking to/from on _every_ packet, e.g. you have to check for the
domain being contained in a list of validated domains instead of doing a
string comparision.

> but the relative increased complexity does lead to fragile 
> implementations in s2s - even vanilla dialback + tls required + use/not 
> use of 'xmpp 1.0', and combinations seems to have issues across servers.

Should there be piggybacking over 1.0 streams? I have (mostly
aesthetical) objections against sending a from/to combination in the
stream header and then doing piggybacking with another from/to
combination.

Most of the complexity of piggybacking must be implemented on the
originating server. There are (lots of) pitfalls when deciding whether
to use piggybacking on 1.0 streams which are encrypted by TLS or
authenticated by SASL, etc.
Yet, as the spec does not mandate that you MUST reuse a connection, you
don't have to implement 'active' piggybacking.

What about discouraging active usage ("you don't want to implement
that") while keeping 'passive' support (on the receiving  server) for
backward compability?

Philipp


More information about the Standards mailing list