powered by Jive Software

Remove check server capability request (disco#info)

I have noticed that smack sends disco#info request for some of the service i.e muclight and pubsub. Smack send these request before the auth callback triggers in my connection manager. I don’t want to send these disco#info requests as we always communicate with the same server and its capabilities are known to us. As we implement services on the client side knowing this is supported by the server.

<iq to='muclight.server.com' from='id@server.com/R' id='yN82u-18' type='get'><query xmlns='http://jabber.org/protocol/disco#info'></query></iq>

iq to='pubsub.serve.com' from='id@server/R' id='yN82u-20' type='get'><query xmlns='http://jabber.org/protocol/disco#info'></query></iq>

<iq to='upload.server.com' from='id@server/R' id='yN82u-24' type='get'><query xmlns='http://jabber.org/protocol/disco#info'></query></iq>

<iq to='vjud.server.com' from='id@server/R' id='yN82u-22' type='get'><query xmlns='http://jabber.org/protocol/disco#info'></query></iq>

These are some of the noticed discon#info request.

Please guide how can I avoid these disco#info requests.

Service discovery queries are often necessary (eg. to determine the type of and/or information about pubsub nodes etc) and therefore many places in Smack’s source code will rely on them.
There is no straight forward way of deactivating those queries altogether and I fear that to disable them completely you’d have to patch the method calls out manually in many places. I’m not sure if you really gain much from this.

Note that you can reduce the number of necessary queries by implementing and setting a caps cache implementation, eg. a SimpleDirectoryPersistentCache, which will cache the capabilities of entities and servers, so that only a single query is necessary to look up the capabilities locally by comparing a hash value.

I can imagine that you could write some packet intercepting code that would prevent these stanzas from being sent out. However, this feels like a classic example of premature optimization to me. Unless these requests are doing you some kind of harm, I’d leave it in place.

1 Like

Thanks for your response on this. With SimpleDirectoryPersistentCache and EntityCapsManager I have noticed that it’s caching some results now. Few things I have observed, It’s not caching all the results. For instance, I don’t see pubsub, upload, and vjud.

I see muc (<feature var='http://jabber.org/protocol/muc'/>) in the cached result but the disco#info request is still being sent for this and of course for others that are not in the cache.

Initially, I had a similar approach in mind but I have noticed that some services have a dependency on DiscoverInfo i.e HttpFileUploadManager. I suppose other changes are also required for this.

What is the problem that you’re trying to solve?

@guus The goal is to minimize the disco requests. As mentioned earlier, in our case server capabilities are always known on the client-side. So, we want to avoid these requests as much as possible.

Why? The (data) savings are minimal, but the amount of work required, as well as the risk that something breaks is high.

I guess guus has the same feeling as I do, that this falls into the category of premature optimization without any real underlying issue (besides wasting a few bytes traffic and cpu cycles).

I know that Smack has a certain post-authentication delay due to the requests (mostly) being performed sequentially, but here, the right way forward is to parallelise them, not to forcefully suppress them. As the latter could cause any kind of unwanted side effects.