复旦大学：《计算机网络 Computer Networking》课程实验指导_因特网中继聊天（IRC）服务器_Network Project1 Request 2013.pdf

Overview An IRC network is composed of a set of nodes interconnected by virtual links in an arbitrary topology. Each node runs a process that we will call a routing daemon. Each routing daemon maintains a list of IRC users available to the system Figure I shows a sample IRC network composed of 5 nodes. The solid lines represent virtual links between the nodes. Each node publishes a set of users(i.e, the nicks of the IRC clients connected to it)to the system. The dotted lines connect the nodes to their user sets The usage model is the following: If Bob wants to contact Alice the iRC server on the left first must find the route or path from it to the node on the right. Then, it must forward Bob's message to each node along the path(the dashed line in the figure)until it reaches the IRC server at Alices node. which can then send the message to the client alice In this project, you only need to implement a standalone IRC server. You can assume that there is only one IRC server and all clients are connected to the server. RC Sorver outing Proloc Figure 1: IRC network 4 Definitions nodeID-unique identifier that identifies an IRC server, or node In the first project, the nodeld for the standalone irc server should be 1 destination-IRC nickname or channel as a null terminated character string. As per the irC RFC, destinations will be at most 9 characters long and may not contain spaces IRC port- The TCP port on the IRC server that talks to clients Note: In Project 1, only TCP port which is used to talks to clients are needed, and only l serve ssumed. But in Project2, IRC router is required to be implemented. And IRC Server needs to be expanded to implement more IRC Command to talk with IRC router. So consideration to extend your code is necessary for convenience of reuse your code in Project2 The Irc server Your server will implement a subset of the original IRC protocol. The original IRC protocol is IRC server, we have provided an annotated version of the RFC [4]. For this project, you should defined in RFC 14593. Because RFC 1459 omits some details that are required to implement

2 3 Overview An IRC network is composed of a set of nodes interconnected by virtual links in an arbitrary topology. Each node runs a process that we will call a routing daemon. Each routing daemon maintains a list of IRC users available to the system. Figure 1 shows a sample IRC network composed of 5 nodes. The solid lines represent virtual links between the nodes. Each node publishes a set of users (i.e., the nicks of the IRC clients connected to it) to the system. The dotted lines connect the nodes to their user sets. The usage model is the following: If Bob wants to contact Alice; the IRC server on the left first must find the route or path from it to the node on the right. Then, it must forward Bob's message to each node along the path (the dashed line in the figure) until it reaches the 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 can assume that there is only one IRC server and all clients are connected to the server. Figure 1: IRC network 4 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. As per the IRC RFC, destinations will be at most 9 characters long and may not contain spaces. • IRC port - The TCP port on the IRC server that talks to clients. Note: In Project 1, only TCP port which is used to talks to clients are needed, and only 1 server is assumed. But in Project2, IRC router is required to be implemented. And IRC Server needs to be expanded to implement more IRC Command to talk with IRC router. So consideration to extend your code is necessary for convenience of reuse your code in Project2. 5 The IRC Server Your server will implement a subset of the original IRC protocol. The original IRC protocol is defined in RFC 1459 [3]. Because RFC 1459 omits some details that are required to implement an IRC server, we have provided an annotated version of the RFC [4]. For this project, you should

al ways 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 a concurrent network application without spending an inordinate amount of time implementing lots of features Specifically, your server must implement the following commands Basic Commands NICK-Give the user a nickname or change the previous one. Your server should handle plicate 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 to all other users sharing the channel with the departing client Channel commands JOIN -Start listening to a specific channel. Although the standard irC protocol allows a client to join multiple channels simultaneously, your server should restrict a client to be a member of at most one channel. Joining a new channel should implicitly cause the client to leave the current channel PART-Depart a specific channel. Though a user may only be in one channel at a time, PART should still handle multiple arguments. If no such channel exists or it exists but 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 ignore arameters and list all channels and the number of users on the local server in each channel Advanced commands PRIVMSG-Send messages to users. The target can be either a nickname or a channel. If the target is a channel, the message will be broadcast to every user on the specified channel, except the message originator. If the target is a nickname, the message will be sent only to that user WHO-Query information about clients or channels. In this project, your server only needs to support querying channels on the local server. It should do an exact match on the channel name and return the users on that channe For all other commands, your server must return ERR UNKNOWNCOMMAND. If you are unable to implement one of the above commands(perhaps you ran out of time),your server must return the error code ERR UNKNOWNCOMMAND, rather than failing silently, or in some other manner Your server should be able to support multiple clients concurrently. The only limit to the number of concurrent clients should be the number of available file descriptors in the operating system(the min of ulimit-n and FD SETSIZE-typically 1024). While the server is waiting for a client to send the next command, it should be able to handle inputs from other clients. Also, your server should not hang up if a client sends only a partial command. In general, concurrency can be Ither select or multiple threads. However, in this proje your server using select to support concurrent connections. See the resources section below for help on these topics As a public server, your implementation should be robust to client errors. For example, your server should be able to handle multiple commands in one packet. It must not overflow any buffers when the client sends a message that is too long(longer than 512 bytes). In general, your

3 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 a concurrent network application without spending an inordinate amount of time implementing lots of features. Specifically, your server must implement the following commands: Basic Commands • NICK - Give the user a nickname or change the previous one. Your server should handle 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 to all other users sharing the channel with the departing client. Channel Commands • JOIN - Start listening to a specific channel. Although the standard IRC protocol allows a client to join multiple channels simultaneously, your server should restrict a client to be a member of at most one channel. Joining a new channel should implicitly cause the client to leave the current channel. • PART - Depart a specific channel. Though a user may only be in one channel at a time, PART should still handle multiple arguments. If no such channel exists or it exists but 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 ignore parameters and list all channels and the number of users on the local server in each channel. Advanced Commands • PRIVMSG - Send messages to users. The target can be either a nickname or a channel. If the target is a channel, the message will be broadcast to every user on the specified channel, except the message originator. If the target is a nickname, the message will be sent only to that user. • WHO - Query information about clients or channels. In this project, your server only needs to support querying channels on the local server. It should do an exact match on the channel name and return the users on that channel. For all other commands, your server must return ERR UNKNOWNCOMMAND. If you are unable to implement one of the above commands (perhaps you ran out of time), your server must return the error code ERR UNKNOWNCOMMAND, rather than failing silently, or in some other manner. Your server should be able to support multiple clients concurrently. The only limit to the number of concurrent clients should be the number of available file descriptors in the operating system (the min of ulimit -n and FD SETSIZE - typically 1024). While the server is waiting for a client to send the next command, it should be able to handle inputs from other clients. Also, your server should not hang up if a client sends only a partial command. In general, concurrency can be achieved using either select or multiple threads. However, in this project, you must implement your server using select to support concurrent connections. See the resources section below for help on these topics. As a public server, your implementation should be robust to client errors. For example, your server should be able to handle multiple commands in one packet. It must not overflow any buffers when the client sends a message that is too long (longer than 512 bytes). In general, your

erver should not be vulnerable to a malicious client. This is something we will test for Note your server behaves differently from a standard iRC server for some of the required commands(e.g, JOIN). Therefore, you should not use a standard iRC server as your reference for your implementation. Instead, refer to the annotated version of the rfc on the course web page Testing and debugging of your IRC server can be done with our provided sircc client(discussed later in section 7), or a telnet client for issuing commands and receiving responses 6 Implementation Details and usage Your programs must be written in the C or C++ programming language. You are not library functions, and the csapp wrapper library developed for ICS. You may use the pthread o- allowed to use any custom socket classes or libraries, only the standard libsocket, the provide library, but you are responsible for learning how to use it correctly yourself if you choose to To use the csapp wrapper library, you must link with libpthread(-lpthread ) If you wish to use other libraries, please contact us 6.1 Compiling You responsible for making sure your code compile and run correctly on the x86 machines running Linux. We recommend using gcc to compile your program and gdb to debug it. You nould use the-Wall flag when compiling to generate full warnings and to help debug. Other tools available are suggested are ElectricFence [7(link with-lefence)and Valgrind [8]. These tools will detect overflows and memory leaks respectively. For this project, you will also be responsible for turning in a GNUMake(gmake)compatible Makefile. See the gNU make manual [5]for details. When we run gmake we should end up with the simplified IRC Server which you should call sired 6.2 Command Line arguments Your IRC server will al ways have two arguments usage:. /sired nodeld config file nodeld- The nodeld of the node should be l for the standalone irc server configfile -The configuration filename Configuration File Format This file describes the neighborhood of a node. In this project, since there are no neighbors other than the standalone server itself, the file is used to specify the rFC port used by the server. The format of the configuration file is very simple, and we will supply you with code to parse it. Note that most of the fields will become important only in the next project. Each line has the following format nodeld hostname routing-port local-port IRC-port nodeld An identifier of the server(it should match the nodeld argument when starting the IrC server) hostname

4 server should not be vulnerable to a malicious client. This is something we will test for. Note your server behaves differently from a standard IRC server for some of the required commands (e.g., JOIN). Therefore, you should not use a standard IRC server as your reference for your implementation. Instead, refer to the annotated version of the RFC on the course web page. Testing and debugging of your IRC server can be done with our provided sircc client(discussed later in section 7), or a telnet client for issuing commands and receiving responses. 6 Implementation Details and Usage Your programs must be written in the C or C++ programming language. You are not allowed to use any custom socket classes or libraries, only the standard libsocket, the provided library functions, and the csapp wrapper library developed for ICS. You may use the pthread library, but you are responsible for learning how to use it correctly yourself if you choose to. To use the csapp wrapper library, you must link with libpthread (-lpthread). If you wish to use other libraries, please contact us. 6.1 Compiling You responsible for making sure your code compile and run correctly on the x86 machines running Linux. We recommend using gcc to compile your program and gdb to debug it. You should use the -Wall flag when compiling to generate full warnings and to help debug. Other tools available are suggested are ElectricFence [7] (link with -lefence) and Valgrind [8]. These tools will detect overflows and memory leaks respectively. For this project, you will also be responsible for turning in a GNUMake (gmake) compatible Makefile. See the GNU make manual [5] for details. When we run gmake we should end up with the simplified IRC Server which you should call sircd. 6.2 Command Line Arguments Your IRC server will always have two arguments: usage: ./sircd nodeID config_ file nodeID -The nodeID of the node, should be 1 for the standalone IRC server. configfile -The configuration filename. 6.3 Configuration File Format This file describes the neighborhood of a node. In this project, since there are no neighbors other than the standalone server itself, the file is used to specify the RFC port used by the server. The format of the configuration file is very simple, and we will supply you with code to parse it. Note that most of the fields will become important only in the next project. Each line has the following format: nodeID hostname routing-port local-port IRC-port nodeID An identifier of the server (it should match the nodeID argument when starting the IRC server). hostname

The name or iP address of the machine where the neighbor node is running, it should be localhost for the standalone server local-por The TCP port on which the routing daemon should listen for the local IRC server and you can ignore this routing-port The port where the neighbor node listens for routing messages and you can ignore this IRC-Dort The tCP port on which the IRC server listens for clients and other IRC servers, you should specify the port to use How does a node find out which ports it should use as IRC ports? When reading the configuration file, if an entry's nodeld matches the node's nodeld of the node(passed in on the command line), the node uses the specified port number as RFC port This is how we will start your IRC network /sired 1 node 1. conf The IRC Server will be passed its nodeld and the configuration file to find out about what rts it should use/talk to 6.5 Framework Code We have provided you with some frame work code to simplify some tasks for you, like reading in the command line arguments and parsing the configuration file. You do not have to use any of this code if you do not want to. This code is documented in rtlib h and implemented in rtlib c. Feel free to modify this code also Testing Code quality is of particular importance to server robustness in the presence of client errors and malicious attacks. Thus, a large part of this assignment(and programming in general)is knowing how to test and debug your work. There are many ways to do this; be creative. We would like to know how you tested your server and how you convinced yourself it actually works. To this end you should submit your test code along with brief documentation describing what you did to test that your server works. The test cases should include both generic ones that check the server functionality and those that test particular corner cases. If your server fails on some tests and you do not have time to fix it, this should also be documented we would rather appreciate that you know and acknowledge the pitfalls of your server, than miss them). Several paragraphs(or even a bulleted list of things done and why) should suffice for the test case documentation To help you get started on testing, we have provided a simple irC client srcc and several example test scripts. These will give you an idea of what tests we will use to evaluate your work, and ensure that you are on the right track with your server

5 The name or IP address of the machine where the neighbor node is running, it should be localhost for the standalone server. local-port The TCP port on which the routing daemon should listen for the local IRC server and you can ignore this. routing-port The port where the neighbor node listens for routing messages and you can ignore this. IRC-port The TCP port on which the IRC server listens for clients and other IRC servers, you should specify the port to use. How does a node find out which ports it should use as IRC ports? When reading the configuration file, if an entry's nodeID matches the node's nodeID of the node (passed in on the command line), the node uses the specified port number as RFC port. 6.4 Running This is how we will start your IRC network. ./sircd 1 node1.conf The IRC Server will be passed its nodeID and the configuration file to find out about what ports it should use/talk to. 6.5 Framework Code We have provided you with some framework code to simplify some tasks for you, like reading in the command line arguments and parsing the configuration file. You do not have to use any of this code if you do not want to. This code is documented in rtlib.h and implemented in rtlib.c. Feel free to modify this code also. 7 Testing Code quality is of particular importance to server robustness in the presence of client errors and malicious attacks. Thus, a large part of this assignment (and programming in general) is knowing how to test and debug your work. There are many ways to do this; be creative. We would like to know how you tested your server and how you convinced yourself it actually works. To this end, you should submit your test code along with brief documentation describing what you did to test that your server works. The test cases should include both generic ones that check the server functionality and those that test particular corner cases. If your server fails on some tests and you do not have time to fix it, this should also be documented (we would rather appreciate that you know and acknowledge the pitfalls of your server, than miss them). Several paragraphs (or even a bulleted list of things done and why) should suffice for the test case documentation. To help you get started on testing, we have provided a simple IRC client sircc and several example test scripts. These will give you an idea of what tests we will use to evaluate your work, and ensure that you are on the right track with your server