[jdev] Reliable presence
David Waite
dwaite at gmail.com
Wed Aug 11 20:59:15 CDT 2004
The problem is state management and caching in a distributed system
XMPP ignores this problem completely. Missed updates to state are
considered non-important. Message reliability does not fix this
problem, as message reliability (or "guaranteed delivery") does not
give you an absolute guarantee - what is really guaranteed is that a
message will be delivered (probably with just once semantics) within a
timeout period, and that the sender will have a mechanism of
determining if the message was delivered within that timeout period.
With or without guaranteed delivery of presence, if state changes and
the corresponding message times out (s2s down) or the state change
does not result in a message being sent (coding error, server crash)
state will stil become out of sync.
Handling replay of state information peer-to-peer is a bad solution,
as it makes things like s2s responsible for maintaining (or having
access to) all presence state for all connections. Keep in mind also
that presence isn't a single value per user; a user may publish
multiple endpoints, may specify dynamic privacy rules to determine who
is supposed to be given access to that presence, and may directly send
different presence to specific entities (such as a MUC room).
Requiring intermediaries to maintain or have access to this state also
opens the door to manage state in other situations, such as MUC or
pubsub. Routers become active participants in the protocol.
The fundamental problem is 'what does a presence message mean'. In
truth, it indicates the availability and status of an endpoint at a
particular point in time. Over time, that presence message becomes
next to meaningless. Unfortunately today, there is no mechanism within
XMPP to even specify what time presence was set.
There are solutions which come to mind, but none which closely
resemble the current presence model in XMPP.
-David Waite
On Wed, 11 Aug 2004 11:33:43 -0700, Justin Karneges
<justin-keyword-jabber.093179 at affinix.com> wrote:
> On Wednesday 11 August 2004 11:15 am, JD Conley wrote:
> > the remote server. Thus, something like the proposed ping protocol
> > would be required, not just a connection attempt. I've spent a great
> > deal of time thinking about how to best fix this issue in our server and
> > have come to the same conclusions as Justin.
>
> Unfortunately, 4 out of 5 council members have already objected to the JEP on
> the council mailing list. This is probably some sort of record. The only
> hold-out is rob, who told me this morning that he needs to read up on JEP-79
> (AMP) before he can form an opinion.
>
> That said, would it hurt for the council to write to the public standards-jig
> so we can have an actual discussion? Better yet, can they _read_ it also?
> It's not like this is a new topic, and we even have an active thread going.
>
> -Justin
>
>
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> https://jabberstudio.org/mailman/listinfo/jdev
>
More information about the JDev
mailing list