[Standards] mobile optimizations (was: Re: Google Andro?d SDK not XMPP compliant ?)

Dave Cridland dave at cridland.net
Mon Feb 18 09:21:56 UTC 2008


On Fri Feb 15 20:16:32 2008, Tony Finch wrote:
> (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.
> 
> 
Not evil, just misunderstood. :-)

> 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.
> 
> 
Or you simply tell clients they MUST NOT attempt pipelining without  
reasonable grounds for knowing the authentication will succeed.

I think my nefarious use of EXTERNAL+TLS session resume essentially  
requires a round-trip before, whereas PLAIN would need a previous  
authentication success, and DIGEST-MD5 fast-reauth would need a  
round-trip during.


> 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.
> 
> 
There's also the odd case where a client attempts to use a  
pre-existing resource and conflicts, or where the client specifies  
the resource but the server overrides.

These sorts of things are policy/implementation issues, though - I  
think we could have a child element or two of the bind feature that  
will allow clients to know, a priori, what to expect.


> 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.
> 
> 
Stunt buffering - and that's a great term - is not always easy,  
especially with XML processing. A lot of XMPP implementations handle  
the XML streams by pushing buffers directly into the XML parser, and  
unless the XML parser tells the application exactly where each  
element ends, things are going to get unpleasant.

It's also tricky because many TLS implementations either explicitly  
must use the socket directly, or are very much easiest in that mode.  
(Example: OpenSSL is a lot easier to use with sockets, and many  
bindings only support this mode. I added buffering support to my fork  
of PyOpenSSL, so it's possible to do stunt buffering in Python, at  
least, but this probably won't help the average mobile handset).

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list