powered by Jive Software

Handling Client Presence Probes

Currently, it would appear that the openfire server is dropping presence probes sent from the client.

Presence probes are useful to force a refresh of your presence state if you were previously ignoring presence (say, via a privacy list which blocks incoming presence).

Blocking incoming presence is useful in mobile environments when interest in other’s presence is only necessary in very limited contexts. Receiving and handling presence stanzas when they aren’t being used wastes power, so it is a good idea to not have them be sent at all. The problem then comes what do you do when you want to actually view presence in a roster?

Sending a single presence probe makes the most sense, but it currently does nothing. In the absence of this functionality on the server side, the client is reduced to sending a presence probe to each individual on their contact list.

To reiterate: I believe that the best behavior for the server to take when it receives an unaddressed presence probe from the client is to forward that presence probe to the contacts which that user is subscribed to.

Any thoughts?

Additional information:

Ignite Realtime: Openfire closes stream when client …

[Standards] Client-Generated Presence Probes

Hi Robert!

I am absolutely with you. I have the same Problem. ( see: http://www.igniterealtime.org/community/thread/38581?tstart=0 )

I had to patch Smack to request presence (via type “probe”), but I only get it for each user individually.

It would be really nice to get all presences by only sending one probe to the server. Is that possible with other xmpp-servers?

What else could I do to get current probes after denying presence_in?

I could drop the connection and reconnect. Is that the recommended way?

Regards,

Dirk