Grading procedure

Deadlines

Demo sessions

• For this lab, you must verbally demonstrate your code to one of the teaching assistants during one of the demo sessions. There will be 3 Demo sessions are held on Thursday Feb. 26th.

• Both group members will be required to answer questions about your code.

• You must book a timeslot for the session during which you will perform your demonstration. Pick one slot per group and register with your Fire group number.

• You must submit your code through Fire before coming to the demo session. No code submitted = no verbal demo!

• You may be required to make corrections to your source code and resubmit. The final deadline for resubmissions is Sunday Mar. 15th, 23:59.

Introduction to CCHAT

Check how to install Erlang/OTP in your computer!

Building a "real" concurrent system is not easy. In this lab, we aims put you through some of that experience. You will need to make design decisions, evaluate the trade-off between performance and simplicity, face debugging, and much more. While challenging, it is plenty of fun!

The topic

Nowadays, messaging systems are very popular (Whatsapp, Snapchat, Facebook chat, etc.). They provide great connectivity to users as well as different features like stickers, videos clips, etc. In this lab, you will build a simple (but still quite real) text-based messaging system called CCHAT (the first C is from Chalmers). CCHAT is very much inspired by IRC, an old but still valid standard designed for group discussions. For simplicity, and reasons of time, your implementation of CCHAT is not going to use IRC's protocol nor low-level TCP/IP communication. Instead, it will leverage Erlang's processes and message passing features.

A first look

Below, you can find a short video of how CCHAT will look and work.

Here, some details about the demo.

• Command cchat:server() starts a chat server called shire. For the rest of the lab, users connect to that server.

• Command cchat:client() opens a new client window. The GUI is basic, but the good news is that you do not have to implement it yourselves.

• The user interface has a System tab. This tab has the purpose of showing the activities carried out by different domains as well as reporting errors. For instance, when connecting to the shire, you saw the following on the system tab:

    * Trying to connect to shire...
    + Connected! 

• The chat server cannot have two users connected using the same name. By default, the GUI utilizes the nickname user01. The command /nick <username> changes the nickname to <username>. The format for username is the same as for an Erlang's atom, i.e., it will start with a lower case letter and followed by letters, numbers, or underscore (_). For this lab, you only need to handle changing the client's nickname when disconnected from the server.

• In order to chat, bilbo joined to the discussion group (or channel) #hobbits with the command /join #hobbits. By convention, all the channels' names start with #.

• Then, frodo joined to the same channel. After a small, chat frodo left the channel using the command /leave. Then, he disconnected from the server by issuing the command /disconnect. Similarly, bilbo executed the same commands and finally closed the application.

Architecture

CCHAT will use a client-server architecture. It consists on a client part, which runs the GUI and a client process, and a server which runs the chat service (server process) and host the discussions groups. The graphic below illustrates the situation.

In the graphic above, the client process (blue circle with double lines) has the goal to be a bridge between the GUI and the server process (the other blue circle with double lines).

• Location of the client and server processes

  The picture suggests that the client and server processes might be located in different machines. Nevertheless, and for simplicity, we will consider that all the processes are located on the same local machine. If you get the implementation of CCHAT right, you will be able to easily adapted to run in a distributed environment. This is one of the great aspects of Erlang!

• The GUI and the client process

  The GUI will interact with the client process through a specific protocol (described below). You do not need to implement the GUI, we will give it to you. Instead, you need to provide a implementation of the client process. Your implementation should know how to interact with the GUI, i.e., it should follow the GUI protocol (to be explained later on).

• The server process

  The server handles the requests coming from the clients. The protocol being used between a client and the server is up to you. You have complete freedom to implement the server process as you want. Take into account that the chat server might be composed by several processes, not only the one that you see in the picture above. You have to think of the parts of your code in which the fact of having more processes would increase the concurrency of your application. Remember to keep your code simple.

The GUI and the client process

The protocol

The protocol between the GUI and the client process is partly fixed. The reason for that is two fold. Firstly, by following the protocol, you will be able to use the GUI without knowing its internal implementation details. Secondly, and more importantly, we will test your code assuming that your client process follow the protocol. If you do not follow it, your code will not pass the tests (see the test section below) and your submission will be immediately rejected.

The protocol scheme is as follows.

The GUI sends a message Message requesting some operations. Then, the Client either replies with the atom ok or {error, Atom, Text}. Atom ok indicates that the operation succeeded. Tuple {error, Atom, Text} denotes that something went wrong while processing the request. These errors are not fatal and the GUI can recover from them. Variable Text contains the text to be reported in the System tab of the GUI. You are free to choose the value of Text. However, you should strictly use the values for Atom as described by the protocol.

• Connecting to the server

  When the user writes the command /connect Server, the GUI sends the message {connect, Server} to the client process, where variable Server denotes the name of the chat server chosen by the user.

  Atom user_already_connected is used when the user tried to connect but it is already connected to the server. Atom server_not_reached is returned when the server process cannot be reached for any reason.

• Disconnecting from the server

  When the user writes the command /disconnect, the GUI sends the message disconnect to the client process. It is possible to disconnect from a server only if the user has left all the chat rooms (i.e. channels) first.

  Atom user_not_connected is returned when a user tries to disconnect from a server where he/she is not connected to. Atom leave_channels_first is returned when a user tries to disconnect from a server without leaving the chat rooms first. Lastly, atom server_not_reached is used when the server process cannot be reached for any reason.

• Joining a chat room

  To join a chat room, users write the command /join Chatroom, where Chatroom is a string starting with #, e.g., #hobbits. The GUI sends the message {join, Chatroom}.

  Internally, if the chat room does not exists in the server side, the server process will create it. We assume that, once created, chat rooms are never destroyed, i.e., they will always exist as long as the server runs. Bear in mind that only users who have joined a chat room can write messages on it.

  Atom user_already_joined is return when a user tries to join to the same channel again.

• Writing messages in a chat room

  When the user is in a chat room and writes an string (not started with /), the GUI sends the message {msg_from_GUI, Chatroom, String} where variable Chatroom contains the name of the channel as an string (e.g. "#hobbits") and variable String stores the typed string (e.g. "hello fellow hobbits").

  Atom user_not_joined is returned when a user tries to write a message in a channel that he/she has not joined.

• Leaving a chat room

  When the user types /leave in a chat room, the GUI sends the message {leave, Chatroom}, where variable Chatroom contains the name of the chat room.

  Atom user_not_joined is returned when a user tries to leave a channel that he/she has not joined.

• Asking for the nickname

  When the user writes the command /whoami, the GUI sends the message whoami to the client process. The client should respond with the nick as a string (instead of the atom ok). There are no errors to report in this case.

• Changing the nickname

  When the user writes the command /nick Name, the GUI sends the message {nick, Name} to the client process. Variable Name contains the new chosen nickname for the user.

  To make things easier, you only need to support changing nick when the user is disconnected. Return atom user_already_connected if the user attempts to change nick when connected.

  Optional: If you wish to implement changing the nick when connected, you should return atom nick_taken when trying to change to nick that is already taken.

Until this point, the protocol describes communications initiated by the GUI. There is only one occasion when the client process starts communication with the GUI: when something is written to a channel, the client needs to tell the GUI to display the new text. The client process sends the message {msg_to_GUI, Chatroom, Msg} when it wishes to print out the line Msg in the chat room Chatroom.

For that, we use the following line of code

gen_server:call(list_to_atom(GUIName), {msg_to_GUI, Chatroom, Name++"> "++Msg})

Where Name is the nick of the author and Msg is their message. Observe that gen_server is not the same as genserver (the module that has been shown in class). Module gen_server is the OTP implementation of a generic server..

Variable GUIName contains the name for the GUI process, which is generated in the gui.erl module and passed onto your client in client:initial_state/2.

Errors

• Fatal errors

  The client process has the chance to respond to the GUI with the tuple {'EXIT', Reason}. This tuple indicates to the GUI that something went very wrong on the client side, e.g. when the server process clashes in the middle of processing a request. The GUI will display the content of variable Reason and exit. You might see this behavior during development but it is clear that it should not appear in your submission when we will test it.

• Other errors

  When developing your solution, you might find yourself wondering "what if this fails?", "what should process A or B do then?", "should I modify my code to catch this error?", etc. If you want to take this road, you will go down the rabbit hole! Try to focus on making your solution work as described by the protocol above. For instance, you might decide to only report those errors described above, and making your solution crash if some other error occurs.

Code skeleton

In this lab, you are required to build the client and server processes based on the structure in the skeleton code. The main reason for that is to make it easier to have your lab up and running. You could use any Erlang code that we saw at the lectures if it helps you.

We will give you the following files:

 gui.erl lexgrm.erl grm.yrl lex.xrl 

 test_client.erl dummy_gui.erl 

 defs.hrl 

 client.erl 

 server.erl 

 cchat.erl 

 helper.erl 

To download it, click on the button that says "Download ZIP", or you can clone the entire repository using git clone.

After you download it (and extract the files) you should compile everything with make and start to perform the same demo as in the first video. You should be able to start the server and open up chat windows, but Bilbo and Frodo will not able to communicate because most of the functions are not implemented. It is your task to make sure that they can!

If you do not have GNU Make, you should run the following commands in the Erlang shell:

  cd("the directory where the skeleton code is").
  c(lexgrm).
  lexgrm:start().
  cover:compile_directory(). 

Tips

• The server process will be registered (using Erlang's register BIF) to an atom of the same name. So when the server name is shire, you can send messages directly to the atom shire without knowing the server's process ID. You might also want to check the function list_to_atom.

• From the Erlang shell, use the function cover:compile_directory/0 to re-compile all Erlang files in the current directory.

Test cases

All unit tests are contained in the file test_client.erl. Tests are carried out using EUnit. We have created entries in the Makefile to make life easier for you (see below for alternatives to using make). There are two sets of tests, correctness and performance tests.

The video below shows how to use the test suite (includes audio):

Correctness

There are positive and negative tests which check that your solution follows the requirements and protocol as specified above. To run these tests, execute the following:

$ make -s run_tests

Performance

We have also included two cases which test the performance of your solution by spawning large numbers of clients and channels simultaneously. To run them, use the command:

$ make -s run_perf_tests

This will run the 2 performance tests 3 times each: once using 4 cores, once with 2 cores, and once with only 1 core enabled. In each case you will see the time elapsed for the test case to complete. To test your use of concurrency, we expect that your solution will be significantly faster with more cores. The actual times do not matter much, as long as there is a noticeable improvement. Of course if you don't have 4 cores, then the first set of results will not be taken into consideration.

Alternatives to make

If your system doesn't have the make command, you can run the test suites like so:

Correctness

$ erl +P 1000000 -eval "cover:compile_directory(), eunit:test(test_client), halt()"

Performance

The number 4 below specifies the number of cores to use. Make sure to run this command with values 4, 2, and 1:

$ erl -smp +S 4 +P 1000000 -eval "cover:compile_directory(), eunit:test([{timeout, 60, {test,test_client,many_users_one_channel}},{timeout, 60, {test,test_client,many_users_many_channels}}]),halt()"

Turning off colour codes

If you don't have a colour-enabled terminal, you will see a lot of ugly colour codes in your test output. You can disable these by commenting out the colour function in test_client.erl and replacing it with:

colour(Num,S) -> S.

Submission

You should submit your code based on the skeleton code and whatever other files are needed for your solution to work. In addition, you should comment your code so that graders can easily review your submission.