<TeXmacs|1.99.2>
<style|generic>
<\body>
<doc-data|<doc-title|The NARP protocol specification >|<doc-subtitle|A
Generic Recursive Communication Protocol for Networked Applications>>
In this document we explain the purpose and provide a draft specification
for the NARP protocol, a general-purpose networking protocol destined to be
used in many layers of a new operating system and networking system.
<section|Introduction>
We begin by remarking that a basic operation in all computer operation
processes consists in naming objects and providing acces to these named
objects. Here are a few examples of naming in real use cases:
<\itemize>
<item>Naming of files on a local or distant file system
<item>Naming of devices in the <verbatim|/dev> virtual filesystem on Unix
machines
<item>Naming of networked machines (with IP adresses and DNS records)
<item>Naming of internet ressources over protocols such as HTTP, IMAP,
IRC, specfic web services, ...
</itemize>
We propose here a novel architecture with the purpose of unifying all the
naming happening at all levels of the system, with two base concepts :
<em|objects> and <em|service>.
<\itemize>
<item><em|objects> are ressources that may implement different semantics
: bidirectionnal communication (such as sockets) ; unidirectionnal
communication (FIFO-like) ; file semantics ; etc.
<item><em|services> are a way of naming objects, querying the interfaces
they implement, and multiplexing communications with them
</itemize>
We suggest that a NARP service may be provided on any bidirectionnal
channel of communication supporting the (reliable) sending and recieving of
messages. In addition, NARP objects may implement such a send/recieve
interface ; therefore a NARP service can be channeled into an object. Such
a construction of using a NARP object to access a NARP service is a
fundamental operation that we call <em|recursive multiplexing>, or just
<em|multiplexing>.
The NARP protocol is a client/server protocol meant to include a variety of
different operations that may or may not be implemented by a specific NARP
server.
<section|High-level overview>
<subsection|The basic operations on services and objects>
A NARP service is basically any object that implements the following
operations:
<\itemize>
<item><em|query> : get information on a ressource identified by name
<item><em|list> : know the names of ressources presented by the service
(possibly in a specific sub-path)
<item><em|attach> : get an object interface for accessing a ressource,
identified by name
</itemize>
A NARP object is basically any object that implements the following
operations :
<\itemize>
<item><em|send> : send a message (an arbitrary byte string) to the object
<item><em|recieve> : recieve a message from the object (this may be done
asynchronously with handler functions)
<item><em|detach> : delete object connection
</itemize>
<subsection|The basics of the NARP protocol>
Given any interface with send/recieve capabilities considered as an
assymetric (client/server) configuration, the following client messages
consitute the basics of the NARP protocol for providing a NARP service on
the interface:
<\itemize>
<item><verbatim|hello> : initialize a connection, check version
information, ...
<item><verbatim|authenticate> and appropriate response messages : use
credentials (user/password or access token) to gain acces to some
ressources provided by the server (the protocol is thus statefull)
<item><verbatim|walk>, <verbatim|list> and appropriate response messages
: get information about the available ressources
<item><verbatim|attach> and appropriate response messages : give an
identifier (a descriptor) to a ressource in order to communicate with it
<item><verbatim|send> and appropriate response messages : send a message
to an attached ressource, identified by its descriptor
<item><verbatim|detach> : close a descriptor and detach from a ressource
<item><verbatim|create>, <verbatim|delete>, <verbatim|rename>,
<verbatim|link> : requests the creation or modification of a ressource in
the namespace
</itemize>
The server may also at any moment send a message, including:
<\itemize>
<item>a response to a query
<item><verbatim|recieve> : a notification of a message sent from the
object to the client
<item><verbatim|detached> : the connection to the object has been
terminated by the object server
</itemize>
<subsection|Recursion>
If an object is a NARP server, the messages sent to it and recieved from it
are messages of the NARP protocol. Otherwise, they are arbitrary.
<subsection|Reverse object><label|rev-sock>
Some NARP servers may support reverse object serving: the client creates an
object on the server and handles all the requests arriving to this object
(therefore the initial NARP server only serves as a relay between the new
server and its clients<\footnote>
Research is to be done on shortcutting mechanisms in specific situations
where too many levels of recursion cause a performance issue.
</footnote>). A client wishing to act as a reverse object server may use
the following commands:
<\itemize>
<item><verbatim|serve> : listen for attach requests on a servable (empty)
object created in the server namespace (if authorized)
<item><verbatim|accept> and <verbatim|reject> : accept (or reject) an
attach request to the object
<item><verbatim|detach> : close connection between object and client
(this is the same detach message as in standard communications)
<item><verbatim|unserve> : stop serving for the object. Attached clients
continue to be attached.
</itemize>
The server may in turn send the following messages concerning the server
object:
<\itemize>
<item><verbatim|attach_request> : a client is willing to attach to the
object. A descriptor is already associated to the connection to be
established, but the server may reject it.
</itemize>
Once a client is attached to the object, a classical send/recieved
interface is provided.
Typically, the protocol exchanged over the object is NARP protocol,
therefore enabling the reverse server to provide its own namespace and
other functionnality.
<subsection|Specific object types and associated messages>
<subsubsection|Objects are sockets>
Sockets are the basis of the NARP protocol : attaching to an objects opens
a socket connection to the process serving the object, and when the
connection is accepted, basic send/recieve functionnality is provided. See
also the reverse object protocol described in section <reference|rev-sock>.
<subsubsection|File objects>
Small files may implement the following interface:
<\itemize>
<item><verbatim|put> : erase the whole file and put the transmitted
content
<item><verbatim|get> : retrieve the whole file content
</itemize>
Big files may implement the following interface:
<\itemize>
<item><verbatim|write> : write a portion of the file at a given offset
<item><verbatim|read> : read a portion of the file at a given offset
</itemize>
<subsubsection|User IO (terminals...)>
Virtual terminals can be seen as objects implementing a simple send/recieve
semantic, where the data transmitted is unstructured (or structured given a
specific terminal data structure). More specific interfaces can be defined
for advanced terminals and GUIs.
<subsubsection|Specific applications>
Specific applications may define custom messages. Examples include:
<\itemize>
<item>e-mail
<item>instant messaging
<item>collaborative editing of text-based documents
</itemize>
and many other applications yet to be invented.
<subsection|Big messages>
The message size in the NARP protocol is limited to 64kb, and recommended
not to exceed 4kb+header (4kb is the size of a memory page on many
machines). Therefore a possibility would be for the NARP protocol to
include a way to transmit big messages by fragmenting them into small
messages. Optionnal error correction may be included. This can be useful
for example when using <verbatim|put> or <verbatim|get> on large files, or
<verbatim|read>s and <verbatim|write>s of big file portions. The recieving
of a large fragmented message may have a specific implementation allowing
the reciever to work with the partial data as soon as it starts arriving
and not having to wait for the whole message to be transmitted and
buffered. Research is yet to be done on this specific subject.
<subsection|Permissions>
For each attached client the server may keep track of associated
permissions, and accept or reject requests according to those permissions.
The client may use an authentication command to gain supplementary
privileges on the server's ressources. The client may request a token to
delegate it's privileges on a given object to another client. Advanced
right management functionnalities are to be discussed.
<subsection|Reliability concerns>
The NARP protocol relies on the fact that when transmitting a message, the
other end will recieve it. It is nevertheless recommended that NARP
implementations support the repeating of messages if an expected
acknowlegment has not arrived after a given delay.
<subsection|Example NARP servers>
<subsubsection|Virtual NARP server (i.e. NARP router)>
This server implements a namespace where any client may create an empty
object and serve connections to it. Additionnaly, the server may implement
the possibility to create virtual files, virtual directories, FIFO queues,
etc.
This server may be connected to other virtual NARP servers in order to
provide a global namespace accessible to all. Each virtual NARP server acts
as an endpoint into the network and may have functionnality for routing the
communications to objects to the clients that serve them.
<subsubsection|NARP file server>
This server simply implements access to a filesystem : listed ressources
are the same as the files present in a served directory, each of these
implements the filing protocol (served directly by the file server), and
the creation of files/directories may also be implemented.
<subsubsection|NARP terminal/GUI server>
Clients may create objects on the server ; each of these objects correspond
to a GUI window. Two interfaces may be implemented : text IO (terminal) and
graphical interaction. Advanced terminal interaction features may be
implemented at the protocol level, such as auto-completion of commands or
of text being edited...
Suggestion for a third kind of window : the data sent by the client
corresponds to a description of the scene in a given markup language and
the server does the rendering. The client can also subscribed to events
such as clicking on an item or entering text. This possibility is to be
explored.
<subsubsection|NARP e-mail and newsgroup server>
Several features to be implemented:
<\itemize>
<item>user login and private user mailboxes
<item>bridge to standard SMTP/POP3/IMAP services
<item>private threads of conversation with access rights (the users don't
each have a copy of the thread)
<item>synchronization between many servers
<item>public discussion forums
</itemize>
<subsubsection|NARP chat server>
<\itemize>
<item>user login and status notification
<item>online and offline private messaging
<item>public chat rooms, chat room logging independently of user being
online or offline
<item>bridging and synchronization between many servers
</itemize>
<subsubsection|NARP applicative server>
TODO...
<section|Specifics of the NARP protocol>
<subsection|Protocol description format>
A protocol message is given in the following form:
<block*|<tformat|<table|<row|<cell|element type>|<cell|element
type>|<cell|...>|<cell|element type>>|<row|<cell|element
description>|<cell|element description>|<cell|...>|<cell|element
description>>>>>
The following element types apply:
<\itemize>
<item><math|int16>, <math|int32>, <math|int64> : 16-bit, 32-bit or 64-bit
little-endian integers
<item><math|str> : a string, prefixed by a 16-bit length header
<item><math|arr<around*|(|T|)>> : an array of <math|T>'s (where <math|T>
is another element type), prefixed by a 16-bit length header
<item>* (for the last element) : consider all the rest of the message as
a byte string
</itemize>
<subsection|Basic message format>
The basic format of a message is :
<block*|<tformat|<table|<row|<cell|int16>|<cell|int16>|<cell|*>>|<row|<cell|message
size>|<cell|message type>|<cell|payload>>>>>
We will abbreviate by ``header'' the first 32 bits (4 bytes) of the
message. The list of message types is given in section
<reference|type-nums>.
Messages for communication with an attached ressource will have the
following format :
<block*|<tformat|<table|<row|<cell|int16>|<cell|int16>|<cell|int32>|<cell|*>>|<row|<cell|message
size>|<cell|message type>|<cell|ressource descriptor
(handle)>|<cell|payload>>>>>
Many client messages awating a response will have a message ID included ;
this message ID is an arbitrary number generated by the client and used by
the server when giving its response. The header then looks like this:
<block*|<tformat|<table|<row|<cell|int16>|<cell|int16>|<cell|int32>|<cell|*>>|<row|<cell|message
size>|<cell|message type>|<cell|message ID>|<cell|payload>>>>>
<subsection|Message list for core NARP protocol>
Client messages have an up arrow (<math|\<uparrow\>>) next to their name,
while server messages have a down arrow <math|<around*|(|\<downarrow\>|)>>.
The core NARP protocol is meant for small size and rapidity (so that many
layers can be encapsulated with minimal overhead), therefore no
acknowlegment is to be sent for recursive send/recieve messages. Other
messages usually imply some kind of action or getting of information,
therefore an acknowlegment or an error is usually sent as a response.
<paragraph|Hello<math|\<uparrow\>\<downarrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|arr(int32)>>|<row|<cell|header>|<cell|version>|<cell|list
of needed/provided interfaces>>>>> \ \
When a NARP connection is established, the client is always the first to
send a <strong|Hello> message. The object may then respond either with a
<strong|Hello> message indicating that the requested interfaces can be
provided, or with an <strong|Error> message. The two common error causes
are <em|interface not implemented> and <em|incompatible versions>.
For interface numbers : see table in section <reference|interface-nums>.
</indent>
<paragraph|Error<math|\<downarrow\>>>
<\indent>
Generic error response message for any operation.
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|error ID>|<cell|error string>>>>>
Common error IDs are specified in section <reference|error-nums>.
</indent>
<paragraph|Ack<math|\<downarrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>>|<row|<cell|header>|<cell|request
ID>>>>>
Generic acknowlegment message for commands that require it. An acknowlege
implies the command has been sucessfully executed (otherwise an error
message is sent).
</indent>
<paragraph|Stat<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|filename>>>>>
The request ID is an ID decided by the client so that it can identify the
answer.
</indent>
<paragraph|StatR<math|\<downarrow\>>>Response to the <strong|Stat> message.
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|arr(int32)>>|<row|<cell|header>|<cell|request
ID>|<cell|implemented interface>>>>>
Common interface numbers are to be found in section
<math|<reference|interface-nums>>.
If a <strong|Stat> query on an object gives a certain list of interfaces,
then when connecting to the object at least all these interfaces must be
included in the server's <strong|Hello> message as supported interfaces.
Note that some interface numbers correspond to actions that can be done
on the object from the connection where the object exists (e.g. :
symbolic link, directory), and others correspond to actions that can be
performed after attaching to the object (e.g. file, terminal, ...)
</indent>
<paragraph|List<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|first entry number>|<cell|number of entries
requested>|<cell|base path string>>>>>
</indent>
<paragraph|ListR<math|\<downarrow\>>>Response to the <strong|List> message.
<\indent>
One message is passed for each entry in the requested range:
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|entry number>|<cell|entry name>>>>>
After the directory has finished being enumerated, a supplementary entry
is given with entry number the last valid entry number plus one and an
empty entry name. This supplementary entry is only given if its (ficious)
entry number is included in the range requested by the client.
</indent>
Possible extension : combine List and Stat so that when the answer to List
is given, information is also given on the object's implemented interfaces.
<paragraph|Attach<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|filename>>>>>
</indent>
<paragraph|Attached<math|\<downarrow\>>>Response to the <strong|Attach>
command.
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|request
ID>|<cell|handle>>>>>
(the handle, ie the ressource descriptor, is attributed by the server)
</indent>
<paragraph|Send<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|*>>|<row|<cell|header>|<cell|handle>|<cell|payload>>>>>
This message does not expect a response.
</indent>
<paragraph|Recieve<math|\<downarrow\>>>
<\indent>
Spontaneous server message indicating some data is sent by an attached
ressource. This message does not expect a response.
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|*>>|<row|<cell|header>|<cell|handle>|<cell|payload>>>>>
</indent>
<paragraph|Detach<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>>|<row|<cell|header>|<cell|handle>>>>>
This message does not expect a response.
</indent>
<paragraph|Detached<math|\<downarrow\>>>
<\indent>
Spontaneous server message indicating the object has been detached.
<block*|<tformat|<table|<row|<cell|>|<cell|int32>>|<row|<cell|header>|<cell|handle>>>>>
</indent>
<paragraph|<strong|Create<math|\<uparrow\>>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|arr(int32)>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|needed interfaces>|<cell|path>>>>>
A create request is accompanied with a list of needed interfaces that
direct the server into creating the corresponding type of object (e.g. an
empty object to be served, a directory, a file, ...)
</indent>
<paragraph|Created<math|\<downarrow\>>>Response to the <strong|Create>
command.
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|arr(int32)>>|<row|<cell|header>|<cell|request
ID>|<cell|implemented interfaces>>>>>
Signals that the object has been created, and has corresponding
interfaces associated to it.
</indent>
<paragraph|Delete<math|\<uparrow\>><verbatim|>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|path>>>>>
This message expects a standard <strong|Ack> response message.
</indent>
<paragraph|Link<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|destination path>|<cell|link path>>>>>
This message expects a standard <strong|Ack> response message.
Semantics of the link object:
<\itemize>
<item>attaching or serving on this objects corresponds to resolving the
linked path and attaching/serving on the linked object
<item>stating the link will stat the linked object and add as an
implemented interface the ``this is a symlink'' information
<item>directory listings follow links
<item>deleting the link will not delete the original file but only the
link
</itemize>
</indent>
<paragraph|ReadLink<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|path>>>>>
</indent>
<paragraph|ReadLinkR<math|\<downarrow\>>>Response to the <strong|ReadLink>
message.
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|link description>>>>>
This will only return the first level of linking, ie the link data
directly associated to the link object.
</indent>
<paragraph|Rename<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>|<cell|str>>|<row|<cell|header>|<cell|request
ID>|<cell|original path>|<cell|new path>>>>>
This message expects a standard <strong|Ack> response message.
</indent>
<paragraph|Serve<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>|<cell|array(int32)>>|<row|<cell|header>|<cell|request
ID>|<cell|path>|<cell|announced interfaces>>>>>
This message is a request for the client to be a reverse server to an
object. The response message to this message is an <strong|Attached>
message. The handle attributed to the served object is known as the
<em|server handle> and is used in the <strong|Incoming> and
<strong|Detach> messages.
To stop serving an object, the client simply sends a <strong|Detach>
command on the server handle. The semantics is that all connections that
have been openned through the reverse-served object are preserved when
the object stops being served, and an individual <strong|Detach> message
must be sent to all of them if we want to close them.
The <em|announced interfaces> serves to answer <strong|Stat> messages on
the object while we are serving it.
</indent>
<paragraph|Incoming<math|\<downarrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|server
handle>|<cell|client hande>>>>>
This message is sent by the server when another client wishes to attach
to an object reverse-served by this client. The server handle is the one
given as a response to the <strong|Serve> message. The client handle is a
handle associated to the connection. The reverse server may reject the
connection by issuing a <strong|Detach> command on the client handle, or
may accept it using the <strong|Accept> message given below.
</indent>
<paragraph|Accept<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>>|<row|<cell|header>|<cell|client
handle>>>>>
Once a connection has been accepted, the reverse server may at any moment
close it by sending a <strong|Detach> command on the corresponding client
handle.
</indent>
<paragraph|Unbox<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|request
ID>|<cell|outer handle>|<cell|inner handle>>>>>
Consider the handle <em|outer handle> as a NARP protocol service, and
associate a handle in the outer layer to the handle of the inner layer
with handle <em|inner handle>.
Example : in connection A we have a connection open on handle 5 which
contains NARP data that we will call B, and in connection B we have
another connection open on handle 7. Issuing a Unbox(id, 5, 7) request on
A will lead to the server creating a handle (say 12) where sending
corresponds to sending a message to handle 7 on connection B, and such
that all messages recieved on handle 5 (ie on connection B) are filtered
and messages whose destination is handle 7 on connection B are removed
from the stream and issued on handle 12 of connection A instead.
The answer to such a request is an <strong|Attached> response giving a
handle to the unboxed connection.
Systematically unboxing open connections may lead in some cases to the
network infrastructure being able to do simplifications in the
interconnections. In other cases it may result to useless overhead on the
server side : in such a case the server may refuse an unbox request.
</indent>
<paragraph|Plug<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|request
ID>|<cell|handle A>|<cell|handle B>>>>>
Ask the server to redirect all messages recieved on handle A to handle B
and all mesages recieved on handle B to handle A. The messages recieved
on either handle are not sent to the client anymore.
The answer messages are standard <strong|Ack>/<strong|Error> messages.
</indent>
<paragraph|Unplug<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|int32>>|<row|<cell|header>|<cell|request
ID>|<cell|handle A>|<cell|handle B>>>>>
Undoes a plugging.
</indent>
<subsection|Big message protocol>
To be defined. Is it really usefull? What role exactly does it have? Can it
implement repetition in the case where the message hasn't been acknowledge?
...
<subsection|Authentification and rights managment commands>
<paragraph|Authenticate<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|int32>|<cell|*>>|<row|<cell|header>|<cell|message
ID>|<cell|authentification method>|<cell|authentification data>>>>>
Used to gain access using credentials (user/password, token, ...).
Response messages are standard <strong|Ack> on success or <strong|Error>
on failure. Autentification methods include :
<\itemize>
<item>1 : user + password
<item>2 : token
</itemize>
</indent>
<paragraph|NewToken<math|\<uparrow\>>>
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|message
ID>|<cell|path>>>>>
Requests the server to create an authentication token for accessing a
given object with the privileges of the connected client. Once the token
has been returned, it may be transmitted to another client so that that
client will use it to gain same access to the object.
</indent>
<paragraph|NewTokenR<math|\<downarrow\>>>Response to the <strong|NewToken>
message.
<\indent>
<block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|message
ID>|<cell|token>>>>>
</indent>
TODO : request account creation, manage user groups and ACLs, ...
<subsection|TODO>
<\itemize>
<item>file protocol
\;
<item>system protocols (see section on OS design using NARP)
<item>UI protocols (terminal, GUI)
<item>communication protocols (mail, IM)
</itemize>
<subsection|Table of IDs>
The tables presented in this section give the number associated to the
message types. These tables are the reference on the subject ; any
information found somewhere else is wrong if it is not the same as found
here. This is for protocol version 1.
<subsubsection|Message types><label|type-nums>
<paragraph|Base protocol>
<\indent>
<block|<tformat|<cwith|1|-1|4|4|cell-tborder|0px>|<cwith|1|-1|4|4|cell-bborder|0px>|<table|<row|<cell|message>|<cell|<math|\<uparrow\>>
id>|<cell|<math|\<downarrow\>> id>|<cell|>|<cell|message>|<cell|<math|\<uparrow\>>
id>|<cell|<math|\<downarrow\>> id>>|<row|<cell|<strong|Hello>>|<cell|0>|<cell|10000>|<cell|>|<cell|<strong|Stat>
/ <strong|StatR>>|<cell|10>|<cell|10010>>|<row|<cell|<strong|Error>>|<cell|>|<cell|10001>|<cell|>|<cell|<strong|List>
/ <strong|ListR>>|<cell|11>|<cell|10011>>|<row|<cell|<strong|Ack>>|<cell|>|<cell|10002>|<cell|>|<cell|<strong|Create>
/ <strong|Created>>|<cell|12>|<cell|10012>>|<row|<cell|>|<cell|>|<cell|>|<cell|>|<cell|<strong|Delete>>|<cell|13>|<cell|>>|<row|<cell|<strong|Attach>
/ <strong|Attached>>|<cell|5>|<cell|10005>|<cell|>|<cell|<strong|Rename>>|<cell|14>|<cell|>>|<row|<cell|<strong|Send>
/ <strong|Recieve>>|<cell|6>|<cell|10006>|<cell|>|<cell|<strong|Link>>|<cell|15>|<cell|>>|<row|<cell|<strong|Detach>
/ <strong|Detached>>|<cell|7>|<cell|10007>|<cell|>|<cell|<strong|ReadLink>
/ <strong|ReadLinkR>>|<cell|16>|<cell|10016>>|<row|<cell|<strong|Serve>>|<cell|8>|<cell|>|<cell|>|<cell|>|<cell|>|<cell|>>|<row|<cell|<strong|Incoming>>|<cell|>|<cell|10008>|<cell|>|<cell|<strong|Unbox>>|<cell|20>|<cell|>>|<row|<cell|<strong|Accept>>|<cell|9>|<cell|>|<cell|>|<cell|<strong|Plug>>|<cell|21>|<cell|>>|<row|<cell|>|<cell|>|<cell|>|<cell|>|<cell|<strong|Unplug>>|<cell|22>|<cell|>>>>>
</indent>
<paragraph|Authentication & privileges>
<\indent>
<block|<tformat|<table|<row|<cell|message>|<cell|<math|\<uparrow\>>
id>|<cell|<math|\<downarrow\>> id>>|<row|<cell|<strong|Authenticate>>|<cell|30>|<cell|>>|<row|<cell|<strong|NewToken>
/ <strong|NewTokenR>>|<cell|31>|<cell|10031>>>>>
</indent>
<subsubsection|Error messages><label|error-nums>
<\indent>
<block|<tformat|<table|<row|<cell|id>|<cell|cause>>|<row|<cell|1>|<cell|Incompatible
versions>>|<row|<cell|2>|<cell|Command/interface not
implemented>>|<row|<cell|3>|<cell|Invalid request (e.g. : out of
bounds)>>|<row|<cell|4>|<cell|Invalid handle>>|<row|<cell|5>|<cell|Attach
request rejected>>|<row|<cell|6>|<cell|Action impossible because object
is in use (cannot delete, ...)>>|<row|<cell|7>|<cell|No such object
(invalid path)>>|<row|<cell|8>|<cell|Could not resolve
link>>|<row|<cell|9>|<cell|Incorrect credentials>>|<row|<cell|10>|<cell|Unauthorized>>>>>
</indent>
<subsubsection|Object interfaces<label|interface-nums>>
<\indent>
<block|<tformat|<table|<row|<cell|id>|<cell|name>|<cell|must implement
messages>>|<row|<cell|0>|<cell|servable>|<cell|<strong|Serve>,
<strong|Accept>, <strong|Incoming>>>|<row|<cell|1>|<cell|enumerable>|<cell|<strong|List>,
<strong|ListR>>>|<row|<cell|2>|<cell|is symlink>|<cell|<strong|ReadLink>,
<strong|ReadLinkR>>>|<row|<cell|>|<cell|>|<cell|>>|<row|<cell|9>|<cell|non-NARP
inside>|<cell|once attached, inside data is
arbitrary>>|<row|<cell|10>|<cell|NARP service>|<cell|once attached,
inside data is a NARP service (ie has objects,
...)>>|<row|<cell|11>|<cell|NARP unbox>|<cell|once attached,
<strong|Unbox> command supported>>|<row|<cell|12>|<cell|NARP
plug>|<cell|once attached, <strong|Plug> and <strong|Unplug> commands
supported>>|<row|<cell|>|<cell|>|<cell|>>|<row|<cell|20>|<cell|file>|<cell|once
attached, file semantics>>|<row|<cell|21>|<cell|terminal>|<cell|once
attached, terminal semantics>>|<row|<cell|22>|<cell|graphics
window>|<cell|once attached, GUI semantics>>>>> \
</indent>
<paragraph|Servable>This interface specifies that the object is currently
an empty object waiting for someone to issue a <strong|Serve> command on
it, providing it with an implementation of some interfaces.
<paragraph|non-NARP inside>This interfaces indicates that once attached to
the object, the messages sent/recieved to it are not supposed to be NARP
format but any arbitrary format. If this interface is not specified, then
it is expected that the messages transmitted will follow the general NARP
protocol (message format, standard hello/ack/error messages).
<paragraph|NARP service>This interface indicates that once attached to the
object, one can have access to a new NARP namespace where at least the
following operations are supported : <strong|Stat>, <strong|Attach>,
<strong|Send>, <strong|Recieve>, <strong|Detach>. Additionnal messages may
or may not be supported.
<section|Architecture of a NARP implementation in OCaml or Haskell>
An asynchronous implementation can be easily programmed in functionnal
languages such as OCaml or Haskell, using closures as continuations for
<em|what to do when a (response) message arrives>.
TODO
<section|Using NARP to design an Operating System>
When designing the NARP protocol, we had in mind that it would be possible
to use it in a new operating system design at many levels : access to
devices, process management, memory management, filesystems, IPC, GUI, ...
Kernel helpers could be developped so that a part of the NARP multiplexing
and demultiplexing takes place in kernel land, before messages are passed
to userspace. For instance, this would allow the simplification of useless
mux-demux chains taking place on the same machine. The mux-demux helper can
be implemented via the <strong|Unbox> protocol message, handled at the
level of the root stream of NARP communication with the kernel. Another
possible helper would be to map a virtual memory region to a NARP ressource
implementing a standard filing protocol, much like memory mapped files in
standard OSes (only this would work with arbitrary ressources).
In this section we will develop on a concrete proposal for a NARP-based
operating system.
<subsection|Architecture of the OS>
The basic primitive of the system being message-passing, the system looks a
lot like a micro-kernel. Only the message format has a complex semantic and
the communication layer is not really ``simple''. Furthermore, the system
has device drivers, file system and networking running as kernel-mode
processes, making the kernel more monolithic (but still having a
micro-kernel spirit). It should be easy to make any user mode process run
as a kernel mode process instead, for the sake of performance (eg :
graphical server & compositor).
The kernel land is divided in three major parts, with strict dependency
order:
<\itemize>
<item>Level 0 : System ressource managment : physical memory, virtual
memory, hardware interaction (IRQ, v86), debug output
<item>Level 1 : Scheduler, IPC & NARP core server : builds on top of
level 0, adds support for processes and communication between them
restricted to NARP protocol data.
<item>Level 2 : System processes : hardware, file systems, network, ...
(may access level 0 and level 1 features)
</itemize>
User processes are restricted to syscalls that call level 1 primitives.
Here are a few basic principles for the design of these three levels :
<\itemize>
<item>Level 2 processes may not communicate directly nor share memory :
they must go through level 0 and level 1 primitives to achieve such a
goal. Each level 2 process has a separate heap, which is completely freed
when the process dies. Level 2 processes do not use separate virtual
memory spaces : since the kernel memory space is mapped in all page
directories, a level 2 process may run with any page directory.
Benefits : critical system parts are restricted to level 0 and level 1.
Level 2 components may leak or crash with less consequences.
<item>All synchronization & locking is handle by level 1, except for
level 0 that must implement its own locking devices (since it cannot rely
on level 1).
Benefits : no complex synchronization in most of the code (which is
either level 2 or userland), only simple message passing and waiting for
stuff to happen
<item>No concept of ``threads'' : system processes are actually kernel
threads, but we call them processes since they use separate parts of
memory. Userlands processes cannot spawn multiple threads of execution
either : they must fork and communicate through NARP if they want to do
so (eg: launching an expensive communication in the background).
(since fork is a complicated system call, and features such as
copy-on-write depend on processes using different paging directories, the
fork system call is accessible only to userland processes : level 2
processes may not fork, but only create new processes)
<item>Level 1 also has a memory heap ; it is used with
<verbatim|core_malloc/core_free>. Level 2 proceses use standard
<verbatim|malloc/free>, which are modified to act on the heap of the
current process.
<item>Each process (system or user) has a <em|mailbox>, ie a queue of
incoming NARP messages waiting to be transferred. The mailbox has a
maximum <em|size> (buffer size), and a <em|send> call may fail with a
<em|no space left in queue> error. This is the only possible failure for
a <em|send> call.
System processes (level 2) spend most of their time in <em|waiting mode>
; they may be waked up by either recieving a NARP messsage or by a
hardware event. Therefore the <em|wait_for_event> function that composes
the main loop may return either : <em|a message was recieved> or <em|a
system event happenned>. If the reason is <em|a message was recieved>,
the process is free not to read the message immediately.
On the other hand, user processes can wait for only one thing : recieving
a NARP message. Each user process has a <em|message zone> in its memory
space, and the <em|wait for message> function just copies the first
message of the mailbox into this zone (overwriting whatever was there
before) and returns control to the process (returning the length of the
message).
<item>Handling of IRQs : some hardware stuff requires action as soon as
the interrupt is fired, therefore a specifi IRQ handler may be used. Such
a handler must do as little as possible, and when it is done signal level
1 that an IRQ has happenned (it may add specific data to the ``IRQ
happenned'' message). Level 1 adds a message to the queue of the
recipient process (if there is one) and returns immediately : the IRQ
handler must leave as soon as possible. An IRQ is handled on whatever
stack is currently used, and the IF flag is constantly off while the IRQ
handler is running. The timer IRQ is the only one that behaves
differently, since it has to trigger a task switch.
</itemize>
<subsection|Steps of the developpment of the OS>
<\enumerate>
<item>Develop level 0 completely and with cleanest possible design
<item>Develop level 1 with only basic funcionnality
<item>Develop some basic applications in level 2 : display, keyboard,
mini kernel shell, mini file system, ...
<item>Improve level 1 with more complex stuff ; try to quickly attain a
complete level 1
<item>Work on the rest of the stuff
</enumerate>
</body>
<\initial>
<\collection>
<associate|page-medium|paper>
</collection>
</initial>
<\references>
<\collection>
<associate|auto-1|<tuple|1|1>>
<associate|auto-10|<tuple|2.5.3|3>>
<associate|auto-11|<tuple|2.5.4|3>>
<associate|auto-12|<tuple|2.6|4>>
<associate|auto-13|<tuple|2.7|4>>
<associate|auto-14|<tuple|2.8|4>>
<associate|auto-15|<tuple|2.9|4>>
<associate|auto-16|<tuple|2.9.1|4>>
<associate|auto-17|<tuple|2.9.2|4>>
<associate|auto-18|<tuple|2.9.3|4>>
<associate|auto-19|<tuple|2.9.4|5>>
<associate|auto-2|<tuple|2|1>>
<associate|auto-20|<tuple|2.9.5|5>>
<associate|auto-21|<tuple|2.9.6|5>>
<associate|auto-22|<tuple|3|5>>
<associate|auto-23|<tuple|3.1|5>>
<associate|auto-24|<tuple|3.2|5>>
<associate|auto-25|<tuple|3.3|6>>
<associate|auto-26|<tuple|3.3.0.1|6>>
<associate|auto-27|<tuple|3.3.0.2|6>>
<associate|auto-28|<tuple|3.3.0.3|6>>
<associate|auto-29|<tuple|3.3.0.4|6>>
<associate|auto-3|<tuple|2.1|1>>
<associate|auto-30|<tuple|3.3.0.5|6>>
<associate|auto-31|<tuple|3.3.0.6|7>>
<associate|auto-32|<tuple|3.3.0.7|7>>
<associate|auto-33|<tuple|3.3.0.8|7>>
<associate|auto-34|<tuple|3.3.0.9|7>>
<associate|auto-35|<tuple|3.3.0.10|7>>
<associate|auto-36|<tuple|3.3.0.11|7>>
<associate|auto-37|<tuple|3.3.0.12|7>>
<associate|auto-38|<tuple|3.3.0.13|8>>
<associate|auto-39|<tuple|3.3.0.14|8>>
<associate|auto-4|<tuple|2.2|2>>
<associate|auto-40|<tuple|3.3.0.15|8>>
<associate|auto-41|<tuple|3.3.0.16|8>>
<associate|auto-42|<tuple|3.3.0.17|8>>
<associate|auto-43|<tuple|3.3.0.18|8>>
<associate|auto-44|<tuple|3.3.0.19|8>>
<associate|auto-45|<tuple|3.3.0.20|9>>
<associate|auto-46|<tuple|3.3.0.21|9>>
<associate|auto-47|<tuple|3.3.0.22|9>>
<associate|auto-48|<tuple|3.3.0.23|9>>
<associate|auto-49|<tuple|3.3.0.24|9>>
<associate|auto-5|<tuple|2.3|2>>
<associate|auto-50|<tuple|3.3.0.25|10>>
<associate|auto-51|<tuple|3.3.0.26|10>>
<associate|auto-52|<tuple|3.4|10>>
<associate|auto-53|<tuple|3.5|10>>
<associate|auto-54|<tuple|3.5.0.27|10>>
<associate|auto-55|<tuple|3.5.0.28|10>>
<associate|auto-56|<tuple|3.5.0.29|10>>
<associate|auto-57|<tuple|3.6|10>>
<associate|auto-58|<tuple|3.7|11>>
<associate|auto-59|<tuple|3.7.1|11>>
<associate|auto-6|<tuple|2.4|2>>
<associate|auto-60|<tuple|3.7.1.1|11>>
<associate|auto-61|<tuple|3.7.1.2|11>>
<associate|auto-62|<tuple|3.7.2|11>>
<associate|auto-63|<tuple|3.7.3|11>>
<associate|auto-64|<tuple|3.7.3.1|11>>
<associate|auto-65|<tuple|3.7.3.2|11>>
<associate|auto-66|<tuple|3.7.3.3|11>>
<associate|auto-67|<tuple|4|11>>
<associate|auto-68|<tuple|5|11>>
<associate|auto-69|<tuple|5.1|12>>
<associate|auto-7|<tuple|2.5|3>>
<associate|auto-70|<tuple|5.2|12>>
<associate|auto-71|<tuple|4|12>>
<associate|auto-72|<tuple|5|12>>
<associate|auto-73|<tuple|3.10.3.3|12>>
<associate|auto-74|<tuple|4|12>>
<associate|auto-75|<tuple|5|13>>
<associate|auto-8|<tuple|2.5.1|3>>
<associate|auto-9|<tuple|2.5.2|3>>
<associate|error-nums|<tuple|3.7.2|12>>
<associate|footnote-1|<tuple|1|2>>
<associate|footnote-2|<tuple|2|?>>
<associate|footnr-1|<tuple|1|2>>
<associate|footnr-2|<tuple|2|?>>
<associate|interface-nums|<tuple|3.7.3|12>>
<associate|rev-sock|<tuple|2.4|2>>
<associate|type-nums|<tuple|3.7.1|11>>
</collection>
</references>
<\auxiliary>
<\collection>
<\associate|toc>
<vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|1<space|2spc>Introduction>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-1><vspace|0.5fn>
<vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|2<space|2spc>High-level
overview> <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-2><vspace|0.5fn>
<with|par-left|<quote|1tab>|2.1<space|2spc>The basic operations on
services and objects <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-3>>
<with|par-left|<quote|1tab>|2.2<space|2spc>The basics of the NARP
protocol <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-4>>
<with|par-left|<quote|1tab>|2.3<space|2spc>Recursion
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-5>>
<with|par-left|<quote|1tab>|2.4<space|2spc>Reverse object
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-6>>
<with|par-left|<quote|1tab>|2.5<space|2spc>Specific object types and
associated messages <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-7>>
<with|par-left|<quote|2tab>|2.5.1<space|2spc>Objects are sockets
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-8>>
<with|par-left|<quote|2tab>|2.5.2<space|2spc>File objects
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-9>>
<with|par-left|<quote|2tab>|2.5.3<space|2spc>User IO (terminals...)
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-10>>
<with|par-left|<quote|2tab>|2.5.4<space|2spc>Specific applications
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-11>>
<with|par-left|<quote|1tab>|2.6<space|2spc>Big messages
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-12>>
<with|par-left|<quote|1tab>|2.7<space|2spc>Permissions
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-13>>
<with|par-left|<quote|1tab>|2.8<space|2spc>Reliability concerns
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-14>>
<with|par-left|<quote|1tab>|2.9<space|2spc>Example NARP servers
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-15>>
<with|par-left|<quote|2tab>|2.9.1<space|2spc>Virtual NARP server (i.e.
NARP router) <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-16>>
<with|par-left|<quote|2tab>|2.9.2<space|2spc>NARP file server
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-17>>
<with|par-left|<quote|2tab>|2.9.3<space|2spc>NARP terminal/GUI server
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-18>>
<with|par-left|<quote|2tab>|2.9.4<space|2spc>NARP e-mail and newsgroup
server <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-19>>
<with|par-left|<quote|2tab>|2.9.5<space|2spc>NARP chat server
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-20>>
<with|par-left|<quote|2tab>|2.9.6<space|2spc>NARP applicative server
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-21>>
<vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|3<space|2spc>Specifics
of the NARP protocol> <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-22><vspace|0.5fn>
<with|par-left|<quote|1tab>|3.1<space|2spc>Protocol description format
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-23>>
<with|par-left|<quote|1tab>|3.2<space|2spc>Basic message format
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-24>>
<with|par-left|<quote|1tab>|3.3<space|2spc>Message list for core NARP
protocol <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-25>>
<with|par-left|<quote|4tab>|Hello<with|mode|<quote|math>|\<uparrow\>\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-26><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Error<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-27><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Ack<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-28><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Stat<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-29><vspace|0.15fn>>
<with|par-left|<quote|4tab>|StatR<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-30><vspace|0.15fn>>
<with|par-left|<quote|4tab>|List<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-31><vspace|0.15fn>>
<with|par-left|<quote|4tab>|ListR<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-32><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Attach<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-33><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Attached<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-34><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Send<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-35><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Recieve<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-36><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Detach<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-37><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Detached<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-38><vspace|0.15fn>>
<with|par-left|<quote|4tab>|<with|font-series|<quote|bold>|math-font-series|<quote|bold>|Create<with|mode|<quote|math>|\<uparrow\>>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-39><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Created<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-40><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Delete<with|mode|<quote|math>|\<uparrow\>><with|font-family|<quote|tt>|language|<quote|verbatim>|>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-41><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Link<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-42><vspace|0.15fn>>
<with|par-left|<quote|4tab>|ReadLink<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-43><vspace|0.15fn>>
<with|par-left|<quote|4tab>|ReadLinkR<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-44><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Rename<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-45><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Serve<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-46><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Incoming<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-47><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Accept<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-48><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Unbox<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-49><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Plug<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-50><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Unplug<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-51><vspace|0.15fn>>
<with|par-left|<quote|1tab>|3.4<space|2spc>Big message protocol
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-52>>
<with|par-left|<quote|1tab>|3.5<space|2spc>Authentification and rights
managment commands <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-53>>
<with|par-left|<quote|4tab>|Authenticate<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-54><vspace|0.15fn>>
<with|par-left|<quote|4tab>|NewToken<with|mode|<quote|math>|\<uparrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-55><vspace|0.15fn>>
<with|par-left|<quote|4tab>|NewTokenR<with|mode|<quote|math>|\<downarrow\>>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-56><vspace|0.15fn>>
<with|par-left|<quote|1tab>|3.6<space|2spc>File protocol
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-57>>
<with|par-left|<quote|1tab>|3.7<space|2spc>UI protocols
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-58>>
<with|par-left|<quote|2tab>|3.7.1<space|2spc>Terminal protocol
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-59>>
<with|par-left|<quote|2tab>|3.7.2<space|2spc>Graphical user interface
protocol <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-60>>
<with|par-left|<quote|1tab>|3.8<space|2spc>Communication protocols
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-61>>
<with|par-left|<quote|2tab>|3.8.1<space|2spc>Email and newsgroups
protocol <datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-62>>
<with|par-left|<quote|2tab>|3.8.2<space|2spc>Instant messaging protocol
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-63>>
<with|par-left|<quote|1tab>|3.9<space|2spc>Other protocols
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-64>>
<with|par-left|<quote|1tab>|3.10<space|2spc>Table of IDs
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-65>>
<with|par-left|<quote|2tab>|3.10.1<space|2spc>Message types
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-66>>
<with|par-left|<quote|4tab>|Base protocol
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-67><vspace|0.15fn>>
<with|par-left|<quote|4tab>|Authentication & privileges
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-68><vspace|0.15fn>>
<with|par-left|<quote|2tab>|3.10.2<space|2spc>Error messages
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-69>>
<with|par-left|<quote|2tab>|3.10.3<space|2spc>Object interfaces
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-70>>
<with|par-left|<quote|4tab>|Servable
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-71><vspace|0.15fn>>
<with|par-left|<quote|4tab>|non-NARP inside
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-72><vspace|0.15fn>>
<with|par-left|<quote|4tab>|NARP service
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-73><vspace|0.15fn>>
<vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|4<space|2spc>Architecture
of a NARP implementation in OCaml or Haskell>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-74><vspace|0.5fn>
<vspace*|1fn><with|font-series|<quote|bold>|math-font-series|<quote|bold>|5<space|2spc>Using
NARP to design an Operating System>
<datoms|<macro|x|<repeat|<arg|x>|<with|font-series|medium|<with|font-size|1|<space|0.2fn>.<space|0.2fn>>>>>|<htab|5mm>>
<no-break><pageref|auto-75><vspace|0.5fn>
</associate>
</collection>
</auxiliary>
