[Standards] mobile optimizations (was: Re: DevCon report)

Dave Cridland dave at cridland.net
Wed Feb 27 17:52:38 UTC 2008


On Wed Feb 27 16:06:23 2008, Peter Saint-Andre wrote:
> Fabio Forno wrote:
> > Though sending roster diffs helps. There is a new possible  
> approach
> > I've found only after the discussion we had: use just roster push,
> > that must implemented regardlessly any optimization. The client  
> asks
> > for the roster adding a timestamp of the last received push, and  
> the
> > server sends changes as pushes (all timestamped)
> 
> Yes, we have roster pushes so it seems like a good idea to use them  
> (in
> general I think we should make intelligent use of everything we've
> already defined, such as presence and rosters and roster pushes and  
> so
> on -- other real-time communication technologies don't have these
> features at the base level, so it's to our advantage to use them). I
> think that something like what you suggest might work well.
> 
> Also, before the devcon Dave Cridland mentioned that he didn't like  
> the
> XEP-0150 approach but at the devcon we somehow didn't hear from him  
> on
> this topic, so perhaps he could weigh in with his ideas here.

At the devcon, the more interesting discussion was concerning  
quiescing the stream, etc. We decided that, as I recall, we'd not  
bother discussing startup optimizations, mainly because we basically  
knew the score there, and with our unnamed external expert talking  
about other stuff, we concentrated on that.

So... There's three options in the roster push optimization space.  
All involve the client and server maintaining a "timestamp" for the  
roster as a whole, and/or each individual item within it. The  
timestamp might be opaque (like ETags), a strictly increasing  
sequence number, or a modified, strictly increasing, timestamp. It  
actually doesn't matter, but the latter two allow for interesting  
things.

Whichever, the server MUST include the timestamp-like thing in each  
roster push.

1) Client says "I got the roster at this point in time". Server says  
either "Then you have it." or "Then I'll send you the new roster."

This is basically the ETags method. I don't like this, because I add  
people to my Roster, and reorganize those that are there, relatively  
often, and this would incur a full dowload each time.

2) Client says "I have the roster as of this point in time". Server  
says "Here's all the changes since then.".

This is obviously the best option in terms of efficiency, but it,  
too, has problems. The key issue is that roster entries won't die -  
instead, they'll be maintained along with a timestamp when deleted,  
in order that the server can tell a client it's gone.

3) Client says "I have the roster as of this point in time". Server  
either says "Here's the changes" or "Here's the whole roster",  
depending on whether it can find all deletions.

This is basically addressing the shortfall of the above, and allows  
for a single RTT self-correcting error case. I like this one best,  
and it's pretty easy to implement.

I also have a fondness for modified strictly increasing timestamps,  
but implementors need to appreciate that computer clocks go  
backwards, so they need to remember to handle odd cases like that by  
"letting time catch up" - just using a few ms later than the last  
timestamp until the real time is greater than the last timestamp.

This would allow clients to show the "last changed" date/time of the  
roster entry in a mostly realistic manner.

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