User Tools

Site Tools


cs415pdc:lab10

Lab 10: Client/Server Distributed Computing

In this lab we'll test an Erlang distributed program in multiple settings: as a single process in the Erlang environment, as two separate processes in different nodes on the same machine, and as processes running on different machines.

Step 1.

The program in question is a name server. Essentially this is a server-based version of the Map or Dictionary ADT studied in CSci 257, and is often implemented using a hash table. As such, it can be used to store any sort of name, value pair and later do lookups for the values associated with each name, where name is used as a key. Grab the file from name server.

It's dead easy to use: call kvs:store with key and a value to associate the key with the value, and kvs:lookup with a key to retrieve a previously stored value. Well, you do need to call kvs:start to get set up. For example, start the Erlang shell erl in the directory containing kvs.erl and try this; you should get the responses shown:

$ erl
>c(kvs).
{ok,kvs}
>kvs:start().
true
>kvs:store(cs326, "Erlang").
true
>kvs:store(cs320, "pseudocode").
true
>kvs:store(cs157, "Java").
true
>kvs:lookup(cs326).
{ok, "Erlang"}
>kvs:lookup(cs257).
undefined

Type <Ctrl-C> twice to exit.

Step 2.

Once that works, move on to working with multiple processes using Erlang nodes. To communicate between nodes, whether on the same computer or over a network, two Erlang nodes must be named using the -sname option when invoking the Erlang shell. For example, to start a new node named frank you would issue this command:

erl -sname frank

The prompt changes to show the node name; if I had started this on the host eneva, the prompt is now frank@eneva. In the following, you'll need to use the node and hostname of your computer in place of mine.

  • Restart erl but this time give your node a name (must be lower-case). The following assumes the name is frank but you can use any name.
  • Open a second Terminal window and start another erl shell with a different node name
  • In the first shell, start the name server as before; now you have a server running
  • Try the examples above in the server shell to make sure things still work
  • In the second shell, issue this command: rpc:call(frank@eneva, kvs,store, [weather, cooold]).
  • Now issue this command: rpc:call(frank@eneva,kvs,lookup,[weather]).
  • Switch back to the first shell and try kvs:lookup(weather). You should get the same result as the previous step.

What you've done is create two processes running in two separate Erlang nodes that are communicating by passing messages: distributed computing using the client/server model. Note that your second node does not have a local copy of the kvs store; it must remotely call the server's API functions to store or lookup values, using the rpc (remote procedure call) mechanism provided by Erlang.

Step 3.

It only takes a few steps to extend this to multiple networked computers: two Erlang instances running on different computers can communicate by following these steps:

1) Again, each instance must be uniquely named using the -sname option and 2) be running on systems with the same value stored in the file ~/.erlang.cookie. For most of us, the system already generated a .erlang.cookie file, but they are all different and need to be the same for client/server to work. After some experimentation, we discovered two ways to make these the same:

  • the easy way: specify the value on the command line when you start erl, using the -setcookie option. For example, to start an Erlang node named frank that communicates using the cookie this_is_very_secret, start Erlang this way:

erl -sname frank -setcookie this_is_very_secret

  • the almost as easy way: delete the file ~/.erlang.cookie, then recreate it using the method shown in the tutorial, section 3.4. If you do this, the -setcookie option is not needed, but you and your partner must agree on the same cookie value.

(This cookie stuff is a simple, low-cost protection mechanism to keep arbitrary Erlang processes from accidentally intruding on your private server. It wouldn't be used for a public system like DNS or web servers.)

Restart your Erlang shell using the same node name as before. Work with the person across from you (exchange node and host names) and do:

  • Decide who will be the client and who will be the server.
  • The server restarts Erlang using the method above. Store two or three initial key/value pairs; the keys can be CS courses like in Step 1, but the value can be any string, such as “really hard”, “boring”, or “too much fun”.
  • The client restarts Erlang using the method above.
  • Server tells client the keys, client uses rpc:call as before to look them up.
  • Now client adds new [key, value] pairs using store with rpc:call as before. Make sure both client and server get the right answers when looking these up.
  • Call me to check you off by looking at what you and your partner have done.

Step 4 - if there's time

I have a kvs name server running on the host farheen with Erlang node named bob. The keys are atoms representing every computer science course in the catalog, like above. My cookie value is this_is_very_secret.

Use the rpc:call mechanism to look up at least three different keys.

Now use the rpc:call mechanism to store a new key/value pairs on my server. Personalize them so I know who did what! Use your initials (all 3 if you have 3, all lower case) and a three digit number as the key. The values can be any string, but remember this is a family-friendly lab! Now check that you can look them up.

Record the results of trying to store and trying to look them up again, even if it doesn't work.

  NOTE: don't get too frustrated if this doesn't work easily. I haven't tested it very deeply! If you have problems, let me know. No matter the outcome, record your results.
cs415pdc/lab10.txt · Last modified: 2017/12/12 13:14 by scarl