Peer to Peer Instant Messaging

Transcription

1 Peer to Peer Instant Messaging Assignment in Computer Networks I, Department of Information Technology, Uppsala University. Overview In this assignment you will implement an instant messaging system that uses a central server to handle user status. The assignment is divided into four stages, and in each stage you will extend your client to handle more types of messages and implement higher functionality. At the end of the assignment you will have an instant messaging client that can talk to other clients and maintain an encrypted connection to the server. 1

2 1 General Problem Description The purpose of this assignment is to implement a simple peer-to-peer instant messaging client with a central server that keeps track of who is online. All communication will use TCP with messages in clear text. This is to make debugging easier. A code skeleton in C is provided for the client. You are not required to use this skeleton, but you are highly recommended to do so. The code skeleton implements list handling, and parsing input from the standard input among other things. The idea is that you should focus on the network programming part, and should not have to care about things not relating to this subject. A java skeleton is also available but it is untested and there will be no java specific support. This assignment is divided into four stages, which are: 1. Implement simple authorization with the server. 2. Handle PING-messages. 3. Handle the list of users online. 4. Communicating with other peers. To see a full description of the stages see section 2. All the messages are described in section 3, and the code skeleton in 4. The stages build on each other, and you should reuse and extend your code from a previous stage when you implement the current one. Some stages will force you to change things in the code from previous stages, but the changes will be small. See section 5 for information about hand-in instructions. It is important that you follow these instructions to pass the assignment! 1.1 Important Things to Think About The messages are in clear text, remember that when debugging. Never send ints and other types, messages should only be character strings. Remember to use network byte order. If you don t, you will run into problem when dealing with port numbers and IP-addresses. Check return values from system calls, as for example send or recv. These can tell you if the server or another peer has closed the connection. 2

3 If there is an internal error in the server that it cannot deal with, for example it runs out of memory it will terminate your connection. If that happens, try re-connecting. Beej s socket guide is an excellent source of information on socket programming. You can find it at: 3

4 2 Project Stages Stage 1: Connecting to, and authorizing with, the server In short: 1. Connect to the server 2. Implement and send an ATH1 message to initiate authorization with the server. 3. Handle the ATH2 response to the server 4. Handle the ERRO messages from the server. In this part of the lab you will use simple client/server interaction to register your peer at the server. You will need to compose a correct ATH1 command, send it to the server and handle the ATH2 message the server will send back. Refer to the Messages chapter to see how these messages are defined. You can safely drop any other messages you receive from the server. However, it might be worthwhile to handle the ERRO messages the server will send if something is wrong, as it could help you with debugging. These messages contain a string with the error, and should give you a hint of what is wrong. If you keep getting NO from the server, make sure that your ATH1 message is correctly formatted. There is no need to log out, simply closing the socket will make the server register you as offline. Functions to implement/edit connecttohost(): Set up a socket to the server. authenticate(): Send your login information to the server. parsemessagefromserver(): Handle data from the server. Remember to check return values from functions! Testing Test this stage by connecting to the server and authorize and then check the server web page to see if it has correctly identified you. If it has identified you, your peer should appear in the Users online table. 4

5 When the server is convinced you have successfully accomplished this stage it will record stage one done, which you can see on the same web-page. 5

6 Stage 2: Handling PINGs In short: 1. Answer PING messages sent by the server. Extend the code from stage 1 so that it answers the PING messages sent periodically from the server. The server uses these messages to ensure that the peers registered as online really are online. As soon as the server receives PONG from you in response to a PING sent by the server it will register you as having finished the second stage. After this the server will consider you offline if you fail to answer to two consecutive PING messages. Functions to implement/edit parsemessagefromserver(): Handle data from the server. Testing Check your current status on the servers web page when you think you have completed this stage. 6

7 Stage 3: Handling online messages In short: 1. Handle ONLN and OFLN messages sent from the server. 2. Keep track of other peers that are online. 3. Rewrite the PONG message. In order to keep track of which peers that are currently online each peer must maintain a list of online users. The server has a master list with all peers that are online and will send this out to a peer as soon as the peer is authorized. After this the server will only send out changes to this list when new users go online or when users go offline. Observe that your own peer will be present in the first list you receive from the server as you go online! The list will come as a series of ONLN messages, which you must handle and insert the given users in your online list. Note that there is no guarantee that the ONLN messages will appear in any special order, and there might be other messages between the messages (e.g. PING messages). When new users come online you will receive ONLN messages and when users go offline you will receive OFLN messages, and you have to update your user-list to reflect the users currently online. In order for the server to know that you have completed this stage it needs to know that you have a correct view of who are online. To achieve this you will now need to change the PONG message so it includes the numbers of users online and the user id s of all the users you think are online. The pong message will now look Where N is the number of users online and uid 1 through uid N are their user ids # and % as start, split and end token, note that this is not how it will look in reality, the real start, split and end tokens are not printable characters). Please observe that it may take a couple of PONG-messages before the server is convinced that you have finished this stage, as some user may go online or offline while you are sending this message. This will make the server falsely believe that your user list is incorrect, but this should even itself out after a few messages. 7

8 Functions to implement/edit parsemessagefromserver(): Handle data from the server. Also, you need to have a Userlist to store user information in. Take a long good look at the functions in userlist.h. Testing This stage can be tested by comparing your view of who are online is the same as the one presented on the servers web page, and that the server has registered you as having completed stage 3. 8

9 Stage 4: Messages to other peers In short: 1. Establishing connections with other peers 2. Sending and receiving MESG messages Now you will begin communicating with other peers that are online. The peers communicate by sending and receiving MESG messages containing the user id of the peer you are trying to talk to and the text of the message. After a successful authentication it s time to start listening for incoming connections. You should bind 1 a listening socket to the port stored in the variable listenport. It s best to do it at the beginning of the program so you know if the port is already in use or not, although It s fine to do it later. When you have authenticated yourself, begin listening on that socket. Functions to implement/edit sendmessage(): Send messages to peers (and the server too). parsemessagefromclient(): Handle data from other peers. Testing Test this stage by talking to other peers that are online. If you cannot initiate a connection with the other peers, you can try the peer-bot, with whom you can communicate. Managing to talk to the peer-bot is also required to convince the server that you have completed this stage. To communicate with the peer-bot you need to send a special command message to the server in the form of a regular MESG message with the text testmsg. The server has uid 0, so the command at the prompt in the client would look something like: msg 0 testmsg Once the server gets this message it will inform the peer-bot that you are ready to talk to it, and you will receive a message from the bot. Respond to the question in the message, and hopefully you will receive a message from the bot telling you that you have completed stage 4. If something is wrong, error. 1 Take a look at the socket reuse option so you can avoid the socket already in use 9

10 you will receive either an ERRO message from the server or a message from the peer-bot. 10

11 3 Messages All messages in this assignment are clear text strings, to make debugging easier. However, when you start encrypting messages, this will of course not be true anymore. Note that this means you will always have to convert numbers to strings if you want to send them in a message. The messages are all on the same form: START_TOKEN type SPLIT_TOKEN text of message END_TOKEN Where the text of the message can contain several SPLIT TOKEN to divide the message in several fields. The type field is always four bytes long, and the type is always in upper-case. The START TOKEN is defined to be ASCII character 1, SPLIT TOKEN is ASCII character 30 and END TOKEN is character 4. However, you should not need to worry about this, as they are defined in common.h and you can match them for example like this: if(char == END_TOKEN) {... } In the description below, the START TOKEN is represented SPLIT TOKEN as # and END TOKEN as %. Note that this is just for readability, as the real tokens are below ASCII character 32 and therefore not printable. The messages are: MESG This is the message type for sending messages to other peers and contains your own uid and the text of the message. It is of the of message% ERRO This is an error message the server will send to you when it has gotten an ill formatted message from you or was expecting another message. The text of the message describes what the server thinks the problem of error% ONLN Describes that the user with user id uid is online at address address and listening for connections from other peers at port port. 11

12 @ONLN#uid#address#port% OFLN The user with user id uid has gone PING This message is sent periodically by the server, and should be answered by a PONG PONG The response to the PING message. This message is special as it has two different forms, depending on how far in the assignment you are. Up to stage two it will be on the In stage 3 and onwards you will need to include the number of users, say N, and the user ids of all these users. This is to make it possible for the server to auto-correct you user list. With N users the message would look ATH1 The message you will send to the server to initiate simple authorization without encryption. Contains your user id and password in clear text, and the port you are listening for connections from other peers ATH2 The response from the server to the ATH1 message. The response is either OK, if username and password were correct, NO if they were not, and AC if the server thinks you are already Of the above messages you need to be able to send: PONG to the server in response to PING. 12

13 ATH1 to the server to initiate simple authorization. MESG to other peers to communicate with them, and to send commands to the server. And you have to receive: PING from the server. ATH2 from the server which tells you if are authorized or not. ERRO from the server, which you can use for help with debugging. ONLN and OFLN from the server, telling you when users go online and offline. MESG from other peers. 13

14 4 Code Skeleton The code skeleton for the assignment can be downloaded from the course web page. It contains two directories: common/ and skel/. p2p/ -- common/ : The code library. Don t edit these files! --- commandparser.[ch] : For parsing standard input. Take a look. --- common.h : Common #defines. Take a look. --- crypto.[ch] : Cryptography functions. Take a look. --- messagelist.[ch] : The message list modules. no peeking! --- parsehelp.[ch] : Functions for helping you parse messages. You don t have to use them. --- userlist.[ch] : The user list modules. Take a look. -- skel/ : The skeleton. ---.p2prc : Config file for the client. Edit. --- Makefile : Makefile, just edit if you add new files or if you need to compile it on another platform (not encouraged though). --- README : README file. Light information about running the client. --- client.c : The main program. Edit this. --- useraction.[ch] : More functions. Edit this one too. Figure 1: Directory structure of source code tree. To make the client program just type make (or make linux ) in the skel/ directory. This should give you a client binary. Until you edit any files 2, this will compile the program and running it will give you the pretty p2p$ prompt. So far it can only handle the quit and help commands and it s your job to implement the rest of them. 2 Hopefully it will compile after you have edited files too :-) 14

15 5 Hand-in Instructions To pass the assignment you need to provide the complete source code for the stages you are supposed to solve. It is important that you follow the steps below: 1. Make sure that the client automatically compiles into a executable file by a make from the directory skel/. 2. Create a tar ball with the complete source tree as shown in figure 1. Name the tar ball p2p-{username}.tar.gz. Example: > tar zcvf p2p-krmo5621.tar.gz p2p/ 3. Fill in the form at the back of this compendium. Do not forget to provide a path to the source code in your home directory. Also make sure that the tar ball has the right permissions, i.e. it must be readable by others. 4. Hand in the form. If you do not follow these instructions your assignment will automatically be handed back to you without corrections. 15

16 Peer to Peer Instant Messaging Name(s): Login Name: Course and Course Code: Path to code: (e.g., /home/gujo8932/p2p-gujo8932.tar.gz) Date: Signature: 1