Hacker News Reader

Comment by cagenut | Hacker News Reader

I've often wondered how well an ircd would scale as a twitter clone. Following someone would just joining a channel that only they could write to.

I wonder how many clients are connected and receiving realtime messages during peak usage on say efnet.

edit: sorry I clearly phrased this poorly, I said "an ircd" but in my brain I was thinking of an ircd network like efnet, freenode, etc.

View on HN

On EFNet: 40416 44108 :Current global users 40416, max 44108

On IRCNEt: 66290 98675 :Current global users 66290, max 98675

Which is probably significantly less than number of twitter users, but IRC is explicitly designed to be scalable.

It was also designed in the eighties to be used in university networks. The scale was a lot smaller back then.

The volume of communication is FAR higher than twitter though, and the number of engaged people is likewise higher.

Those are actually very small numbers. Justin.TV's chat system, for comparison, has scaled to half a million concurrents. And I had to significantly diverge from the IRC spec to achieve that level of scale.

I'm interested in exactly how you diverged. What changes did you make to the protocol (especially in terms of server-server communication) to facilitate that kind of scalability?

You mean like tircd or twircd?

http://github.com/kore/twircd http://code.google.com/p/tircd/

I might be naive, but to me "connected" to an IRC server implies having an open TCP/IP connection. That means that the server will run out of ports at roughly 65,000 clients.

Of course, you could probably solve that by load-balancing, having multiple parallel ircd instances that share the backend, but then you're not having "an ircd" any longer.

Having multiple instances of ircd is the main point of IRC protocol, that is what the R (as in Relay) stands for.

In a world where a single server can support over 100K connections, I wonder if server-to-server support is needed. You could probably simplify an ircd significantly by making it centralized.

In a world where IRC networks are frequently DDoS attacked by scriptkiddies (and others), a single point of failure is not worth the simplification.

It seems like if you can DDoS one server, you can DDoS several, but I'm no expert. Also, I thought one of the major motivations for IRC DoSes was to cause netsplits that allow nick stealing; a single sever can't have a netsplit.

No. TCP connections are identified by a four-tuple of (sender's IP, sender's TCP port, receiver's IP, receiver's port). Thus you are only limited by 65536 connections between a particular server and a particular client.

In fact you are limited to 2^32 (=65536^2) connections between two hosts, as you can vary both ports. But that is only theory. In practice you will run out of some other system resource (kernel memory, file descriptors, slots in connection table...) before reaching this limit.

Yes, I meant connections to one particular service. In that case both IP fields and the server port are fixed, so the only varying parameter is the client port number.

And that was, I feel kind of redundant in pointing out, exactly what I meant too.

For the most scenarios the maximum number of connections between the same client and server will be smaller, because an unbound client socket would reside in the ephemeral port range:

http://en.wikipedia.org/wiki/Ephemeral_port

Twitter doesn't run on one server either. In fact there was talk a while back that some particularly famous users have an entire server's worth if traffic.

That means that the server will run out of ports at roughly 65,000 clients.

I wrote the justin.tv chat server (which happens to be based on irc). A single one of our chat machines can handle about 120,000 concurrent connections. Available cpu is the limit, not number of ports.

No, the server is only using a single port - the one it's listening to. It's also already standard to run multiple, local relays per server instance in the case of IRCds. Many servers run multiple instances that together span 3 or 4 ports; 6667, 6668, 6669 etc.

Reply on news.ycombinator.com