On Fri Feb 19 11:35:20 2010, Philipp Hancke wrote:
Dave Cridland wrote:
Ah, gotcha, you're referring to smart presence distribution, and
ironically comparing the reaction of the council. How witty.
;-)
1) Without trundling back to the threads to remind myself what the
sync liabilities are, I suspect this refers to assymetric rosters,
which have remained a problem (and the current resolution is to
respond to probes on a case-by-case basis to re-symmetrize - if
that's a word - the rosters, which'd entirely break with "smart"
presence distribution). Distributed MUC is specifically designed
(one hopes) to handle synchronization of relevant state data, and
is allowed (specifically) to do all manner of weird things to
mitigate the liabilities therein.
Simple chatrooms actually do not need shared state and control. All
you
need is smarter routing.
Depends on what you're shooting for.
2) S2S compression remains our best solution to the matter of
inter-domain presence bandwidth, but I'd note we have nothing like
the issue that other protocols have. I do have some research I
need to carry out on this, but I currently lack the time. In any
case, I've read this proposal as an attempt to tackle resilience
rather than efficiency as the primary goal, so I'm not convinced
this argument is worth revisiting
In http://mail.jabber.org/pipermail/muc/2010-February/000144.html
you say
"Another distinction between the two approaches is what the core
aims
are - in PSA-style, it's to provide resilience between servers,
whereas in KD-style, it's largely to reduce redundant message
traffic
from being repeated redundantly repeated."
So you changed your mind already and think reducing redundant
redundancy
is no longer worth revisiting?
Not for presence as a whole, no. For chatrooms, I think it's worth
looking at, especially if we can gain some levels of resilience out
of it as well. Sorry, but by trying to combine two arguments, you are
muddying the waters and confusing two cases which I don't think are
the same.
Let me also clarify - if we could send IM presence once over a link
and have fan-out controlled by a foreign domain, I'd be happy with
it. But I don't think that's a practical option, given that it
requires greater trust between domains, and prevents various other
forms of control. FWIW, the same applies to PEP versus general
PubSub, I think, and these are the same protoclo, but with different
controls.
for this proposal - but the distinction of trust delegations means
different solutions may apply.
One fabulous side effect of "smart" distribution techniques, where
you
let the receiving server know who's to receive things from somewhere
is the amazing way how this protects you from SPIM. If the protocol
is
all built on unicast, there is hardly a way to detect SPIM. If a
message has to go to all recipients of a certain context, be it a
distributed chatroom or a person's presence, multicast SPIM leads to
unsubscription from the "infected" source whereas unicast SPIM is
obviously illegal and doesn't need to be delivered to the recipient.
So having proper multicast structures actually strengthens trust and
solves not only the effeciency issue.
3) I'm not sure exactly what Matt Miller intended to mean at this
point, but I suspect it relates to Peter's suggestion to get hard
data. See above - on the subject of inter-domain presence (and,
for that matter, inter-domain MUC traffic), I'm intending doing
some measurements when I can on actual field data, although my
measurements based on more theoretical cases seemed to hold up,
and the observation that the bulk of bandwidth consumption is
highly self-similar, and thus should compress well, is still valid.
No doubt. But those properties also mean that the traffic pattern is
similar to a SPIM or flood attack, making those undistinguishable.
Okay, I can go along with this, but I also suspect it's again much
more of an issue with chatroom (and PubSub) traffic than it is with
general presence (and PEP), which in general terms has an established
relationship involved as well. Luckily, this is very similar division
to the trust issue - fan-out of chatrooms and pubsub nodes is, I
think a lot more likely to be practical without any changes to the
trust model we have.
4) I understand this proposal is aimed at bringing simple
resilience for chatrooms across heterogeneous XMPP networks, very
much like IRC. I'd be interested in seeing how you'd do it. I do
think you're much better
lynX will post to muc@ about that.
placed to find a reasonable solution, and in this case, where
trust
Unfortunately, there is no single "reasonable solution". The only
common pattern is "at most once per link".
I don't think that's the only goal. I think shared state to provide
resilience is useful and important too, but I think we can require a
formalized trust relationship there.
relationships are explicitly configured, I'd expect the kinds of
solutions you're likely to propose to be more acceptable to us
annoying folk in the XMPP world.
Beware, I still consider sending stanzas without a 'to' attribute
the
most elegant approach ;-)
Sure, from some perspectives. I just think that thanks to various
other features of the architecture, doing this blindly will lead to
problems.
But I'm pretty sure you understand my perspective on this - you
pointed out in private IM that "the moderator which uses a slave
needs different information from the master than the average user" -
things like jid disclosure, etc, may indeed mean that a simple
master/slave isn't suitable for all cases, and we'll need to consider
that carefully.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
