On Fri, 15 Feb 2008, Dave Cridland wrote:
>
> Both are really scary. I've always been a big fan of the detailed round-trip
> analysis at the end. I'm hoping Tony will notice this thread and do something
> similar for XMPP.
3920bis already has some nice examples which provide a great starting
point for round-trip optimization. XMPP's connection setup is very similar
to SMTP's, so I don't think it would be all that difficult to adapt
quickstart. There are a few significant differences, though:
(1) In XMPP the client speaks first. This is a win for XMPP compared to
SMTP, since it allows the client to piggyback useful information in the
first data-carrying packet of the TCP connection. SMTP requires evil hacks
to persuade paranoid servers not to reject clients that want to speak
earlier than is traditional.
(2) The XMPP server includes the stream features in its first utterance,
which is again a win for XMPP compared to SMTP - no wasted round trip for
EHLO.
(3) XMPP has resource binding, which is a lose compared to SMTP - an extra
round trip. More about this below.
The essence of my quickstart extension was to work out a safe way of
pipelining as much of the initial protocol negotiation as possible. I'm
not so familiar with XMPP as SMTP, but I don't remember RFC 3920 saying
much about pipelining. Is there anything to prevent a connection startup
along the following lines?
C: <stream>
<starttls/> <!-- hope for the best -->
S: <stream>
<features/>
<proceed/> <!-- the bet paid off -->
C: TLS hello
S: TLS stuff
C: TLS again <!-- with a TLS session cache the client
could even start talking now -->
S: TLS finish
<stream> <!-- hey that's a bit presumptuous -->
<features/>
C: <stream> <!-- but the client always asks for a stream -->
<auth mechanism="PLAIN">BASE64</auth>
<stream> <!-- really sure that password is right -->
<iq><bind/></iq> <!-- keen as mustard -->
<presence/> <!-- if all goes well ... -->
S: <stream> <!-- ... the man from del monte says yes -->
<features/>
<success/>
<stream>
<features/>
<iq><bind><jid/></bind></iq>
For really tight optimisation, I expect the trickiest part will be dealing
with the stream restart after SASL negotiation, especially when there is a
failure. The simplest solution is to require a round trip at that point.
Otherwise you'd have to introduce a new error response to deal gracefully
with what looks to the server like an attempt to nest streams after a SASL
failure, when the client expected a stream restart after a SASL success.
Resource binding is interesting because either end can choose the
resource. It's much easier to pipeline if the client specifies it, since
that means it doesn't have to wait for information from the server. How
common is it for clients to let servers choose their resource?
Latency-sensitive clients should be encouraged not to.
The pipelined session above is 4 round trips, compared to 8 in 3920bis
section 10. It could be reduced to 3 with a TLS session cache. If you are
willing to specify some stunt buffer handling then it is possible to shift
the TLS hello into the client's first packet and save another round trip.
However this requires some really quite tricky juggling of the XML and TLS
layering which might not even be possible on many platforms.
I'm not going to the devcon, I'm afraid, nor am I planning to go to any
IETFs in the near future. (Dublin would have been tempting if the location
weren't nearly as far away from the city centre as Cork.)
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
GERMAN BIGHT: EAST VEERING SOUTHWEST 3 OR 4, OCCASIONALLY 5 LATER. MODERATE.
FAIR. GOOD.
