Expose API in Smack to do XEP-0198 server ping

[Georg_Lukas]

I’d like to use the 0198 ack mechanism to ping the server, as a light-weight alternative to XEP-0199.

The current API exposes XMPPTCPConnection.addStanzaAcknowledgedListener() which allows to track individual stanzas and requestSmAcknowledgement() to send a “ping” to the server.

However, if there were no actual stanzas transmitted since the last <r/>, the StanzaAcknowledgedListener won’t have any stanzas to acknowledge, and so it won’t be called.

I propose the following changes:

• implement an additional Listener API that is triggered on each element received from the server, returning the @h value.
• expose the currently expected @h value as a return value from requestSmAcknowledgement() - this will allow to match the response to the that was requested by the client code.

[Flow]

Is there any reason not to design this a high level API, e.g.

SmackFuture<Long> XMPPTCPConnection.requestServerSmHeight()

?

[Georg_Lukas]

If you go high-level, the actual value of @h doesn’t play a role. The important thing is to ensure that the server actually does respond to the specific I send, so that I can measure the RTT latency. Example:

• Smack sends <r/> on its own behalf
• Some time passes without new stanzas
• I send an <r/> via requestServerSmHeight() (the anticipated @h value is the same)
• The <a/> corresponding to the first <r/> arrives, so the Future succeeds prematurely
• The second <a/> arrives in silence.

Ideally, I want something like a blocking/nonblocking XMPPTCPConnection.measureServerLatencyOrTimeout(int timeout_ms) which automatically decides to use 0198 on enabled sessions or PingManager otherwise.

[Flow]

@Georg_Lukas

If you go high-level, the actual value of @h doesn’t play a role.

Maybe, but is available anyways and it doesn’ hurt to make it avaialble via the Future.

@Georg_Lukas

The important thing is to ensure that the server actually does respond to the specific I send

Ok, you didn’t not mention that this was a requirement. Then, of course, due to how SM <r/> and </a> are designed, you probably can not use the API is suggested.

@Georg_Lukas

XMPPTCPConnection.measureServerLatencyOrTimeout(int timeout_ms) which automatically decides to use 0198 on enabled sessions or PingManager otherwise.

So your use case is to measure the client to server latency? Is there any reason to not simply use always XMPP pings (XEP-0199)? It appears that would be much simpler and avoid a lot of complexity compared to abusing Stream Management requests if available and fallback to XEP-0199 approach.

[Flow]

@Flow

Then, of course, due to how SM <r/> and </a> are designed, you probably can not use the API is suggested.

I think I have to correct myself here slightly: It should probably be possible to implement the requestServerSmHeight() method so that it yields the result of the <a/> that is triggered as result of the method invocation.

[Georg_Lukas]

@Flow

So your use case is to measure the client to server latency?

Okay, so now you got me. I should have rolled back from “I try to forward-port the old smack3-based mess into a new smack4-based mess” to whatever I actually want to achieve.

My ultimate goal is to measure/probe the health of the connection as follows:

• after a certain configurable interval without receiving any data from the server (typically 15mins), I want to probe the connection:
  • send an <r/> or alternatively a <ping>
  • if it is responded to within another configurable interval (typically 60s), everything is alright
  • if no response comes in, fire a callback that does the instantShutdown() + reconnect game
• the probe handler should be delayed by each incoming packet on the connection (stanza, nonza or even whitespace)

[Flow]

That sounds nearly exactly like what PingManager already does (minus using SM <r/>s).

Is there any reason, besides saving a few bytes for the ping/pong elements, for using stream mangement elements for that?

[Georg_Lukas]

You are probably right. I know I had very high hopes on using SM pings instead of <ping> back then, but currently I can’t come up with really plausible reasons for that.