Hi Philipp!
Philipp Hancke schrieb:
> 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.
Well the cost for managing a socket higher than the cost for managing a
list. (Comparing the total cost in the complete system including the
work the OS has to do.)
Managing a list of strings instead of a single string is neither cost
expensive nor hard to implement. I'd expect that each Jabber server
implementation already has to manage other lists as well.
So for me what you said is an argument, that all servers SHOULD at least
support "passive piggybacking" (as you called the receiving part of the
protocol).
Even this part of the comparison is easier to implement than the
separation of the domain part in the JID - which has to be compared
only. In neither case you can just compare the value of the attributes
on the stream root (only domains) and the stanzas (full JIDs)
> 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.
The from and to attributes are nothing special with 1.0 streams, they
are present in 0.9 streams as well. But I also see no problem with that.
The stream is connecting to from host with the to host ... and these
hosts are routing several domains across this connection. That's just to
different layers of protocol.
(BTW: SMTP does the same. It uses a different domain in the EHLO command
than later in the address of the mail command.)
> 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?
I would not like to see active piggybacking discouraged. But maybe it
would really be a good idea to make passive support a MUST (should not
be hard to implement) while active support could get downgreaded from
SHOULD to MAY.
Matthias
--
Matthias Wimmer Fon +49-700 77 00 77 70
Züricher Str. 243 Fax +49-89 95 89 91 56
81476 München http://ma.tthias.eu/
