[jdev] Re: Reliable presence

[David Waite]

On Thu, 12 Aug 2004 13:14:04 -0600, Peter Millard <pgmillard at gmail.com> wrote:
> On Thu, 12 Aug 2004 01:55:59 -0500, Nolan Eakins
> <sneakin at semanticgap.com> wrote:
> > Reading this I came up with another possible solution. Your definition of
> > presence as availability at a specific time helped. It would be possible to
> > periodically send presence stanzas which would solve the problem, but doing
> > that may end up flooding the network. Doing that would be a bad idea, but
> > presence stanzas could specify when the presence will be updated again.
> 
> This doesn't get around the problem of having to deal with state for
> presence stanzas. This is a problem that I didn't fully realize until
> I had to work on a server :) What you are proposing isn't new..
> checkout the SIMPLE RFC's. They have no such thing as long lived
> presence subscriptions and require entities to continuously subscribe.
> You are proposing the same thing except for regular availability
> stranzas.
> 
> If we do this, it still requires routers to cache all of the presence
> packets that pass thru it, and "do the right thing" if they don't get
> another packet. It's these types of complications that make a protocol
> a lot more resource intensive and time consuming to implement.
>
> I really have to wonder if the added complexity of these types of
> protocol bits are really worth the gain of handling these somewhat
> "extreme" edge case scenarios.

I get breakage all the time, and I know between jabber.com and
jabber.org (with s2s funness) also has problems.

Technically, the only places presence needs to be cached would be
1. session manager needs to cache a user session's current "default"
presence, if any
2. either a client or the architectural piece responsible for
maintaining the client connection needs to request presence
periodically.

> I do agree that we see these problems more and more because of s2s
> issues. I'd argue that the issue is that various s2s implementations
> are not as reliable and robust as they should be. It's not so much a
> deficiency in the protocols as it is a deficiency in the
> implementations. I know this to be true based on how often I (as a
> j.org admin) have to restart our s2s process because it becomes
> "borked" in a variety of ways.

With infinitely reliable software and hardware and network conections,
there would of course be no issue :)

However, even if you use a transactional message queue (rather than
simple TCP socket) within your server implementation for the router to
talk to s2s, you still cannot guarantee a message written out over the
TCP socket to another s2s instance was processed correctly. You also
do not guard against the state getting changed without generating
notification messages, such as when part of a componentized
architecture goes away and comes back, possibly with a restart and a
flush of all non-persisted state.

No, the issue is that state is distributed, but without any sort of
synchronization mechanism. I see the same thing happen all the time
with presence subscriptions - I have to say I think SIMPLE (with
presence subscriptions needing to be 'renewed') got things a bit more
correct in that regard.

> Perhaps the time we're spending on this discussion could go to
> improving the jabberd 1.4.3 s2s process and we'd all be much happier
> :)

I doubt jabberd (1.x or 2.x) could really become robust enough to
really hide these issues and make them 'theoretical'.

-David Waite