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?
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.
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.
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:
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.
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.
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.
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.
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.
Jabber rode the wave of "everything must be xml". Try debugging anything that's based on irc - you can do it using telnet (and/or tcpdump, if you need to see full client-server interactions). Now try doing the same for Jabber. Typing xml snippets into telnet is not pleasant.
Indeed, which is why it's typically not done, there are many better XMPP clients with debugging capabilities (including command-line ones) than telnet.
Personally I much prefer debugging XMPP to debugging IRC protocol issues since it's always obvious what is going on from what goes over the wire, whereas in IRC you are frequently forced to look up random specs to figure out what some obscure numeric code means to a particular implementation of the protocol.
In the glory days of IRC, everyone was using it. Now most social medias have replaced the need for it. I think that what really killed IRC was msn/icq, specialised and targeted chat instead of meeting random people (which is quite hard to do these days).
IRC was the precursor to many specific stuff that later gave whole industries. Stuff like online dating didn't exist, interest groups like #linux or regional chatrooms like #Montreal. I think that jabber rose during the fall of IRC but they didn't manage to catch the fleeing users since their service is quite similar to what people were leaving. Since the web caught on online dating and such, IRC and jabber became less and less interesting for most of their former users.
Critical mass (or the lack of it) would be my guess. Social tools are not very useful if you are using it alone. And switching IM requires quite a lot of momentum imho.
And there are some technical stuff too. Jabber is much heavier and noisier protocol. And afaik there isn't a Jabber client comparable to irssi yet.
Good point, I think abstractbill nailed it with the XML, which would explain why there was never a good (or great) client. I remember having the client conversation when Jabber was growing, there were clients you could use but nothing that you really wanted to use.
IRC client running in background is non-obtrusive, while Jabber is primarily intended for IM, which means frequent distractions. I know many developers who do not use any kind of IM, while they frequently chat on IRC.
There is nothing about Jabber group chat that requires any frequent distractions, and group chat Jabber apps I have used seem to behave somewhat identically to irc clients (granted, this was ~4 years ago).
Yes, but the Jabber group chat implementation is actually half-assed at the protocol level. IRC actually does a much better job and has much better features for managing large group conversations.
That they've had extensibility in mind for forever and actually make improvements that allow for richer features beyond text-only chat? Don't try to market DCC to me.
Nice never thought i'd get to mIRC.net, a site i am an admin on, through hackernews. There are several great RAW tutorials on mirc.net and mircscripts.org and in fact theraw section this blog post links too is an excellent reference point for all network deviations of the RFC's.
I suppose that makes me one of the smaller handful of people who's learned the IRC protocol while making an iPhone app (Mobile Colloquy). And I even liked it so much that I then had to go and do some work on a second implementation of it (for Justin.tv's app)!
Agreed. I spent way too much time reading old mailing lists and server and client specific docs when trying to understand the protocol (not any specific software that used it) while writing nodebot (http://github.com/thwarted/nodebot). RFC1459 is seriously lacking in real-world use, explanation of terms, and general robustness, despite that it was written to document a defacto protocol.
On the other hand, you do see a lot of the organic evolution of a protocol in what is IRC, which is valuable from both an historical and educational perspective.
I agree about the problems with the specs. For the most part, the best way to find out how a lot of the stuff worked was just to telnet a few IRC servers. For example, the thing about some servers needing a ping after user? Not mentioned in any spec, discovered while using a specific IRC network via telnet.
A truly wonky and stupid protocol that could've been done so much better. Good grief. And I say this not just being a permanent IRC resident since over 10 years, but having written both an IRC client and a bot-of-sorts.
It was easy for us to say this 15 years ago when a super-compact binary protocol just seemed to make oh so much sense, but now I'm not so sure.
The IRC protocol does exactly what it sets out to do, and there isn't really much over-the-wire overhead for client connections. The only information that's repeated unnecessarily is user hostmask data; everything else is mostly 100% useful.
It could really have only been a bit better if each event was described in a JSON- or YAML-like notation, but this was 1988, not 2008.
Compared to tons of other legacy protocols in use today (FTP!?), IRC isn't all that bad.
Well ... FTP was very early, RFC 114 in 1971 going by the titles (http://tools.ietf.org/rfc/) and only coming after (at that level) a logger protocol (had to do with setting up terminal service), terminal services and RJE.
But, yes, anyone who complains about a new boziod protocol should be forced to look at the wonders and horrors of FTP, especially in the context of NATs.
I know I did it. It's a great learning experience in network programming. And one you can brag to your friends in #whatever.