View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006268 | unreal | ircd | public | 2023-04-30 19:59 | 2023-05-10 08:42 |
| Reporter | PeGaSuS | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Platform | Linux | OS | Ubuntu | OS Version | 22.04 |
| Summary | 0006268: Global maxclients setting | ||||
| Description | Recently someone asked on IRC for a way to limit the number of clients that can connect to the network. Although it is an unusual request, and even though we have the "class::maxclients" option, it only applies to the server in question. In case we want to limit the number of connections on all the servers, we have to divide the desired number of connections by the number of servers in the network and define this value on all the servers. It would be practical to have a setting such as "class::global-maxclients" which would take precedence over the setting "class::maxclients". | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I have big doubts about this. Also, as mentioned on IRC, the user needed this per-server and not per-network, so this is mostly your feature request not his. It is impossible in class, because classes only work for local clients. So it would have to be a separate setting. I don't think this would be a great setting though, putting a hard limit basically makes you reject everyone, which turns things into a DoS (you deny service to everyone). We already have connthrottle for when you are under attack. Also, it would create yet-another setting where users could be refused. We already have allow::maxperip, class::maxclients, the FD limit, connthrottle can kick in, and then you would also have this. I'm thinking it is a bit too much. I could leave this issue linger for a "just in case it could be useful to someone" but I think it's a bit too much, and then you could have many issues linger forever (which we do, but they are generally have stronger/better use cases than this one, so to say). |
