15-441: Computer NetworksProject 1: Internet Relay Chat (IRC) ServerLead TA: Xi Liu <[email protected]>Assigned: January 19, 2008Checkpoint 1 due: January 25, 2008Checkpoint 2 due: Feburary 1, 2008Final version due: Feburary 12, 20081 IntroductionThe purpose of this project is to give you experience in developing concurrent networkapplications. You will use the Berkeley Sockets API to write an Internet chat server using asubset of the Internet Relay Chat protocol (IRC)[1].IRC is a global, distributed, real-time chat system that operates over the Internet. AnIRC network consist s of a set of interconnected servers. Once users ar e connected to an IRCserver, they can converse with other users connected to any server in the IRC network. IRCprovides for group communication, via named channels, as well as personal communicationthrough “private” messages. For more information about IRC, including available clientsoftware and public IRC networks, please see The IRC Prelude[2].If you have not used IRC before, you may want to try it out to get a f eel for what it is.For a quick start, log in to an Andrew machine, and run irssi -c irc.freenode.net -n nicknamewhere nickname is the nickname you want to use. Then type /join #networking to join anetworking discussion channel. Other channels you might be interested include #gentoo,#redhat, #perl, and #c++. After you have tried out the text mode IRC client, you maywant to try out graphical clients such as xchat and chatzilla (part of mozilla).2 Logistics• The tar file for t his project can be found here:http://www.cs.cmu.edu/∼dga/15- 441/S08/project1/project1.tar.gz• This is a solo project. You must implement and submit your own code.• We recommend adhering to a schedule like:1date milestone1/19 project assigned1/22 read and understand the project handout1/25 checkpoint due – version control basics2/1 checkpoint due – handling multiple clients2/8 standalone irc server complete2/10 standalone irc server tested thoroughly2/12 last minute rush to get things done and hand-in3 OverviewAn IRC network is composed of a set of nodes interconnected by virtual links in an arbitrarytopology. Each node runs a process that we will call a routing daemon. Each routing daemonmaintains a list of IRC users availa ble to the system. Figure 1 shows a sample IRC networkcomposed of 5 nodes. The solid lines represent virtual links between the nodes. Each nodepublishes a set of users (i.e., the nicks of the IRC clients connected to it) to the system. Thedotted lines connect the nodes to their user sets.The usage model is the following: If Bob wants to contact Alice, the IRC server on theleft first must find the route o r path from it to the node on the right. Then, it must f orwardBob’s message to each node along the path (the dashed line in the figure) until it reachesthe IRC server at Alice’s node, which can then send the message to the client Alice.In this project, you only need to implement a standalone IRC server. You canassume t hat there is only one IRC server and a ll clients are connected t o the server.Figure 1: IRC network24 Definitions• nodeID – unique identifier that identifies an IRC server, or node. In the first project,the nodeID for the standalone IRC server should be 1.• destination – IRC nickname or channel as a null terminated character string. Asper the IRC RFC, destinations will be at most 9 chara cters long and may not containspaces.• IRC por t – The TCP port on the IRC server that talks to clients.5 The IRC ServerYour server will implement a subset of the original IRC protocol. The original IRC protocolis defined in RFC 1459[3]. Because RFC 14 59 omits some details tha t are required to imple-ment an IRC server, we have provided an annotated version of the RFC[4]. For this project,you should always refer to the annotated version of the RFC, not the original version.We have chosen a subset of the protocol that will provide you with experience developing aconcurrent network application without spending an inordinate amount of time implement-ing lots of features. Specifically, your server must implement the following commands:Basic Commands• NIC K – Give the user a nickname or change the previous one. Your server shouldhandle duplicate nicknames and report an error message.• USER – Specify the username, hostname, and real name of a user.• QUIT – End the client session. The server should announce the client’s departure toall other users sharing the channel with the departing client.Channel Commands• JOIN – Sta rt listening to a specific channel. Although the standard IRC protocolallows a client to join multiple channels simultaneously, your server should restrict aclient to be a member of a t most one channel. Joining a new channel should implicitlycause the client to leave the current channel.• PART – Depart a specific channel. Though a user may only be in o ne channel at atime, PART should still handle multiple arguments. If no such channel exists o r it existsbut the user is not currently in that channel, send the appropriate error message.• LIST – List all existing channels on the local server only. Your server should ignoreparameters and list all channels and the number of users on the local server in eachchannel.3Advanced Commands• PRIVMSG – Send messages to users. The target can be either a nickname or achannel. If the t arget is a channel, the message will be broadcast to every user o nthe specified channel, except t he message originator. If the target is a nickname, themessage will be sent only to that user.• WHO – Query information about client s or channels. In this project, your server onlyneeds to support querying channels on the local server. It should do an exact match onthe channel name and return the users on that channel.For all other commands, your server must return ERRUNKNOWNCOMMAND. If youare unable to implement one of the above commands (perhaps you ran out of time), yourserver must return the error code ERRUNKNOWNCOMMAND, rather than failing silently,or in some other manner.Your server should be able to support multiple clients concurrently. The only limit tothe number of concurrent clients should be the number of available file descriptors in t heoperating system (the min of ulimit -n and FDSETSIZE – typically 1024). While the serveris waiting for a client to send the next command, it should be able to handle inputs fromother clients. Also, your server should
View Full Document
Unlocking...