BBS: TELESC.NET.BR Assunto: Re: C Origins De: Nightfox Data: Wed, 27 May 2026 13:01:54 -0700 ----------------------------------------------------------- hbRenb: hcRe: C Origins bBynb: hcShitty bto cDenn bon cWed May 27 2026 03:37 pmn Sh> There have to be dozens of ways around that for a person who's creating Sh> the BBS software. Sh> If nodes are a must, then a new node should be created as needed for every Sh> connection, and there can be a subset for authenticated users, and Sh> something like fail2ban can be deployed for handling repeated failed Sh> attempts. I wonder how that would work with door games, which often require you to have a different configuration file for each node. Old door games were not designed with dynamic creation of nodes in mind; they all assumed a specific set number of nodes. This made sense, because BBS nodes were typically phone lines, and it was often very difficult to add more, because they would need computer resources (for serial ports) and would require paying money for phone lines and modems. As far as tying up nodes, there are already solutions to help mitigate that, and I think they work fairly well. And I think the concept would be basically the same with any kind of server, whether it be telnet, web, FTP, etc.. And I feel like dynamically creating more nodes for clients to connect to might actually be a bad solution, because that would mean consuming more computer resources. That could open your system up for a denial of service attack: Attackers could create perhaps thousands of connections to your BBS, which could result in your computer running out of memory, etc. due to having spawned too many threads to handle all the nodes for the incoming connections. In that regard, I think the inactivity timeout is probably the better solution. Nightfox n --- gSynchronetn Digital Distortion: digitaldistortionbbs.com ----------------------------------------------------------- [Voltar]