[jdev] Re: Reliable presence

[Peter Millard]

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 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.

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
:)

pgm.