[Standards-JIG] proto-JEP: Smart Presence Distribution

Carlo v. Loesch CvL at mail.symlynX.com
Thu Jun 1 06:13:16 UTC 2006


Richard Dobson typeth:
| timeout, what happens when routers fail, dsl connections drop, leased 
| lines drop, firewalls drop sockets without properly closing them, 
| someone pulls out a network cable, I could go on as there are many 
| situations where you can get broken sockets, for more info read the 
| discussion about jep-ack.

I know, I've seen the discussions, they are mostly on wether to whack or
to <ack/> but not talking about the causes. I've seen that URL weeks ago,
but all of it doesn't apply to our proto-JEP -- If a TCP is broken
enough to get stuck, well - leave it stuck until it timeouts - maybe
one day it can be re-established, in that case it is more than obvious
that the list data is no longer valid, so it is resent. End of story.

| > Then you get an error back, that something went wrong.
| > At least you get to send back the queue of outgoing things, which
| > makes it likely that involved people will find out something went wrong.
|
| It will return an error, but it wont necessarily return this error 
| immediately, if a socket ends up getting broken without being cleanly 
| closed by the TCP stack you can end up sending data to the socket for 
| possibly up to 20 minutes or more (read te jep-ack discussion) before 
| the TCP stack times out the socket and fires you an error, all the data 
| that you have sent to the socket in the mean time will then be 
| completely lost.

Yes, that is certainly a problem for some parts of the XMPP protocol
like messaging and roster management. The stuff might just get lost.
But again it doesn't apply to our proto-JEP here, as it doesn't matter
how long one server was unreachable and his TCP line muffled. Either
you do find out, that the TCP line is dead at some point, or you will
open up a new TCP line - but even then you gave up on the old one and
know it. So no matter how you turn the story around, you will become
aware that an error has occured, even if it takes hours. And of course
you can timeout first, if you don't want to wait hours - and that's an
error condition too, then.

| request
| ---
| <iq type="set" id="3433" to="multicast.receiverdomain" from="senderdomain">
| 	<list xmlns="http://jabber.org/protocol/multicast">
| 		<add>jid1 at receiverdomain</add>
| 		<add>jid2 at receiverdomain</add>
| 		<add>jid3 at receiverdomain</add>
| 		<add>jid4 at receiverdomain</add>
| 		<add>jid5 at receiverdomain</add>
| 		<add>jid6 at receiverdomain</add>
| 		<del>jid6 at receiverdomain</del>
| 	</list>
| </iq>
| 
| ack
| ---
| <iq type="result" id="3433" to="senderdomain" 
| from="multicast.receiverdomain" />

Yes, nice. Has nothing to do with good old presence stanzas, but probably
it can be done, too. Just please stop using the technical term 'multicast'
the wrong way. If this was multicast, then you would have to say SMTP has
been multicasting ever since To: Cc: and Bcc: existed. Multicast is only
when you have a tree or mesh of hosts which distribute information, like
the MBONE or IRC. XMPP always fans out things, and neither your nor 0033
are proposals, which actually implement multicasting. So isn't ours, but
at least we have a plan for that.

So in the end we have to do it your way because the least common denominator
is your opinion and your degree of protocol verbosity? Hmm.

| No its not at all, the unclean closing of TCP connections when you had 
| the opportunity to do it cleanly is just a bug and is only a tiny cause 

It's the one bug that affects our proto-JEP and so now that it is fixed
we can go on working. Also, look at all the nice user statements that
Maciek Niedzielski posted:

    "oh, my connection crashed again, so I copy-paste again"
    "just in case, I write again"
    "my connection is sth wrong, what is the last message you received?"
    "oh, you didn't get my message?"

They all speak of temporary losses, not servers being unavailable over
longer times. I can imagine these were either affected by the racing condition
on closing idle streams, or they are all on GPRS or behind evil TCP killer
firewalls. But luckily federated servers don't have those problems.

| Its not a matter of the ease of changing the content of a stanza, its a 
| matter of the desirability of doing so, allowing the content of the 

Hehe, yes I knew a discussion of principles would come along.
So why don't you introduce a framing capable syntax, so that keeping
content as is, is actually of any use? Feeling clean isn't enough of
a reason. In the case of presence, your relaying homeserver has all
reasons to be absolutely in charge of what presence goes where.
After all it is expected to send out an unavailable even for directed
presence. So going the next step of taking control over directed presence
is hardly a big thing.

| what you will think of jep-ack and the related proposals as they all 
| require acking the traffic you send over the TCP socket, which you seem 
| to hate the idea of for some reason.

Are you saying your acks will become redundant as soon as JEP-ack is
in place, thus we should relieve XMPP of all the in-application acks
and switch it to a general reliability ack system like JEP-acks or
whacks? I liked the vertical tab whacks. I doubt any client sends those!




More information about the Standards mailing list