

A brief guide to the IRC protocol - Macha
http://blog.webicity.info/2010/10/14/a-quick-basic-primer-on-the-irc-protocol/

======
jpablo
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.

~~~
jarek
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

------
cagenut
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.

~~~
unwind
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.

~~~
koenigdavidmj
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.

~~~
dfox
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.

~~~
koenigdavidmj
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.

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

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

~~~
zokier
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.

~~~
tvon
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.

------
Mpdreamz
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.

------
akl
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.

------
paolomaffei
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.

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

~~~
_delirium
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.

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

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

~~~
thwarted
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.

~~~
Macha
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.

------
hackermom
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.

~~~
rogerclark
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.

~~~
hga
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.

