Client
The diagram below represents the general control flow of the Client. Study the figure carefully and ask clarification question on piazza.
The client begins by automatically using the command line args (see usage below) to connect to the server. It then proceeds to the login stage which at this time will be automatic as all that needs to be sent to the server is the client’s username. However, use some planning when implementing this section as you will later add support to ask the user for a password while logging in. Upon a successful login your client proceeds to block on I/O Multiplexing, this means your program is waiting on input from either the server’s socket or stdin.
- When receiving input your program will diverge depending on where the input comes from. In the case of stdin your client will handle the command given and do what is described below for the given command.
- When receiving input from the server socket, your program will handle the protocol as described in the document. One example would be, printing the time logged when the EM IT verb is received from the server.
Usage:
1 | ./client [-hcv] NAME SERVER_IP SERVER_PORT |
To make things easier to read, use the ansii escape codes to help color your messages on the client as you did with the server.
WOLFIE Protocol
Now we will attempt to describe the protocol. This is how the server and client program communicate with each other. It is important that you follow the protocol described exactly. During the grading process we will test your client program with a server we have made and your server with a client we have made. As long as you follow the protocol correctly none of this should matter.
In the diagrams we use the symbol CR to represent \r and NL to represent \n (The software that creates the diagram parses \n as a newline so we had to change the symbols). You must replace all occurrences of CR NL with the correct values.
Example:1
IAM student CR NL CR NL
should be translated to1
IAM student \r\n\r\n
Login to the server
When the server accepts the client connection request, it will immediately spawn a login thread to handle the login work. The client will initiate the login transaction with the server by sending the WOLFIE verb to the server. The server will respond to the client by replying with EIFLOW (wolfie backwards). Then the server can expect the client to identify itself with the IAM verb. If everything is correct, the server will respond with HI. At this point the client is logged in. You should retain their login time in the data structure you employed to store user information. You can now send a follow up message to the client which alerts them to the message of the day by sending MOTD. The MOTD should print out on the client upon receipt.
The ellipses … represent that there is more communication further down, but just not illustrated in this part of the diagram.
Failed login
It is possible for a login attempt to fail. If a user logs in using the same name as someone already connected, the server should reject that user. The server will send the ERR verb followed by theand the corresponding.
A list of all error codes can be located at the end of the document.
Logout (client Initiates)
When the user types /logout into their terminal, it begins the process of disconnecting cleanly. The client will send BYE and then receive a BYE response from the server. Implementing the client so that it waits for confirmation from the server is a polite way of making sure the server has properly removed the user from it’s data structures and is in an acceptable state for the user to then disconnect.
Shutdown (server initiates)
Finally if the user were to type /shutdown it would initiate the above protocol to terminate the connection with all connected users. It will send BYE to ALL CONNECTED USERS. It would then clean up any open files and sockets it may have open and then terminate.