Presence is sent even if disabled

Smack Smack Dev
1

I disable automatic presence sending:

configBuilder.setSendPresence(false); // we send presence manually

But when using stream management, on stream resumption a presence is sent.

This is caused by EntityCapsManager which does not evaluate the presence send flag:

if (connection != null && connection.isAuthenticated() && presenceSend) {
            Presence presence = new Presence(Presence.Type.available);
            try {
                connection.sendStanza(presence);
            }
            catch (NotConnectedException e) {
                LOGGER.log(Level.WARNING, "Could could not update presence with caps info", e);
            }
        }

I think the current behavior (v4.1.1) is not correct and I anyway wonder that an extension like EntityCapsManager is enabled by default.

2

See comment right above the code snippet you posted.

Isn’t the problem rather that this may override an existing previously sent presence?

I anyway wonder that an extension like EntityCapsManager is enabled by default.
Why’s that? Do you like to have everything disabled by default?

3

But when using stream management, on stream resumption a presence is sent.

This is caused by EntityCapsManager which does not evaluate the presence send flag:

I’d like to add, that presence should never be resent upon resumption, regardless of the “send flag”.

From XEP-0198:

The client SHOULD NOT resend presence stanzas in an attempt to restore its former presence state, since this state will have been retained by the server.

4

I expect extensions to be disabled by default. In this case EntityCapsManager causes just overhead.

5

Right, that’s why there is no mechanism in Smack that does (intentionally) send presences after resumption.

6

Overhead? In which aspect? Entity Caps in fact minimizes network overhead.

I won’t disable extensions by default. Smack should be “ideally” configured out of the box. But if you really want a stripped down version of Smack, then the design of Smack makes it easy possible: Smack is highly modular, users are able to only select the modules they need. Furthermore you can also disable single Smack classes (managers, …).

7

This is caused by EntityCapsManager which does not evaluate the presence send flag:

  1. if (connection != null && connection.isAuthenticated() && presenceSend) {

I’m sorry, maybe I miss something, but isn’t the presenceSend flag the third boolean in the condition?

8

I think the resumed-check here should be removed:

public void authenticated(XMPPConnection connection, boolean resumed) {

…

// Reset presenceSend when the connection was not resumed
if (!resumed) {

presenceSend = false;

}

}

9

You assume also Smack on the other side. Then you can implement an ideally setup with pre-enabled extensions. If the other side does not support or does not use some extensions then you may produce overhead. In addition the programmer has to find out in Smack source code which extensions are enabled by default.

10

And why do you think so? Could you elaborate on that? It’s perfectly valid as far as I can see.

11

may produce overhead
I still wonder which overhead you mean here. If it’s the extension of presence, then the overhead is minimal and the benefits outweigh IMHO.

12

The client SHOULD NOT resend presence stanzas in an attempt to restore its former presence state. So after authentication it should always set presenceSend here to false.

13

Yes, with overhead I mean:

  • unnecessary stanza stuff, e.g. “”

  • and unnecessary code executed.

14

The client SHOULD NOT resend presence stanzas in an attempt to restore its former presence state.

Again, this is already fulfilled by Smack. If not, the please report where and why it’s not respected.

So after authentication it should always set presenceSend here to false.
Where does Smack resend presence stanzas? How is this related to presenceSend?

presenceSend is only taken into consideration in updateLocalEntityCaps(), which is only called when the information on which caps are based are changed, which is, as far as I can see, not related to authentication.

Furthermore presenceSend is only set to null if the stream is not resumed, if the stream was resumed and presenceSend is not null, then it’s true that there was a presence sent and the value has to be kept.

15

You both give valid points, but I agree with Flow, that the benefits of XEP-0115 outweigh the extra extension and extra computation, which is neglectable (unless you see considerable performance hits, which I doubt).

So, this is one of the extensions which should be enabled by default imo, to promote the benefits of XEP-0115. The cost for other XMPP entities to discover (Smack’s) services (every time) is much higher than including and computing the element.

16

The question may be why obviously updateLocalEntityCaps() is called when stream is resumed. But sorry I cannot debug that in Smack. I just can report the problem outside of Smack and try to point out where it comes from.

17

How do you know that “obviously updateLocalEntityCaps()” is called if you are unable to debug Smack. Or are you just guessing that?

Anyway, I can’t help you if there is no detailed bug report containing a root cause analysis.

18

I scanned Smack source and this is the only place left where a presence is sent in this context. And if I disable *EntityCapsManager *the problem is gone.

The problem is reproducible. For me the workaround is simple, I disable EntityCapsManager, but maybe not for others.

19

Ahh, now that’s some useful information. Could you enable EntityCapsManager and disable Socks5BytestreamManager and see if the presence is still sent?

20

Presence is still sent.