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

Michal vorner Vaner michal.vaner at kdemail.net
Thu Jun 1 11:37:01 UTC 2006

On Thu, Jun 01, 2006 at 12:44:49PM +0200, Carlo v. Loesch wrote:
> Richard Dobson typeth:
> | 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, 
> claim, no facts.
> | 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 
> you still haven't understood the proto-JEP properly.
> no matter which part of the broad unicast fails and when, only that part
> needs to be repeated or re-established. you don't have to restart
> everything from scratch - you only need to redefine a couple of people
> on the list of one particular host, if that particular host had serious
> delivery problems.
> | would be far better if your spec were able to only have to resend only 
> | those which did not get there.
> that's what it does. thanks for talking so much before reading it closely.
> | "Like a broadcast, a multicast replicates information from one source to 
> | multiple recipients on a network"
> incorrect.
> | "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."
> incorrect. why would one invent "ip multicast" if e-mail already did it.
> | "Special form of broadcast in which copies of the packet are delivered 
> | to multiple stations, but only a subset of all possible destinations"
> just go into the IETF MMUSIC WG and ask them if these are valid
> definitions of "multicast" - they will, if they spare the time, inform
> you that these are all superficial simplifications of what multicast
> actually does.
> | "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"
> this definition is mostly correct, although the intention is that every
> packet gets sent to australia only once, so if you know people on 4
> servers in australia, xmpp will, no matter which jep we apply to it,
> send the packets 4 times towards australia. that's no longer proper
> multicast then. it is what we call 'smarticast' at best.
> | 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 
> your list generation is verbose, maybe not much more than a "broad unicast"
> of presence though, so if the good ole "broadcast" is no longer wanted, it
> might as well be an iq. we still get to send an extra <presence/> stanza
> to all links, and we have a bunch of redundant acks, since TCP is stable
> enough for the purpose. so all in all your proposal is still more verbose
> and additionally it requires an extra roundtrip for the acks which delays
> presence delivery, as dave pointed out.
> | number of stanzas the receiver has to process, instead of initially 
> | getting say 50 presence stanzas they just get one single IQ stanza, hmm.
> 50 stanzas? didn't stpeter once claim average users have 10 people in their
> rosters? so why should they have 50 people all on one server? anyway,
> amount of people doesn't matter.
> if the amount of stanzas makes a difference though, than a single iq
> with a lot of subtags is better than a series of presence stanzas.
> please elaborate what the gains are moving away from the traditional
> presence fan-out as it has always been, and on the other hand, if
> anyone is contrary to the <iq> list setting strategy, please speak up now.
> | 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.
> yes i understand the amazing manifold world of timeout problematica,
> but still the most common reason for roster asyncs could be as simple
> as server downtimes. luckily our proto-jep doesn't need to do anything
> if the other side isn't available, so it can always limit its operation
> to a healthy working connection between two entities.
> | Why would we want to introduce a "framing capable syntax"? What real 
> | benefits would it provide over our manipulation of the to and from 
> it allows for
> [x] unquoted and unparsed binary file transfers
> [x] routing and multicasting content without losing time parsing it
> [x] probably more
> even if we get xmpp to do real multicast, it's a bit sad we cannot
> use it for transparent transfers. you probably don't wanna know
> which technology is suited for all of those [x] up there.
> | "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 
> if the jep makes a precise definition on the sort of change it MUST
> make in order for the distribution system to operate correctly, that
> is a very very unfree change of an attribute, and not of the content.
> also we still haven't dismissed the option that we could as well
> use the recipients roster, since the scenario of somebody hacking his
> roster when he also needs to receive directed presence *and* needs to
> be on the same server with more recipients, makes it a rather faint
> security weakness. it's easier to talk somebody into relaying you
> somebody else's presence.
> so if we use the second scenario, we don't even need to modify directed
> presence.
> | stream acking must be in place first throughout the network, otherwise 
> | there will be a lot of wasteful list rebuilding happening.
> that is your presumption, but by all logic i can't see how a lot of
> tcp connections should keep on breaking continously when both ends
> could have closed them properly.
> but sure, we could add an extra clause that stops presence distribution
> on unreliable links. i mean, if a network connection isn't reliable, then
> it is experiencing some serious problems. then i would want important
> protocols like ssh to get all the priority. the least i need on a messed
> up network is some people's away messages.
This is just a guess, but if everyone on the list understands the
proto-JEP wrongly, isn't it wrongly written? Specs should be clear
enough anyone sees at the first glance what it does. Otherwise, it is
hard to understand and implementations will be buggy.


Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060601/51adcab0/attachment.sig>

More information about the Standards mailing list