vCard SHA1 PresenceHash in Cluster

[dkliss]

Hi,

A question on vCard SHA1 hash.

In a two node cluster, when a SHA1 hash for a vCard image is calculated, it is stored in cache in one of the cluster nodes (as per docs). Is there any way to store this computed value in internal or external database? With this, in a cluster setup, if a client needs to retrieve an image hash from presence, the hash will be the SHA1 calculated hash will be same across the cluster.

Or is there any way to sync nodes in a cluster with calculated SHA1 hash value.

Thanks.

Before creating a ticket, please consider if this should fit the discussion forum better: https://github.com/processone/ejabberd/discussions

Environment

• ejabberd version: 22.10
• Erlang version: erl +V
• OS: Linux (Debian)
• Installed from: source | distro package | official deb/rpm | official binary installer | other

Configuration (only if needed): grep -Ev '^$|^\s*#' ejabberd.yml

loglevel: 4
...

Errors from error.log/crash.log

No errors

Bug description

Please, give us a precise description (what does not work, what is expected, etc.)

[prefiks]

There is probably no need to have this cache shared between nodes, cache entries are bound to a single user session (entry for bob@server.com are only read by sessions for bob@server.com user), and each session is always processed on the same node, in practice data on other nodes is never accessed (well at least not unless new session for that same user is spawned on other nodes). We could do that but extra cost of syncing caches, and potentially having half of cache filled with stuff never accessed on a given node (data for sessions living on other node) is probably not that good.

[dkliss]

There is probably no need to have this cache shared between nodes, cache entries are bound to a single user session (entry for bob@server.com are only read by sessions for bob@server.com user), and each session is always processed on the same node, in practice data on other nodes is never accessed (well at least not unless new session for that same user is spawned on other nodes). We could do that but extra cost of syncing caches, and potentially having half of cache filled with stuff never accessed on a given node (data for sessions living on other node) is probably not that good.

Thanks for your reply.

The problem I am facing is. If we have carbons i.e. two users with same user name and different resourceID. If one user bob@server.com/resource1 is attached to node01 in a cluster and another user bob@server.com/resource2 is attached to node02 in the same cluster, if I change image of bob@server.com/resource1, the hash of that image is not available at node 2 where bob@server.com/resource2 is connected. Hence after changing image bob@server.com/resource1 will received correct calculated hash but bob@server.com/resource2 may receive some previous cached value of SHA1 hash.

This is what I am experiencing. If we can have the computed SHA1 hash values stored in cluster then this may not occur.

[dkliss]

An approach, which i tried to alter hash of a node is to try to reset hash of second node using approach in XEP-0153 as below i.e. first i send an empty update child --> then download vCard and then --> send new computed hash. Even in this case, the server still replaces the new hash sent by me with its own cached hash.

If there is a provision to force a node to re-place user computed SHA1 hash in case node is different to where hash was originally computed, then that may also resolve the issue without having to sync.

Excerpt from XEP-0153 Below:

Resetting the image hash consists of the following steps:

1. Immediately send out a presence element with an empty update child element (containing no photo element).
2. Download the vCard from the server.
3. If the BINVAL is empty or missing, advertise an empty photo element in future presence broadcasts.
4. If the BINVAL contains image data, calculate the hash of image and advertise that hash in future presence broadcasts.

[prefiks]

Hm, didn't think about that case, let me see how hard would be adding cache syncing

[prefiks]

One more thing, you are using mod_vcard_xupdate?

[prefiks]

Commit 54cf37e917a44792a5bbbec913060b9ef9eb797b adds cache invalidation.

[dkliss]

Hash works as expected after this fix and therefore closing. Thanks!