#988 mod_muc_limits: make default behavior more adequate
Reporter
Ge0rG
Owner
Nobody
Created
Updated
Stars
★★ (2)
Tags
Component-Community
Status-New
Priority-Medium
Type-Defect
Ge0rG
on
The current mod_muc_limits defaults are not adequate for MUCs with multiple non-members sending CSNs, often causing normal messages to be blocked due to "overactivity".
It would be great to make the module more adaptive, by applying one of these policies (in order of growing anticipated improvement):
1. Increase the static default limit values in accordance with modern client usage.
2. Make the limit depend on the number of MUC members (not participants). This would allow a room to grow organically - more members means more non-members can do more
2. Make the throttle not count stanzas but the visible impact / weight. Example:
- each stanza has a default weight of 10
- stanzas with a body have 10 + len(body) + 10*number_of_lines
Jonas Wielicki
on
A few questions:
1. What exact new limits do you propose for (1)?
2. What scaling factor do you propose as default for (2)?
3. Which of the possibly many <body/> elements shall be counted in what I think was supposed to be (3)? max(len(body) for body in bodies) + 10*max(number_of_lines(body) for body in bodies)?
4. What new defaults for limits would you propose when implementing (3)?
Ge0rG
on
1. Zash mentioned having an installation with custom values. Those are probably better than the defaults already.
2. The default limit (see 1) should be multiplied with SQRT(number of affiliated users). That will scale sub-linearly and provide a useful approximation of the not-everybody-is-talking-at-the-same-time social interaction framework model. It is also a very scientific approach.
3. We need to define a model that covers both bandwidth usage and screen space wasting to adequately answer that question. I think somebody should first write a mod_muc_monitor_usage plugin that counts all the relevant numbers and plots ASCII graphs in XMPP messages to $server_admin. After that, we let it run on some busy MUCs and decide the weights and limits accordingly.
I think that having an easy metric (fixed per-message overhead, rough estimate of the wasted screen estate) with some sensible defaults (taken from 1, multiplied by 10 for the proposed weight) could do it.
Jonas Wielicki
on
Another question: How would Last Message Correction be handled?
I think it should be treated favourably since on clients which support it, it is rather lightweight. However, this opens a hole for malicious clients which could simply use an invalid message ID in the LMC which would make complying clients to show the correction as stand-alone message. That’d be an awful lot of business logic for mod_muc_limits.
Ge0rG
on
For LMC, it's really easy. The following logic should apply:
if the referenced ID is NOT in the MUC back log or the LMC is invalid: apply full cost metric.
Otherwise, if the LMC is valid, subtract the additional cost of the initial message (but not the base cost of 10) from the calculated cost of the new message.
The current mod_muc_limits defaults are not adequate for MUCs with multiple non-members sending CSNs, often causing normal messages to be blocked due to "overactivity". It would be great to make the module more adaptive, by applying one of these policies (in order of growing anticipated improvement): 1. Increase the static default limit values in accordance with modern client usage. 2. Make the limit depend on the number of MUC members (not participants). This would allow a room to grow organically - more members means more non-members can do more 2. Make the throttle not count stanzas but the visible impact / weight. Example: - each stanza has a default weight of 10 - stanzas with a body have 10 + len(body) + 10*number_of_lines
A few questions: 1. What exact new limits do you propose for (1)? 2. What scaling factor do you propose as default for (2)? 3. Which of the possibly many <body/> elements shall be counted in what I think was supposed to be (3)? max(len(body) for body in bodies) + 10*max(number_of_lines(body) for body in bodies)? 4. What new defaults for limits would you propose when implementing (3)?
1. Zash mentioned having an installation with custom values. Those are probably better than the defaults already. 2. The default limit (see 1) should be multiplied with SQRT(number of affiliated users). That will scale sub-linearly and provide a useful approximation of the not-everybody-is-talking-at-the-same-time social interaction framework model. It is also a very scientific approach. 3. We need to define a model that covers both bandwidth usage and screen space wasting to adequately answer that question. I think somebody should first write a mod_muc_monitor_usage plugin that counts all the relevant numbers and plots ASCII graphs in XMPP messages to $server_admin. After that, we let it run on some busy MUCs and decide the weights and limits accordingly. I think that having an easy metric (fixed per-message overhead, rough estimate of the wasted screen estate) with some sensible defaults (taken from 1, multiplied by 10 for the proposed weight) could do it.
Another question: How would Last Message Correction be handled? I think it should be treated favourably since on clients which support it, it is rather lightweight. However, this opens a hole for malicious clients which could simply use an invalid message ID in the LMC which would make complying clients to show the correction as stand-alone message. That’d be an awful lot of business logic for mod_muc_limits.
For LMC, it's really easy. The following logic should apply: if the referenced ID is NOT in the MUC back log or the LMC is invalid: apply full cost metric. Otherwise, if the LMC is valid, subtract the additional cost of the initial message (but not the base cost of 10) from the calculated cost of the new message.