[Standards-JIG] proto-JEP: Smart Presence Distribution
Carlo v. Loesch
CvL at mail.symlynX.com
Tue May 30 13:43:27 UTC 2006
Richard Dobson typeth:
| Of course they will be used, the same rules that you currently use to
| send out the individual broadcasted stanzas you will use for building up
| the explicit list for sending the broadcasted stanzas, the only
| difference is that the stanzas are fanned out at the remote server
| rather than the local one, that is the one and only difference. If
Yes, that's how our proto-JEP operates.
| anything it is your proposal that changes how section 5.x in XMPP IM
| works more as you are using the stanzas to mean something they were not
| originally intended to, and you proposal infact entirely breaks section
| 5.1.4 (directed presence). So if anything it is my proposal that is more
Please bring up an example how 5.1.4 is broken.
| in-line with the RFCs as it doesn't break anything.
Just look at examples 2, 3, 8 and 13 of the Presence Examples in 5.5.
With your strategy in place, they all become outdated. I wouldn't say you
are breaking the RFC, you are simply not using it anymore.
| :), there is no point in going on about "jabber sticking its head in the
| sand" all extensions to protocols need to take into account of what is
No we don't have to talk about Jabber sticking its head anywhere, we
can simply start changing that. Don't tell me it is to hard to code some
error handling into your server.
If Jabber wants to move forward, it needs to change some attitudes.
Conservatism is not going to help you solve the problems it has created.
You don't design a network protocol without failure management.
| But in your proposal there is no way for either server to know if the
| list is out of sync, so they are forced to always repeatedly refresh it
As long as there wasn't an error in transmissions, there is no reason to
presume any data is lost. It's like presuming the sun could rise from the
west tomorrow. Show me an example how something can get out of sync instead
of just claiming it is so and so.
| in any circumstances that could have possibly caused it to get out of
| sync in any way, i.e. a disconnection.
A disconnection doesn't cause a loss of sync if it was properly terminated.
You have a </stream:stream> for that. The example 4.8 in RFC3920 shows
how the first server closes the stream and waits for the other side to
terminate the TCP link. So a clean shutdown of the connection doesn't
cause any loss. It's just how every sane protocol is designed.
| No its not fine as servers cannot know for sure if the connections were
| cleanly closed or timeouted, certainly not be sure enough to guarantee
| that no stanzas get lost and the lists remain in sync.
Why would that be the case. You shutdown the socket and know everything
went according the intentions of the protocol. Why would you risk on losing
stanzas for nothing, by slashing down on the connection in use? And why
would the other side not know? It's enough if one side realizes an error
has happened for the recovery mechanisms to apply. Obviously one should
still avoid creating errors in the first place.
| I see, but what if you only end up sending it once over the connection,
| its a bit of a waste, better if the sending server knows for sure who it
| successfully added or deleted from the list, then there is no need to
| constantly reset it as would be required by your proposal.
If everything is operating according to the specifications, the list can
remain intact until the next restart of a server. They could even be
persisted, but it's not necessary and may induce problems if the persistency
is not 100% trustworthy. Under reasonable circumstances even the persistency
should be trustworthy, but you guys tend to be paranoid :-) , so our
JEP doesn't rely on that. it's just not necessary.
| No using acknowledgements is just simple logic, if the network is not
Your logic is re-inventing TCP. If you're not making proper use of TCP,
then THAT is the problem.
| in the same way as I am suggesting, rosters don't automatically send
| back responses indicating whether the last request got to the other end
| or not, it is entirely up to the end user if they want to do anything
| about any subscription requests etc they receive, rosters don't
| automatically do anything about any errors they get back, or if the
| stanza was lost, the mechanism I am suggesting would have quick
| responses if the request got to the other end, if the sending server
| didn't get a response to a request it sent it can assume it didn't get
Then I presume your idea is a great plan to repair the roster sync problem,
not to address volatile context lists.
| back in sync, but the difference is it will know exactly what has
| succeeded and what probably hasn't, rather than just having to dump the
| whole list and start again as you suggest.
We don't need any extra information to know that something has gone wrong.
We have network level errors. We could add this nice idea with the checksums,
because it is lightweight, but acknowledgements is an unnecessary burden
which defeats to a certain degree the improvement on bandwidth consumption.
you are making a lightweight thing a heavyweight thing, and it's not true
that this is necessary.
| You need to have a read of the archives, reliability has already been
| discussed at length and is not something that is easy to solve as with
| things like sockets even if there is a TCP error there is no way to know
| once you have put something onto the socket whether it got to the other
| end or not, this is simply a fact of life and not something you can just
yes, that's why there needs to be a handshake when closing connections.
it's how every sane tcp application operates, and the example indicates it
too, even though i don't see it explicitely mentioned. so there is no reason
to presume something is lost. but please direct me to the point in the
archive where this discussion took place.
| has already been discussed, you just need to accept that stanzas might
| get lost and you will not get any errors back to know if it was send or not.
yes we can design a protocol on top of udp, then at least we have some
useful aspects in this.
| 1) less bandwidth consumed as the list does not need to be continually
which is based on your incorrect presumption, that lists need to be
| 2) the lists will be more likely to stay in sync
likelihood, what a weird criterium.
| 3) a more custom protocol can provide mechanisms for each server to
| request things like hashes to allow each server to check if the list is
| in sync
there is space for a hash in the to= field
| 4) the multi casting component can be far more easily decoupled from the
| main server
that's a very jabber way to think something as fundamental as one-to-many
delivery can be decoupled anywhere.
More information about the Standards