复旦大学：《计算机网络 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

sRcc The since program takes input from stdin as client commands to send to the server, and echoes server reply on the screen. This can be used to checktheexactformatsofresponses fromyour server andtest how your server behaveswhengiven input is not compliant with the IRC specification unix>/srcc -h usage: srcc and port> are the address and port number of your IRC server By default, the address is set to your local machine and the port number is 666 n order to avoid port collisions from different people, use port numbers in the range: [20000+last 2 bits of your student number*100, 20000-+ last 2 bits of your student number*100+99] For example, if your last 2 bits of your student number is 23, then you should choose the ort numbers from the following range: [22300, 22399] For project 1, you only need one server, o the address can be the following Node id IP Address Routing port Local port IRC Port 1270.0.1 22300 22301 22302 IRC Test scripts The test scripts test your IRC server against different types of commands. For example login. exp checks the replies of the command niCK and USer /lo usage: login.expand<portare the address and port number of your IRC server You may use the provided test scripts as a base to build your own test case. You may also find the following tools to be useful in your test code development expect Quoting from the expect man page, Expect is a program that"talks"to other interactive programs according to a script. Following the script, Expect knows what can be expected from a program and what the correct response should be. An interpreted language provides branching and high-level control structures to direct the dialogue 8 Hand in Your code should submitted/p:∥0.32.141.33lase0/02计算机网终 /WORK UPLOAD/Project 1/,name Checkpoint 1-/Project 1/YOUR STUDENT ID/checkpoint Final Hand-in-/Project1/ YOUR STUDENT ID/final your repository should contain the following files Makefile- Make sure all the variables and paths are set correctly such that your program compiles in the handin directory. The Makefile should build executable named sired

6 sircc: The sircc program takes input from stdin as client commands to send to the server, and echoes server reply on the screen. This can be used to checktheexactformatsofresponses fromyour server andtest how your server behaveswhengiven input is not compliant with the IRC specification. unix>./sircc -h usage: sircc When using sircc, and are the address and port number of your IRC server. By default, the address is set to your local machine and the port number is 6667. ports: In order to avoid port collisions from different people, use port numbers in the range: [20000+last 2 bits of your student number*100, 20000+ last 2 bits of your student number *100+99] For example, if your last 2 bits of your student number is 23, then you should choose the port numbers from the following range: [22300, 22399]. For project 1, you only need one server, so the address can be the following: Node ID IP Address Routing Port Local Port IRC Port 1 127.0.0.1 22300 22301 22302 IRC Test scripts: The test scripts test your IRC server against different types of commands. For example, login.exp checks the replies of the command NICK and USER. unix>./login.exp usage:login.exp Here andare the address and port number of your IRC server. You may use the provided test scripts as a base to build your own test case. You may also find the following tools to be useful in your test code development: expect Quoting from the expect man page, Expect is a program that "talks" to other interactive programs according to a script. Following the script, Expect knows what can be expected from a program and what the correct response should be. An interpreted language provides branching and high-level control structures to direct the dialogue. 8 Hand in Your code should submitted ftp://10.132.141.33/classes/08/102 计算机网络 /WORK_UPLOAD/Project 1/, name • Checkpoint1 - /Project1/ YOUR_STUDENT_ID/checkpoint • Final Hand-in - /Project1/ YOUR_STUDENT_ID/final, your repository should contain the following files: • Makefile - Make sure all the variables and paths are set correctly such that your program compiles in the handin directory. The Makefile should build executable named sircd

All of your source code-(files ending with c, h, etc. only, no o files and no executables Design doc- File containing a brief description of your design of your IRC server. tests txt- File containing documentation of your test cases and any known issues you Grading Server core networking: 20 points The grade in this section is intended to reflect your ability to write the"core networking code. This is the stuff that deals with setting up connections, reading/writing from them(see the resources section below). Even if your server does not implement any IRC commands, your project submission can get up to 20 points here. Thus it is better to have partial functionality working solidly than lots of code that doesn't actually do anything correctl Server IrC protocol: 25 points The grade in this section reflects how well you read, interpreted, and implemented the IRC tocol. We will test that all the commands specified in the project handout work. All commands sent to your server for this part of the testing will be valid. So a server that completely and correctly implements the specified commands, even if it does not check for invalid messages, will receive Robustness: 25 points Server robustness: 13 points Since code quality is of a high priority in server programming, we will test your program in a variety of ways using a series of test cases. For example, we will send your server a message longer than 512 bytes to test if there is a buffer overflow We will make sure that your server does something reasonable when given an unknown command, or a command with invalid arguments We will verify that your server correctly handles clients that leave abruptly(without sending a QUIT message). We will test that your server correctly handles concurrent requests from multiple clients, without blocking inappropriately. The only exception is that your server may block while doing dNs lookups However, there are many corner cases that the rFC does not specify. You will find that this is very common in"real world"programming since it is difficult to foresee all the problems that light arise. Therefore, we will not require your server pass all of the testcases in order to get a full poin We will also look at your own documented testcases to evaluate how you tested your work

7 • All of your source code - (files ending with .c, .h, etc. only, no .o files and no executables) • Design.doc - File containing a brief description of your design of your IRC server. • tests.txt - File containing documentation of your test cases and any known issues you have. 9 Grading • Server core networking: 20 points The grade in this section is intended to reflect your ability to write the "core" networking code. This is the stuff that deals with setting up connections, reading/writing from them (see the resources section below). Even if your server does not implement any IRC commands, your project submission can get up to 20 points here. Thus it is better to have partial functionality working solidly than lots of code that doesn't actually do anything correctly. • Server IRC protocol: 25 points The grade in this section reflects how well you read, interpreted, and implemented the IRC protocol. We will test that all the commands specified in the project handout work. All commands sent to your server for this part of the testing will be valid. So a server that completely and correctly implements the specified commands, even if it does not check for invalid messages, will receive 20 points here. • Robustness: 25 points - Server robustness: 13 points -Testcases: 12 points Since code quality is of a high priority in server programming, we will test your program in a variety of ways using a series of test cases. For example, we will send your server a message longer than 512 bytes to test if there is a buffer overflow. We will make sure that your server does something reasonable when given an unknown command, or a command with invalid arguments. We will verify that your server correctly handles clients that leave abruptly (without sending a QUIT message). We will test that your server correctly handles concurrent requests from multiple clients, without blocking inappropriately. The only exception is that your server may block while doing DNS lookups. However, there are many corner cases that the RFC does not specify. You will find that this is very common in "real world" programming since it is difficult to foresee all the problems that might arise. Therefore, we will not require your server pass all of the testcases in order to get a full 25 points. We will also look at your own documented testcases to evaluate how you tested your work