[Standards-JIG] proto-JEP: Smart Presence Distribution
Carlo v. Loesch
CvL at mail.symlynX.com
Tue May 30 11:43:45 UTC 2006
Richard Dobson typeth:
| Huh???? "disabling large parts of RFC 3921 in your interserver
| communications", sorry but what are you on about? Please explain.
5.x in XMPP IM describes how to deliver presence information to other
servers and people. If you're proposing an explicit new syntax to define
recipient lists on receiving servers, you are delivering similar information
in a completely new way.
Either you keep on using XMPP IM in parallel, then you have no gain,
or you have to disable it in favor of the new list syntax, then you are
designing a new XMPP protocol, because nothing of that part of RFC 3921
is going to be used anymore.
| I've seen it, but as noted and admitted to by Philipp the protocol as
| outlined means the lists will need to be recreated over each new S2S
| connection and will only be valid for that S2S connection, as soon as
| that connection drops the list becomes invalid and needs to be
| regenerated at the next connection, this is a problem because it will
| not work very well with how xmpp/jabber servers are currently
| implemented as the presence sending code and s2s are almost always
This architectural issue sounds like a general strategic problem.
Like an ostrich Jabber puts its head under earth surface and doesn't
want to know about real life network failures and unreliability.
If this JEP enforces that you do not only route XML content packets from
different parts of your server architecture, but also expects you to properly
route exceptions and errors, this may help solve other problems, too.
So it's about time you stop ensuring stability by redundancy but also by
| completely separate, also having to resend the list every time the
| connection is established could mean an increase in bandwidth used
I think I mentioned in an other mail, that there is a special case
allowing your servers to time-out connections without losing the state.
Other than that only evil things can cause the necessity of a list refresh.
| between servers where the S2S connections frequently drop and
As long as the connections are cleanly closed or timeouted, that's fine.
It's not exactly an elaborate strategy, but if your servers are so
monolithic that the amount of open sockets is an issue, then you will
have to keep doing things this way.
| re-establish, as normally in those cases the presence stanzas would only
| get sent once, whereas with your suggestion every time the connection is
| re-established the stanza's will need to be resent again to populate the
| list, if that list doesn't actually end up being used before the
| connection drops then all that traffic would be for nothing.
No, even if you had a faulty break of the connection, it is not your duty
to immediately update the list. You can postpone it to the moment in time
when you are actually sending some information over it.
| You do not have a reliable mechanism for that due to the fact that there
| is no acknowledgement of additions and deletions which due to the
| potential unreliability of xmpp (i.e. stanzas not arriving and no
Introducing acknowledgments is like re-inventing TCP here. Especially for
such a lightweight operation like on-the-fly context lists. All we need
is proper exception handling on TCP and XMPP stream level, and the application
is stable and well-defined. Think of rosters - they have acknowledgments -
and still they aren't reliable.
| undelivered error messages being returned to the sender, i.e. lost in a
| black hole) means that the lists are not usable over multiple S2S
| connections as over time they will get more and more out of sync as the
| presence stanzas get lost.
TCP gives you errors. If your server architecture isn't a black hole,
you can implement things according to the proto-JEP and there will not
be any loss of sync. Show me a situation that the JEP doesn't handle.
| successful or not), you cannot rely on implicit additions and deletions
| as you are in this proposal.
That's incorrect. I'm sorry, your guess is just wrong.
You think a problem has to be solved in a certain way,
but there are more ways to do it, and yours only creates overhead.
More information about the Standards