3 ms·

Also make sure your backup channel can scale. Getting a flood of 10,000+ folks over to a dinky IRC server can knock it over easy. Throttling new joinees isn't a

by gaogao 3y ago

Also make sure your backup channel can scale. Getting a flood of 10,000+ folks over to a dinky IRC server can knock it over easy. Throttling new joinees isn't a panacea either, since there might be someone critical to get on a channel which throttling can complicate.

londons_explore 3y ago
Maybe I'm naive, but I would imagine that any raspberry pi could run an IRC server with 10,000 users... Surely 10,000 Users each on average receiving perhaps five 50 byte messages per second (that's a very busy chat room!) is a total bandwidth of 2.5 megabytes per second. And the CPU time to shuffle messages from one TCP connection to another, or encrypt/decrypt 2.5 megabytes per second should be small. There is no complex parsing involved - it is literally just "forward this 50 byte message into this list of TCP connections". If they're all internal/authed users, you can hopefully assume nobody is deliberately DoSing the server with millions of super long messages into busy channels too.
- xena 3y ago
  IRC servers are single threaded. You have contention at that point.
  - goalieca 3y ago
    Some of the bigger irc channels have thousand users and this was in the day of 128MB of ram.
    - pinkgolem 3y ago
      Sure it's possible. But you need to test... For example there was/is a 1k file descriptor limit per process in a lot of distributions..
- pests 3y ago
  Let's not forget IRC channels can be split between servers too - don't wanna complicate the backup system too much but this is in the original design of IRC.