View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004127 | unreal | ircd | public | 2012-10-06 11:52 | 2015-07-13 22:15 |
Reporter | driew | Assigned To | syzop | ||
Priority | normal | Severity | feature | Reproducibility | have not tried |
Status | closed | Resolution | no change required | ||
Platform | Linux | OS | CentOS | OS Version | 5.3 |
Product Version | 3.2.8 | ||||
Summary | 0004127: HTM enhancements | ||||
Description | Also, I don't know if this has been reported in the past.. but I think HTM should have an outgoing trigger along with the incoming. Without looking at the code, I don't know how complex it would be to add that. But if we go with disabling /who, /list, and using short /names replies during HTM, the server should also know when it's reaching it's outgoing limit just as much as it's incoming. Though I think HTM was originally designed to prevent 100% cpu situations under incoming floods; but it could be adapted very well to handle both aspects of "I have no bandwidth left..". Since the results of running out of outgoing bandwidth is very ugly, nearly as ugly as the ircd getting swapped out ;) | ||||
Additional Information | This bug was cloned off 0003900 | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
Sounds good. In addition to that, I think we should disable /WHO during HTM (it only seems to limit '/WHO *' at the moment). As WHO is really one of the most floody commands out there (2nd after LIST). I think the clients will do fine, even though it might violate some spec... Anyway, HTM means "I'm really short of bandwidth", so such consequences would be justified (like clients not having a fully up to date IAL due to not receiving UHNAMES and WHO) |
|
Also, I don't know if this has been reported in the past.. but I think HTM should have an outgoing trigger along with the incoming. Without looking at the code, I don't know how complex it would be to add that. But if we go with disabling /who, /list, and using short /names replies during HTM, the server should also know when it's reaching it's outgoing limit just as much as it's incoming. Though I think HTM was originally designed to prevent 100% cpu situations under incoming floods; but it could be adapted very well to handle both aspects of "I have no bandwidth left..". Since the results of running out of outgoing bandwidth is very ugly, nearly as ugly as the ircd getting swapped out ;) |
|
Hello! I think the appropriate thing to do here is to add hybrid-style pace waiting. It's proven and it works. HTM is bad in general and should be replaced by a more flexible system (e.g. pace waiting). |
|
In principle I would be fine with another system. If you could explain what you have in mind, how it works, and the benefits (and possible downsides), then we could consider such an alternative. Right now HTM is very little used, and the system itself is pretty limited. |
|
Most of the big deal with HTM is gone on my branch as it stands, as it manipulated what fdlists got polled, and instead we use evented i/o now, where we're not really doing polling anymore like that. For the rest, in charybdis there's two systems: - Hybrid-style pace-waiting (which is likely on the way out). This is simple, basically you store the time_t for the last execution of the command. If it was used recently, you just say "sorry, the command's ratelimited right now". - New charybdis-style token ratelimiting. This is like pace-waiting, except that each client has his own token set, and tokens are refilled every so often. This works better than hybrid-style pace-waiting, and both work better than HTM ever did. |
|
HTM is out |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-10-06 11:52 | syzop | New Issue | |
2012-10-06 11:52 | syzop | Issue generated from: 0003900 | |
2012-10-06 11:52 | syzop | Relationship added | related to 0003900 |
2012-10-06 11:58 | syzop | Reporter | syzop => driew |
2012-10-06 11:58 | syzop | Summary | UHNAMES following HTM => HTM enhancements |
2012-10-06 11:58 | syzop | Description Updated | |
2012-10-06 11:58 | syzop | Additional Information Updated | |
2012-10-27 04:32 |
|
Note Added: 0017207 | |
2012-10-28 08:46 | syzop | Note Added: 0017211 | |
2012-11-04 08:18 |
|
Note Added: 0017220 | |
2013-02-12 08:29 | dummy | Status | new => has patch |
2013-02-19 22:54 | syzop | Status | has patch => new |
2015-07-13 22:15 | syzop | Note Added: 0018486 | |
2015-07-13 22:15 | syzop | Status | new => closed |
2015-07-13 22:15 | syzop | Assigned To | => syzop |
2015-07-13 22:15 | syzop | Resolution | open => no change required |