So I have an ip.can file that is about 1.3 gigs large, and when it gets this large there is a very long delay before a user can connect because I believe the bbs is working on parsing each line and seeing if the ip matches. I would assume I would have the same issue with host.can and other .can files.
I was wondering if there's anything I can do on my end to keep these large .can files and speed things up, or if synchronet needs some internal changes.
So I have an ip.can file that is about 1.3 gigs large, and when it gets
Do you have some kind of automated system that dumps IPs in there?
internal changes.
Do you have some kind of automated system that dumps IPs in there?
It might be worth passing that task off to something that will block those via firewall, like fail2ban or csf/lfd (for Linux). I guess there's something similar for windows (wail2ban? It hasn't been updated in forever but there are forks on github and people claim it still works)
Re: Re: Really struggling with windows install pls help :)
By: Digital Man to Matthew C E Bamber on Mon Jan 01 2024 03:48 pm
So I have an ip.can file that is about 1.3 gigs large, and when it gets this large there is a very long delay before a user can connect because I believe the bbs is working on parsing each line and seeing if the ip matches. I would assume I would have the same issue with host.can and other .can files.
I was wondering if there's anything I can do on my end to keep these large .can files and speed things up, or if synchronet needs some internal changes.
Re: large *.can files make things slow
By: DaiTengu to MRO on Tue Jan 02 2024 11:00 am
So I have an ip.can file that is about 1.3 gigs large, and when it gets
Do you have some kind of automated system that dumps IPs in there?
Synchronet itself seems to automatically put IPs in there when it detects clients trying to reconnect too often? I have a lot of entries in my ip.can with comments that start with "; SMTP - TOO MANY CONSECUTIVE FAILED LOGIN ATTEMPTS". Same with SSH.
memory for all of SBBS to have that massive ip.can file cached. It can be done and would likely have a significant performance improvement, but at the cost of a lot of memory used (in your case).
i guess i'll just trim it down every month.
If you have the available RAM, it wouldn't be a bad option to have. In fact, when importing QWK packets, the ip.can file *is* cached (since the source IP address of each message is compared, and that'd be really slow to re-read the file each time) - so there's already some cases where your SBBS instance is allocating that much RAM for the ip.can file, but for a shorter period of time since that memory is freed after QWK packet import is complete. For a server that's listening for incoming TCP/UDP connections, the memory (for the ip.can cache) wouldn't be freed until the server was terminated.
Re: Re: Really struggling with windows install pls help :)
By: Digital Man to Matthew C E Bamber on Mon Jan 01 2024 03:48 pm
So I have an ip.can file that is about 1.3 gigs large, and when it gets this large there is a very long delay before a user can connect because I believe the bbs is working on parsing each line and seeing if the ip matches. I would assume I would have the same issue with host.can and other .can files.
I was wondering if there's anything I can do on my end to keep these large .can files and speed things up, or if synchronet needs some internal changes.
Thanks,
---
� Synchronet � ::: BBSES.info - free BBS services :::
Sysop: | Coz |
---|---|
Location: | Anoka, MN |
Users: | 2 |
Nodes: | 4 (0 / 4) |
Uptime: | 138:40:42 |
Calls: | 166 |
Files: | 5,389 |
Messages: | 223,229 |