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

Carlo v. Loesch CvL at mail.symlynX.com
Thu Jun 1 10:44:49 UTC 2006


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.




More information about the Standards mailing list