2 The PLAN Implementation
A PLAN node consists of a number of distinct components: the basis,
the interpreter, the network and link layer interfaces,
and the services.
The basis forms the core information about PLAN needed by both the active
router and host applications. This includes definitions of PLAN packets,
values and types (all in file basis/basis.ml), and how these entities
are marshalled to be sent across the wire (file basis/marshalling.ml).
The interpreter is the part of the active router that actually evaluates the
PLAN programs that it receives. Each PLAN program is compiled to an AST
(defined in basis/basis.ml) which is evaluated at the evaluation
destination. The interpreter is implemented in the file interpreter/eval.ml, which makes direct use of the basis and network
functions. Core services are defined in the file interpreter/svc_impl.ml.
The network interface defines the concept of the network available to the
PLAN interpreter (implemented in file planet/net.ml). It is this
interface that is used by the interpreter to transmit packets during the
evaluation of the OnRemote and OnNeighbor primitives, as well to
transmit values to a host application via the use of PLAN ports (with help
from planet/ports.ml).
To properly send a packet, the network interface makes use of address
resolution, defined in file arp/arp.ml. This implements a PLAN
version of the standard IP address resolution protocol (ARP).
The address resolution interface makes use of different underlying linklayer
technologies, all of which are assumed to have broadcast semantics. The
entry point to each is the file net/linklayer.ml, which provides a
uniform interface on top of each of the different link layers. Each link
layer implements the signature in file net/linklayer_impl.ml; there
are currently two link layers: Ethernet and IP (in net/ethernet_impl_file.ml and net/ip_impl_file.ml, respectively).
Also defined here are the concept of a network layer address (in net/activehost.ml), and DNS resolution (net/hostfile.ml).
Security services are defined in the security directory. Both
services for authentication and authorization are provided. A thorough
explanation of these services and some of their implementation details are
presented in [5].
The services define the bulk of the functionality of the active router, and
are amply described in the PLAN Programmer's Guide [4]. Each
service package is implemented in its own directory.
Finally, when the plan daemon is built with the active loader, it uses code
in the loader directory. Files which are common to both the loader
and the standard pland are found in the common directory. In order to
provide certain security guarantees, the loader makes use of module
thinning, meaning that the interface seen by an externally loaded module
presented by the running program may be different than the interface
available to compiled modules. The specification of alternate
interfaces (and sometimes implementations) is automated by the builder
program, whose source is in the builder directory. It takes the builder/safeloader.build file as its default specification file (as
indicated in the Makefile).