This lab is basically an adaptation of CCHAT (Lab 3) for a distributed environment. When it comes to make your code distributed, Erlang is pretty good at it. Here, you will put that to the test!
DCHAT will use the same arquitecture as CCHAT, i.e., a client-server architecture. However, now you client process (and the GUI) should be able to communicate with your server located in another Erlang node (maybe in a different computer).
The GUI and the client process
The GUI will interact with the client process as before except that the CCHAT protocol is extended with one additional case (see below).
The server process
The server handles the requests coming from the clients as before, but it should be able to reply to a client located in another Erlang node (perhaps in another computer).
As before, the protocol between the GUI and the client process is partly fixed and follows the same scheme as in CCHAT. Below, we briefly describe the extra case.
Connecting to a remote server
When the user writes the command /connect {Server,Machine}
, the GUI sends the message
{connect, {Server, Machine} }
to the client process, where variable Server
denotes the
name of the chat server chosen by the user, Machine
the computer to connect
to (it has the shape 'name@IP'
, e.g., 'chalmers_irc@127.0.0.1'
).
Variable Atom
gets the follows values. 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.
Connecting to a local server
As in CCHAT, you can still use the command /connect Server
which
sends {connect, Server}
to the client. In this case you should
assume that your are connecting to a server on the same node as the
client & GUI.
You should use the same one given to CCHAT. Here, you can get the code skeleton!
Now, your software should pass the same test cases as before together with some extra ones designed to check if you adapted your code to work in a distributed environment. The test cases are given in the same testing framework (eunit) as we did previously.
The distributed tests are contained in the file test_remote.erl
(there is currently only one test case). To run these tests, make
sure to get the latest version of the code skeleton and execute the
following:
$ make -s run_distributed_tests
You should see the following output:
$ make -s run_distributed_tests Erlang R16B03 (erts-5.10.4) [source] [smp:4:4] [async-threads:10] [kernel-poll:false] Eshell V5.10.4 (abort with ^G) (testsuite@127.0.0.1)1> # Test: one_client start server node: Ok server startup: Ok start client node client_50150: Ok client startup client_50150: Ok client_50150@127.0.0.1 connects to server as user_72305: Ok client_50150@127.0.0.1 joins #channel_44359: Ok start client node client_91566: Ok client startup client_91566: Ok client_91566@127.0.0.1 connects to server as user_31133: Ok client_91566@127.0.0.1 joins #channel_44359: Ok client_50150@127.0.0.1 sends message on #channel_44359: Ok channel matches: Ok message matches: Ok client_91566@127.0.0.1 leaves #channel_44359: Ok client_50150@127.0.0.1 sends message on #channel_44359: Ok no more messages: Ok Test passed.
If you have added extra modules, make sure that they are also compiled (e.g. by adding them to the makefile).
make
If your system doesn't have the make
command, you can run the test suite like so:
$ killall beam.smp $ erl -name "testsuite@127.0.0.1" -eval "cover:compile_directory(), eunit:test(test_remote), halt()"
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.