[Standards-JIG] proto-JEP: Smart Presence Distribution
richard at dobson-i.net
Thu Jun 1 09:47:48 UTC 2006
> 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.
Well it might be the end of the story for you but its still a big
failing in your spec, it doesn't have a decent level of error recovery,
its a real waste (and if you ask me not something you can truly even
describe as error recovery) to have to send the whole list again from
scratch when you get a problem with only a single one of the stanzas,
maybe even the last one you have sent out. Spin it how you like but it
would be far better if your spec were able to only have to resend only
those which did not get there.
> | 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.
Thank you, I know its nice, I'm glad you agree, when did I say it had
anything to do with presence stanzas?, the whole point of it is that you
aren't using the presence stanzas to set-up the distribution list, I
thought you had understood that.
As noted by David, and after looking at some of the various definitions
for the word multicast there is nothing wrong with our usage of this
word so please stop telling us its wrong when it isn't, it all depends
on the context, all of these definitions of multicast seem to fit with
what we are doing:
"Like a broadcast, a multicast replicates information from one source to
multiple recipients on a network"
"To transmit a message to a select group of recipients. A simple example
of multicasting is sending an e-mail message to a mailing list."
"Special form of broadcast in which copies of the packet are delivered
to multiple stations, but only a subset of all possible destinations"
"Multicast is the delivery of information to a group of destinations
simultaneously using the most efficient strategy to deliver the messages
over each link of the network only once and only create copies when the
links to the destinations split. By comparison with multicast,
conventional point-to-single-point delivery is called unicast, whereas
delivery to every node of the network is broadcast"
> 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.
Protocol verbosity??? I'm confused, how does reducing the number of
stanzas significantly and easily providing for error recovery mean its
verbose, if anything its less so due to the major reduction in the
number of stanzas the receiver has to process, instead of initially
getting say 50 presence stanzas they just get one single IQ stanza, 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.
Yes these speak of temporary losses, but these losses (that Maciek was
talking about) will be practically all due to broken TCP connections
that have yet to time out, not because of the unclean closing of the
streams, so you imagine wrongly, please read the discussion again as it
clearly talks about broken TCP connections. But in any case you will
soon see for yourself that the bug fix you have identified will not make
any real impact on stanza losses. Plenty of servers will be behind
firewalls and NATs that might be uncleanly dropping TCP connections as
David pointed out, so you will soon find for yourself that plenty of
servers do in fact have these 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.
Why would we want to introduce a "framing capable syntax"? What real
benefits would it provide over our manipulation of the to and from
attributes? I'm sorry but "feeling clean" as you describe it is plenty
of reason not to mess with things you don't need to be. Yes your
"relaying homeserver" does have plenty of reason to be in charge of that
presence goes where, that's the whole point of it controlling the
addressing information, but just because it is in control of the
addressing information it doesn't mean it should be freely changing the
content of the stanza, i.e. possibly changing the status or show
elements of the presence stanza from what they originally were, don't
> 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!
No I'm not saying they will be redundant as they are still very useful
at the application layer for ease of implementation and flow of the
protocol. I am saying that before your protocol can really work the
stream acking must be in place first throughout the network, otherwise
there will be a lot of wasteful list rebuilding happening.
More information about the Standards