Anonymous servers, clients and messages in Erlang – Københavns Universitet

Anonymous servers, clients and messages in Erlang

Talk by Guy Wiener from Ben-Gurion University, Israel 

Abstract:

Generally speaking, servers and clients in Erlang are implemented named procedures in named modules. Similarly, processes communicate via messages that have a statically-known structure, and specifically, with static tags, that serve as the "names" of the messages. This exposes and fixes a great deal of information about an Erlang application: The names of the modules, the name of the entry-point procedures within the module, the "names" of the messages between the server and the client, etc. This work explores how to gain anonymity through the use of anonymous higher-order procedures.

To spawn a process on a node, one must either to use a module name and a function, or to pass an anonymous procedure.  In order to use a function from a module, the module file must be available on the remote node.

For a server to receive arbitrarily-many messages, the spawned function must be recursive. Recursive functions are typically implemented in Erlang via a name that is global to an Erlang module. Running such a server requires that the client be aware of the name of the module, the name of a function that serves as an entry point in the module, and the arguments to that procedure.

Functional programming languages, especially of the dynamically-typed variety (such as LISP, Scheme, Erlang), permit recursion to be replaced with self-application, which means closures that are applied to themselves. This is a classical technique that is based on fixed-point theory in the lambda-calculus, which is the theoretical foundation of all functional programming languages. It is a common exercise in functional programming courses to implement recursive functions using self-application instead of recursion, though in most languages this amoun ts to a theoretical exercise. In Erlang, however, replacing recursion with self-application can add flexibility, anonymity and security. Specifically, we demonstrate how to

  • spawn a fully-functional server without any particular module located on the server node
  • run servers on any node, without requiring shared modules or access to the file system
  • have client-server groups that can communicate via messages that have randomly-selected names that change after each message. This encapsulates communication, and makes it more secure, in a way similar to how processes in the pi-calculus can communicate via privately-named channels.

Host: Andrzej Filinski (andrzej@diku.dk). All are welcome