[Standards-JIG] proto-JEP: Smart Presence Distribution
richard at dobson-i.net
Thu Jun 1 18:13:36 UTC 2006
> To the servers or the server? If you are talking about one single server,
> then indeed, should the network be broken it will have to recreate the
> list just for that single server. How many people do you know on jabber.org?
> I have a pretty well distributed roster - people are a bit everywhere.
> Additionally we can use Michals hashes, so we get to keep lists across
> transport errors. Would be interesting to see how often or rare actual
> transport errors happen.
All the hashes do is allow you to detect more easily if the lists have
gone out of sync, they do nothing to help keep the lists across
> now we're talking.
> that's the kind of thing we want to bring up in our follow-up
> multicast jep that builds on top of this jep.
But the way you JEP works, i.e. being coupled into the core server means
you cannot build such things on top of your JEP as far as I can see, it
would need to be able to run as a stand alone component to be able to be
> see, it is much more useful to use the word for nothing less than
> the real thing, because it raises your aims to higher goals. :)
> if you let jep-0033 be multicast, no-one will ever sit down and
> code the real thing.
Why not? Whats your reasoning to make such an assumption? What makes you
assume people will sit down and code up your solution?
> | My suggested list generation is not verbose when directly compared to
> | your method of sending lots of individual presence stanzas to build up
> ok, this one be valid.
Good glad you admit it.
> | the list, and there are not lots of redundant acks, as I showed
> | demonstrated when initially setting up the list there is only the need
> | to send a single stanza which will get a single ack, to be classed as a
> yes, this is certainly better than acking each presence stanza, but
> still you are sending an ack every time you make a change to the list,
> whereas we know the list is healthy because our link is sane, so we
> don't need *any* ack.
How often are people actually going to be changing their lists in the
first place? How often are people actually adding and deleting contacts?
From my experience this happens once in a blue moon so making such an
issue about the acks is a little OTT.
> | bunch of acks if would have to be more than one. Also I've got no idea
> it is a bunch of acks because you have lists for every person on every
> server you are talking to. so even your initial setup will get you acks
> from all involved servers - tcp packets which are redundant because tcp
> itself already ensures the lists are safe from harm.
As already shown TCP does not ensure the lists are safe from harm,
wether you choose to believe this fact is in the end up to you.
> | what you are going on about with regards to not needing to do
> | "broadcast" any more I thought that was the whole point of both of our
> | suggestions.
> yeah ok it doesn't matter if it still looks like a traditional
> presence fan out, or it looks like a fresh new <iq/> thing.
Good i'm glad you admit it.
> | Extra presence stanza??? Not sure what you mean by this either, could
> | you please explain.
> after setting up iq you need an extra round trip for the ack, then you
> can send the <presence to=router/>, which is also one more than in our
I see, well yes, but once the list is in place this is a single presence
stanza to the list, not one that is broadcast from the sending server to
each recipient as happens now, so the bandwidth cost of this is
neglidgable and not worth even worrying about.
> | But yes it does delay the initial presence delivery, but this will only
> | happen once as the lists will not need to be rebuilt and will be able to
> | be re-used whenever they reconnect, I find it very unlikely anyone would
> same goes for our lists, since you have to apply force to break a tcp
> if both servers take care of closing links gently.
Your lists do need rebuilding (on errors) as you have already admitted,
you dont need to "apply force" to break a TCP connections, it will
usually spontaneously happen on its own.
> | if you are referring to the delay that will happen while waiting for the
> | S2S connections to establish between the domains then that's not really
> no, referring to the extra roundtrip delay for the <iq/>
If you arnt refering to the S2S connection delay then the roundtrip
delay is neglidgable and will likely be fractions of a second, hardly
something to get concerned about.
> it is the dimensions in which you and i are thinking. i say occasional
> breaks can be fixed, and it is cheaper than acking. you say breaks happen
> all the time, so fixing costs more than acking. i say breaks no longer
> happen all the time, because we enforce that servers stop closing idle
> links irresponsibly. you say, that's not enough. i say, okay, so what
> can we do now to actually find out who's right instead of keeping on
Well its up to you in the end if you want to create an unreliable
protocol. I intend to work with Michal and anyone else who is interested
to create a generic more reliable protocol, and we can see which the
community picks as the solution they like the best, a good old
competition based on the actual real world merits of each :)
> | If its true that on average there are only a few people on peoples
> | rosters then there is probably no point in even developing this
> | optimisation in the first place as it will mean it does not make any
> | real impact.
> exactly, so let's keep on going.
If you agree that its not going to make any real impact then whats the
point in creating it in the first place?
> and yes, because typically right after setting up the list, the probe
> request comes along. okay so this would be an architectural issue for
> server developers whose servers would not process the input of a single
> tcp linearily. but, does this really happen?
Yes, its how a lot of XMPP servers are architected, the bit that
processes the presence stanzas is usually completely de-coupled from the
> do you really process the
> input of ONE SINGLE tcp stream in a non temporal fashion?
Yes it can certainly happen.
> do i really
> have to take a scenario like this in consideration? how many other JEPs
> would not be able to operate if things aren't happening in the right order?
All of them pretty much, as a lot of them will use IQ based protocols
which wait until the first action has succeded before starting the next,
either that or it doesnt do any harm being out of order.
> i mean, do you get groupchat messages before the MUC has acked your entry?
> aren't there a million scenarios that can't work if you're not keeping
> the order of the stream?
You shouldnt really be relying on the order of the stream, afterall XMPP
is an asynchronous protocol.
More information about the Standards