<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>
<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?
...
Reserved message IDs : <math|<around*|[|20,30|)>> and
<math|<around*|[|10020,10030|)>>.
<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|File protocol>
Client messages [50,100) ; server messages [10050,10100). TODO
<subsection|UI protocols>
Client messages <math|<around*|[|100,200|)>> and server messages
<math|<around*|[|10100,10200|)>>.
<subsubsection|Terminal protocol>
TODO
<subsubsection|Graphical user interface protocol>
TODO
<subsection|Communication protocols>
Client messages <math|<around*|[|200,300|)>> and server messages
<math|<around*|[|10200,10300|)>>.
<subsubsection|Email and newsgroups protocol>
Client messages <math|<around*|[|200,220|)>>, server messages
<math|<around*|[|10200\<nocomma\>,10220|)>>.
<subsubsection|Instant messaging protocol>
Client messages <math|<around*|[|220,250|)>>, server messages
<math|<around*|[|10220\<nocomma\>,10250|)>>.
<subsection|Other protocols>
Protocols not discussed in this specification may use client messages with
type IDs <math|<around*|[|1000,10000|)>> and server messages
<math|<around*|[|11000,20000|)>>. Overlaps between several protocols are
allowed : the information about implemented interfaces for an object is
meant to disambiguate such situations.
<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|>|<cell|>|<cell|>>|<row|<cell|<strong|Accept>>|<cell|9>|<cell|>|<cell|>|<cell|>|<cell|>|<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|non-NARP
inside>|<cell|once attached, inside data is
arbitrary>>|<row|<cell|2>|<cell|NARP service>|<cell|once attached, inside
data is a NARP service (ie has objects,
...)>>|<row|<cell|3>|<cell|enumerable>|<cell|<strong|List>,
<strong|ListR>>>|<row|<cell|4>|<cell|is symlink>|<cell|<strong|ReadLink>,
<strong|ReadLinkR>>>|<row|<cell|10>|<cell|file>|<cell|once attached, file
semantics>>|<row|<cell|11>|<cell|terminal>|<cell|once attached, terminal
semantics>>|<row|<cell|12>|<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. This would allow the simplification of useless mux-demux
chains taking place on the same machine. Another possible helper would be
to map a virtual memory region to a NARP ressource implementing a standard
filing protocol, much as memory mapped files in standard OSes (only this
would work with arbitrary ressources).
TODO
</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.4|9>>
<associate|auto-5|<tuple|2.3|2>>
<associate|auto-50|<tuple|3.5|9>>
<associate|auto-51|<tuple|3.5.0.24|9>>
<associate|auto-52|<tuple|3.5.0.25|10>>
<associate|auto-53|<tuple|3.5.0.26|10>>
<associate|auto-54|<tuple|3.6|10>>
<associate|auto-55|<tuple|3.7|10>>
<associate|auto-56|<tuple|3.7.1|10>>
<associate|auto-57|<tuple|3.7.2|10>>
<associate|auto-58|<tuple|3.8|10>>
<associate|auto-59|<tuple|3.8.1|10>>
<associate|auto-6|<tuple|2.4|2>>
<associate|auto-60|<tuple|3.8.2|10>>
<associate|auto-61|<tuple|3.9|10>>
<associate|auto-62|<tuple|3.10|10>>
<associate|auto-63|<tuple|3.10.1|11>>
<associate|auto-64|<tuple|3.10.1.1|11>>
<associate|auto-65|<tuple|3.10.1.2|11>>
<associate|auto-66|<tuple|3.10.2|11>>
<associate|auto-67|<tuple|3.10.3|11>>
<associate|auto-68|<tuple|3.10.3.1|11>>
<associate|auto-69|<tuple|3.10.3.2|11>>
<associate|auto-7|<tuple|2.5|3>>
<associate|auto-70|<tuple|3.10.3.3|12>>
<associate|auto-71|<tuple|4|12>>
<associate|auto-72|<tuple|5|12>>
<associate|auto-8|<tuple|2.5.1|3>>
<associate|auto-9|<tuple|2.5.2|3>>
<associate|error-nums|<tuple|3.10.2|11>>
<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.10.3|11>>
<associate|rev-sock|<tuple|2.4|2>>
<associate|type-nums|<tuple|3.10.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|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-49>>
<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-50>>
<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-51><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-52><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-53><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-54>>
<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-55>>
<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-56>>
<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-57>>
<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-58>>
<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-59>>
<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-60>>
<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-61>>
<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-62>>
<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-63>>
<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-64><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-65><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-66>>
<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-67>>
<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-68><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-69><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-70><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-71><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-72><vspace|0.5fn>
</associate>
</collection>
</auxiliary>