Depending on your previous experience, this project may be substantially larger than your previous programming projects 1. With that in mind, this section gives suggestions for how to approach the project. Naturally, other approaches are possible, and you are free to use them. Nothing in this section is intended as a requirement.
Begin by reading Sections 1-3 of the RFC. Do not focus on the details; just try to get a sense of how IRC works at a high level. Understand the role of the clients and the server. Understand what nicknames are, and how they are used. You may want to print the RFC, and mark it up to indicate which parts are important for this project, and which parts are not needed. You may need to reread these sections several times.
Next, read Section 4 and 6 of the RFC. You will want to read them together. In general, Section 4 describes the purpose of the commands in the IRC protocol. But the details on the possible responses are given in Section 6. Again, do not focus on the details; just try to understand the commands at a high level. As before, you may want to mark up a printed copy to indicate which parts of the RFC are important for the project, and which parts are not needed.
Now, go back and read Section 1-3 with an eye towards implementation. Mark the parts which contain details that you will need to write your server. Read sections 4 and 6. Start thinking about the data structures your server will need to maintain. What information needs to be stored about each client?
Leave the RFC aside, and let its details percolate in your head. Get started with some socket programming.
In Section 3.2, we mentioned that you will need low level tools to fully test your IRC server. While there are some existing tools that you can download, developing your own tool will provide valuable experience in the client side of socket programming. It is also an excellent way to build up towards the IRC server.
Your low level tool will essentially be a minimal IRC client. It will take messages entered on standard input (stdin), and send them to the server. It will also take messages sent by the server, and deliver them to standard output (stdout). IRC is an asynchronous protocol, in the sense that either side may send a message at any time. Thus, your tool will need to process input from both stdin and the server. This will give you practice dealing with concurrency.
Test your tool by connecting to a public IRC server. See if you can use your tool to register your connection and join a channel. (You may need to reread the documentation of the registration and join commands to figure out what to send the server.)
As you work on the low level testing tool, you may think of questions you have about the protocol. Be sure to write these down so you don't forget them.
Save a copy of your testing tool. You can now use the code from the testing tool to build a simple chat server. The simple server should accept connections from multiple clients. It should take any message sent by any client, and ``reflect'' that message to all clients (including the sender of the message). This server will not be compatible with IRC clients, but the code you write for it will be useful for your final IRC server. Writing this simpler server will let you focus on the socket programming aspects of a server, without worrying about the details of the IRC protocol.
Now, if you had any questions about the protocol, take another look at the RFC to see if you can find the answer. If you can not find the answer, you may want to post a question to the bulletin board.
At this point, you are ready to write the IRC server. You should be able to use the code for the simple chat server as a base. Do not try to write the whole server at once. Decompose the problem so that each piece is manageable and testable. You might start by implementing the routines that read commands from the network connection and parse them. Test these routines with your simple client. Then implement the registration commands. Test these with your simple client, and with standard clients. Next, implement and test the messaging commands. Finally, implement and test any remaining commands.
Before coding, be sure to think about the commands and how they work together. Several commands may need to do some of the same things. Identify these common tasks and group them into procedures, so that you can avoid writing the same code twice.