A brief guide to the IRC protocol | Hacker News Reader

A brief guide to the IRC protocol

blog.webicity.info

60 pointsMacha52 comments

Is there any developer that didn't developed and IRC bot or client in their youth ?

I know I did it. It's a great learning experience in network programming. And one you can brag to your friends in #whatever.

I think there are plenty of them. IRC would barely qualify as "popular" among CS/SE students graduating in the past 5 years.

/jarek, developer, IRC user, not a bot programmer

Yeah, I still use mine. http://jircii.dashnine.org/ :)

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.

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.

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/

So, any speculation as to why jabber never replaced (or even really contended with) irc for developer chats?

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.

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.

Except that irssi itself can speak XMPP with a plugin, you need to mentally decouple UI from protocol.

That said, irssi-xmpp is certainly in need of some hacker love...

BitlBee (http://www.bitlbee.org/) is the answer. Use IRC, ICQ, MSN, XMPP and Twitter from within irssi.

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.

What was the reason for developers to switch over? "A better protocol" isn't a good one.

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.

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.

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 have IRC to thank for learning a lot about basic client/server communications and networking back in my early teens.

Certainly not the best protocol ever invented, but I have fond memories of figuring out how it worked.

I recall I loved IRC so much when I was young I learned all the protocol even if I didn't want to actually use it.

I was one of a million other teenagers who learnt it trying to write an IRC client in VB5/6.

I think my first introduction to "Turing tar-pit" style programming was trying to write an IRC client in mIRC script, which even sorta worked.

I did that too, before mIRC supported multiple servers, I loved mIRC script, now, not so much

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)!

good work. if only I'd had something like this when working on the IRC module for ayttm.

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.

Same with many of the protocols that have taken off. Look at HTTP - it's an abysmal wasteful stupid protocol, but it kinda works well enough.

Pretty much as soon as an implementation takes off, that becomes the de-facto spec, and it mutates from there.

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.

Having watched hundreds of millions of users chat via AIM over the last 20 years, I'd say IRC was brilliant in comparison.

"Gee, if only I could chat with two people in the same window..."

Reply on news.ycombinator.com