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

Mridul Mridul.Muralidharan at Sun.COM
Thu May 10 12:28:27 UTC 2007

Justin Karneges wrote:
> 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 
> channel.
> 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.

Yes, but this was to solve a particular problem - and the generic
solution for that is not probe. probe would be a hack which would need
to work until we fix retransmissions between servers properly.
I am not sure if we need to introduce workarounds into the rfc.

If required, why not have an informational xep for this probe behavior
which would get deprecated later on when 198 becomes mandatory to
implement in client/server (hopefully, in the not so distant future).
This way, the rfc's remain agnostic to the implementation details.

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

Yes, I mentioned this to Peter as the only possible usecase of doing
probes like this.

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

I thought that was a possible solution until 198 is widely supported ?
Maybe 2009 cilent/server Basic spec will have 198 as mandatory to
implement !

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

But if the intent is only hop to hop, I prefer whitespace pings to a xml
ping element.
The only reason I would consider implementing this is to ping e2e.

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

Yes, agree.
We need to get 198 as standard and slowly mandate it for implementation.
Especially in context of s2s, it solves a tonne of issues.


> -Justin

More information about the Standards mailing list