IRC

This is the sixth and final post in my series of simple systems. It recounts my efforts to make a simple IRC client and server. The design of the software is made to emphasize the function of the protocol not the best way to code it. Pre-mature optimization is the route of all evil, before you can make something good you've got to understand how it's made. I hope that this post will help you understand IRC.

Objectives

Introduction

Internet Relay Chat, IRC, is an interesting beast. It is unlike any of the other protocols I have covered here. The server side of the other four is by nature contained to one machine. SMTP and DNS are a little different since they would could forward to another machine if necessary. But IRC, by it's name, is about relaying more than anything.

IRC had it's first rfc in 1993, rfc 1459. But it started it's history in 1988. It was created to replace an existing "MultiUser Talk" system for the university of Oulu Finland. Designed to allow people from within the university, university network, and beyond to all chat with each other, IRC is by nature a "networking" protocol. What I mean was it's primary strength was in the ability of the servers to create a relay network.

The big trick of IRC was it reduced data usage. If 5 students from univerity A are in a chat room with 5 students from university B, the server at A sends a message directly to its 5 students and then 1 message to B, which then shares that message with its 5 students. By doing things this way the message gets "relayed" and only one copy has to be sent over the wire versus 5. If the students from B were connected directly to A instead of through B's IRC server that is what would happen. Saving the data transfer for one message isn't that big of a deal, but IRC networks grew into the millions of users and the ability to limit traffic made this possible.

But that did lead to some interesting history. If you read up a little on IRC's history you'll learn how the universities started setting up their own networks and joined those networks together. There was a honeymoon period, but as with all things, it wouldn't last. in 1990 one of University of Berkeley's servers got quarentined. The anarchy ended. The one giant network of IRC fractured into EFNet, DALnet, IRCNet, etc. All of them are still around, but none of them are that big anymore.

I was hoping to find a protocol, like HTTP, that would be impossible to kill. And at it's basic level, that is true of IRC. But IRC is about relaying. It's value comes from its network. That's not true of HTTP. And that changes the calculous. I certianly hope IRC continues to be a thing, but having dropped from 10m users to 371k users, the future isn't great for this storied protocol.

Client

Over all this is a pretty simple protocol to implement on the client side. Only 109 long with comments makes it the smallest of the clients. It works something like this:

  1. Get server and nickname information from command line.
  2. Connect to server.
  3. Let the server know who we are.
  4. Read messages from server.
  5. Read message/command from user.
  6. Interact as the user requested.
  7. Repeat.

Server

The server Is a little more complicated, the most tricky one I've written. But again is still pretty short. The thing about this server is it has to manage multiple clients. With the other servers, for simplicity, I didn't bother with that ability since it was just to demonstrate how the protocol worked. But this is a chat server, the whole point is multiple people connected at once.

  1. Bind to a socket
  2. See if anyone is waiting to connect
    1. Check if a user with that nick name is already on.
    2. Add user to list of users.
    3. Let user know they have connected, send message of the day.
  3. Next iterate over all the users
  4. Receive whatever message they might have sent.
  5. Parse the message, if it is a command, execute it, if it is a message, relay it. If we were actually leveraging the "Relay" part of this protocol, we would be relaying to the other servers as well as the other users at this point.
  6. Close any connections that have dropped.
  7. Repeat.

Lessons Learned

Admittedly, I've not really used IRC. Of course I have logged into IRC servers in the past on services like Freenode, but IRC was never a big deal for me. This lack of knowledge certainly made it challenging to work with on this post. THe problem was that I didn't really know what some of the objectives were. For example I didn't realize that there were seperate IRC Networks out thre, I just thought people setup their own servers and called it good, much like is done for HTTP. Which makes the lesson learned here that I need to understand what some one was hoping to achieve before I can really understand their protocol. IRC is designed to be more than just a simple chat system, it is designed to be a global, distributed, chat network.

Conclusion

I really hope to see a renesaunce of IRC. Or rather services like it. I really like the decentralized nature of it. The freedom individual users and communities have to join groups or leave groups. In an equally storied history Mastodon seems to be filling in some of those shoes. I don't think Mastadon will be an everlasting protocol though, just like IRC it has some flaws. One of the things I would say is wrong with IRC is it has no obvious way to expand it's content type. Because the base most way messages work was by sending the command privmsg there isn't a really good way to do more complicated things like voice and video. I think this rigidity is what ended up getting in the way of it becoming the end all protocol. I really don't think you can do a semi-decentralized voice and video system though. I think we will need peer to peer for that to work.

Real Code

There are a lot of good libraries out there if you want to make legitamite IRC stuff with python. But the one I used to help me achieve this post was just irc.