[Standards] UPDATED: XEP-0199 (XMPP Ping)

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed May 9 23:37:46 UTC 2007

On Wednesday 09 May 2007 11:46 am, Mridul Muralidharan wrote:
> Justin Karneges wrote:
> > On Wednesday 09 May 2007 10:39 am, Mridul Muralidharan wrote:
> >> Peter Saint-Andre wrote:
> >>> Mridul Muralidharan wrote:
> >>>> Ah, I see that the type=probe is not present in the presence packet :
> >>>> my mistake, thanks for clarifiyng !
> >>>
> >>> In fact that's a typo, there should be a type='probe' in one of the
> >>> examples.
> >>
> >> Hmm, in which case aren't we not back to any entity using probe instead
> >> of only servers ?
> >
> > This example is of a room (or room's server) doing a probe.  Clients are
> > still not supposed to probe.
> Any entity != server implies clients, components, etc.

From an RFC standpoint, there isn't any such thing as a component.  There are 
clients and servers and that's all.  Componentizing a server is an 
implementation design decision, and doesn't have much to do with protocol 
here.  Probes are allowed to come from the other side of an s2s channel.  The 
receiver does not care if it was really a "component" hiding behind that s2s 

Now, from a component design standpoint, I personally wouldn't want components 
sending probes.  I'd have the core server do the presence tracking, and a 
component would never have to poll/probe/ping these things on its own.  But 
we cannot dictate this from the RFCs.

I don't think clients should probe.  I'm fine with changing the RFC to 
restrict probes to servers only.

> probe is a mechanism for servers to discover presence - I dont see how
> it makes sense for directed presence case.

You're right.  However, lately we've been talking about using probes even when 
the presence is already known, as a way to resolve s2s problems.  In that 
case, it would be ideal if probing worked for both kinds of presence.

> > Then probes just the full jid.  The flow should could use some more
> > clarity:
> >
> > Client joins room:
> > <presence from='romeo at example.net/orchard'
> >         to='shakespeare at chat.example.com/RM'>
> >   <status>working</status>
> > </presence>
> >
> > Room (or room's server) probes presence:
> > <presence from='shakespeare at chat.example.com/RM'
> >         to='romeo at example.net/orchard'/>
> >
> > Server responds positively:
> > <presence from='romeo at example.net/orchard'
> >         to='shakespeare at chat.example.com/RM'>
> >   <status>working</status>
> > </presence>
> >
> > Or not:
> > <presence from='romeo at example.net/orchard'
> >         to='shakespeare at chat.example.com/RM'
> >         type='unavailable'/>
> And how is this different from xmpp ping ? Except for being e2e - which
> is just one hop more in this case.

Well, the e2e issue is critical, I think.  Clients don't want to be ponging 
MUC rooms if they can avoid it.

But even so, there is another difference:

C1 - S1 - S2 - C2

Suppose C2 sends C1 some directed presence.  If S2 loses connectivity with S1 
briefly, and C2 sends directed unavailable presence to C1 during this time, 
then the pings won't reveal any problem.  C1 will continue to think that the 
directed presence received earlier from C2 is valid.  In the context of C1 
being a MUC room, this would mean that C2 would remain in the room for as 
long as he stays connected to S2, even though he's really not in the room at 
all anymore.

Presence probing, however, will reveal a problem.  S2 will notice there's no 
directed presence between C2 and C1 in its tracking table when S1 goes 
probing for it, and so S2 will return unavailable presence.  This will remove 
C2 from the MUC room (C1).

> Why should it periodically probe for status ? probe was not intended for
> this imo.

As I admit above, you're right, probe was probably not intended for this.  But 
we need a way to periodically check for presence validity, and probe is one 
way to do it.

> > It's not really a special-casing so much as a completing of the protocol.
> >  It allows directed presence to be probed about just like broadcasted
> > presence. It's an un-special-casing. :)
> Yes, but why do we need it ?
> And since servers wont probes entries - why introduce it ?

They won't?  We had a thread about servers doing periodic probing, and I do 
remember there being interest in this.

> > To be honest, I see xmpp ping more as a diagnostic tool or a stopgap.
> I think it is useful in tackling ghost users in servers, muc's. and in
> other cases.

I call it a diagnostic tool, because I don't think we should be pinging over 
more than one hop in the general case.  In other words, it is fine if you 
want to have a ping tool or maybe a ping mode in a client that tells you if 
another entity is up and running, but I would never want e2e pings to be 
happening automatically.

I don't have a problem with automated single-hop pinging though.  If you want 
to ping the peer of s2s or c2s, as a way of validating the TCP connection, 
that's fine.  However, XEP-198 is a better solution for single-hop 


More information about the Standards mailing list