Openfire 4.7.0 introduced changes to the implementation of kicking occupants from MUC rooms that are 'idle'.
A new feature (or rather, one that was supposedly fixed), is one that uses IQ Pings to determine if an occupant is still reachable/connected (as opposed to being a ‘ghost’).
These changes have several issues:
Occupants are kicked from a room, without having been sent a ping (and without the "kick users after they have been idle for X minutes" feature being enabled - this is a bug in the "check if users are still connected" functionality). This clearly is a bug.
With the introduction of the ‘ping inactive occupants', there no longer is a distinction between occupants that are no longer connected to the room (’ghost users', anetwork issue), and users that are simply quiet (but remain connected). That is because a ping response is now considered 'activity'. There can be use-cases for removing occupants that are quiet, but otherwise connected just fine. That use-case has now been effectively made impossible. This should be restored.
The interval in which the checks to kick or ping a user run, are currently unrelated to the maximum duration of 'idle-ness', meaning that Openfire can act in a rather unexpected point in time.
the kick-message appears twice to the remaining occupants of the room (observed in a cluster of two, which might be related).
Improvements/fixes:
The "Check if users are still connected after they have been idle for Y minutes" option (default to 8 minutes, enabled) should be used to explicitly trying to determine if an occupant is still ‘reachable' / not a 'ghost’ (and kick them otherwise).
The "Kick users after they have been idle for X minutes" option (the defaults for this are: 30 minutes, but disabled) should apply to users that are ‘quiet' (but might be connected). This restores the original interpretation of this feature.
To be able to distinguish between both features, ‘ping responses' should not be considered 'activity' in the sense of the second option. They should only be used for 'ghost detection’ (the first option).
The interval used by the task for the above should be some fraction of the duration of each of the above, to make them react in somewhat of a timely manner.
There is no specific “MUC” ping - the mechanism uses a standard Ping (as defined in XEP-0199) which is widely supported. On top of that, the implementation in Openfire is smart enough to recognize a client response that says “I don’t understand this request” as proof of life.
I’m not sure how s2s comes into play here, although I did observe that in open_chat. The issues do not seem limited to S2S, as I’ve been able to (easily) reproduce them in a local environment, without s2s.
Daryl Herzmann January 27, 2022 at 2:50 PM
My concern is how many clients actually support MUC ping?
Openfire 4.7.0 introduced changes to the implementation of kicking occupants from MUC rooms that are 'idle'.
A new feature (or rather, one that was supposedly fixed), is one that uses IQ Pings to determine if an occupant is still reachable/connected (as opposed to being a ‘ghost’).
These changes have several issues:
Occupants are kicked from a room, without having been sent a ping (and without the "kick users after they have been idle for X minutes" feature being enabled - this is a bug in the "check if users are still connected" functionality). This clearly is a bug.
With the introduction of the ‘ping inactive occupants', there no longer is a distinction between occupants that are no longer connected to the room (’ghost users', anetwork issue), and users that are simply quiet (but remain connected). That is because a ping response is now considered 'activity'. There can be use-cases for removing occupants that are quiet, but otherwise connected just fine. That use-case has now been effectively made impossible. This should be restored.
The interval in which the checks to kick or ping a user run, are currently unrelated to the maximum duration of 'idle-ness', meaning that Openfire can act in a rather unexpected point in time.
the kick-message appears twice to the remaining occupants of the room (observed in a cluster of two, which might be related).
Improvements/fixes:
The "Check if users are still connected after they have been idle for Y minutes" option (default to 8 minutes, enabled) should be used to explicitly trying to determine if an occupant is still ‘reachable' / not a 'ghost’ (and kick them otherwise).
The "Kick users after they have been idle for X minutes" option (the defaults for this are: 30 minutes, but disabled) should apply to users that are ‘quiet' (but might be connected). This restores the original interpretation of this feature.
To be able to distinguish between both features, ‘ping responses' should not be considered 'activity' in the sense of the second option. They should only be used for 'ghost detection’ (the first option).
The interval used by the task for the above should be some fraction of the duration of each of the above, to make them react in somewhat of a timely manner.