diff options
| -rw-r--r-- | .gitignore | 4 | ||||
| -rw-r--r-- | doc/narp.pdf | bin | 0 -> 123463 bytes | |||
| -rw-r--r-- | doc/narp.tm | 1127 |
3 files changed, 1131 insertions, 0 deletions
diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..c158862 --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +# Temporary files +*~ +*.swp + diff --git a/doc/narp.pdf b/doc/narp.pdf Binary files differnew file mode 100644 index 0000000..1804485 --- /dev/null +++ b/doc/narp.pdf diff --git a/doc/narp.tm b/doc/narp.tm new file mode 100644 index 0000000..a992ffe --- /dev/null +++ b/doc/narp.tm @@ -0,0 +1,1127 @@ +<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, + ... + </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 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 + (eventually 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> : requests the creation of a ressource in the + namespace + + <item><verbatim|delete> : requests the deletion of a ressource in the + namespace + + <item><verbatim|link> : create a link for an object under another name + (these are always symbolic links, and are independent of the pointed + ressource) + </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 + </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 possibilith 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. + + <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|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|<math|\<ldots\>>>|<cell|element type>>|<row|<cell|element + description>|<cell|element description>|<cell|<math|\<ldots\>.>>|<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 most messages. Specific interfaces for + objects are responsible for making sure messages have been transmitted + correctly. + + <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\>>> + + <\indent> + Response to the <strong|Stat> message. + + <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\>>> + + <\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\>>> + + <\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>>>>> + </indent> + + <paragraph|Recieve<math|\<downarrow\>>> + + <\indent> + Spontaneous server message indicating some data is sent by object. + + <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>>>>> + </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\>>> + + <\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\>>> + + <\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>>|<row|<cell|header>|<cell|request + ID>|<cell|path>>>>> + + 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 following few 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. + </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\>>> + + <\indent> + <block*|<tformat|<table|<row|<cell|>|<cell|int32>|<cell|str>>|<row|<cell|header>|<cell|message + ID>|<cell|token>>>>> + </indent> + + More TODO : request account creation, manage user groups and ACLs, ... + + <subsection|File protocol> + + Client messages [50,100) ; server messages [10050,10100). + + <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|NARP + service>|<cell|once attached, inside data is also NARP + protocol>>|<row|<cell|2>|<cell|non-NARP socket>|<cell|once attached, + inside data is arbitrary>>|<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, + graphics semantics>>>>> + </indent> + + <section|Architecture of a NARP implementation in OCaml or Haskell> + + \; +</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|4>> + <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.8.1|4>> + <associate|auto-16|<tuple|2.8.2|4>> + <associate|auto-17|<tuple|2.8.3|4>> + <associate|auto-18|<tuple|2.8.4|5>> + <associate|auto-19|<tuple|2.8.5|5>> + <associate|auto-2|<tuple|2|1>> + <associate|auto-20|<tuple|2.8.6|5>> + <associate|auto-21|<tuple|3|5>> + <associate|auto-22|<tuple|3.1|5>> + <associate|auto-23|<tuple|3.2|5>> + <associate|auto-24|<tuple|3.3|6>> + <associate|auto-25|<tuple|3.3.0.1|6>> + <associate|auto-26|<tuple|3.3.0.2|6>> + <associate|auto-27|<tuple|3.3.0.3|7>> + <associate|auto-28|<tuple|3.3.0.4|7>> + <associate|auto-29|<tuple|3.3.0.5|7>> + <associate|auto-3|<tuple|2.1|1>> + <associate|auto-30|<tuple|3.3.0.6|7>> + <associate|auto-31|<tuple|3.3.0.7|7>> + <associate|auto-32|<tuple|3.3.0.8|8>> + <associate|auto-33|<tuple|3.3.0.9|8>> + <associate|auto-34|<tuple|3.3.0.10|8>> + <associate|auto-35|<tuple|3.3.0.11|8>> + <associate|auto-36|<tuple|3.3.0.12|8>> + <associate|auto-37|<tuple|3.3.0.13|8>> + <associate|auto-38|<tuple|3.3.0.14|8>> + <associate|auto-39|<tuple|3.3.0.15|8>> + <associate|auto-4|<tuple|2.2|2>> + <associate|auto-40|<tuple|3.3.0.16|8>> + <associate|auto-41|<tuple|3.3.0.17|9>> + <associate|auto-42|<tuple|3.3.0.18|9>> + <associate|auto-43|<tuple|3.3.0.19|9>> + <associate|auto-44|<tuple|3.3.0.20|9>> + <associate|auto-45|<tuple|3.3.0.21|9>> + <associate|auto-46|<tuple|3.3.0.22|9>> + <associate|auto-47|<tuple|3.3.0.23|10>> + <associate|auto-48|<tuple|3.4|10>> + <associate|auto-49|<tuple|3.5|10>> + <associate|auto-5|<tuple|2.3|2>> + <associate|auto-50|<tuple|3.5.0.24|10>> + <associate|auto-51|<tuple|3.5.0.25|10>> + <associate|auto-52|<tuple|3.5.0.26|10>> + <associate|auto-53|<tuple|3.6|10>> + <associate|auto-54|<tuple|3.7|10>> + <associate|auto-55|<tuple|3.7.1|10>> + <associate|auto-56|<tuple|3.7.2|10>> + <associate|auto-57|<tuple|3.8|11>> + <associate|auto-58|<tuple|3.8.1|11>> + <associate|auto-59|<tuple|3.8.2|11>> + <associate|auto-6|<tuple|2.4|3>> + <associate|auto-60|<tuple|3.9|11>> + <associate|auto-61|<tuple|3.10|?>> + <associate|auto-62|<tuple|3.10.1|?>> + <associate|auto-63|<tuple|3.10.1.1|?>> + <associate|auto-64|<tuple|3.10.1.2|?>> + <associate|auto-65|<tuple|3.10.2|?>> + <associate|auto-66|<tuple|3.10.3|?>> + <associate|auto-67|<tuple|4|?>> + <associate|auto-7|<tuple|2.5|3>> + <associate|auto-8|<tuple|2.5.1|3>> + <associate|auto-9|<tuple|2.5.2|3>> + <associate|error-nums|<tuple|3.10.2|?>> + <associate|footnote-1|<tuple|1|3>> + <associate|footnote-2|<tuple|2|?>> + <associate|footnr-1|<tuple|1|3>> + <associate|footnr-2|<tuple|2|?>> + <associate|interface-nums|<tuple|3.10.3|?>> + <associate|rev-sock|<tuple|2.4|3>> + <associate|type-nums|<tuple|3.10.1|?>> + </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>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-14>> + + <with|par-left|<quote|2tab>|2.8.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-15>> + + <with|par-left|<quote|2tab>|2.8.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-16>> + + <with|par-left|<quote|2tab>|2.8.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-17>> + + <with|par-left|<quote|2tab>|2.8.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-18>> + + <with|par-left|<quote|2tab>|2.8.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-19>> + + <with|par-left|<quote|2tab>|2.8.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-20>> + + <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-21><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-22>> + + <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-23>> + + <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-24>> + + <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-25><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-26><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-27><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-28><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-29><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-30><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-31><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-32><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-33><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-34><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-35><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-36><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-37><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-38><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-39><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-40><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-41><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-42><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-43><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-44><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-45><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-46><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-47>> + + <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-48>> + + <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-49><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-50><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-51><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-52>> + + <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-53>> + + <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-54>> + + <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-55>> + + <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-56>> + + <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-57>> + + <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-58>> + + <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-59>> + + <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-60><vspace|0.5fn> + </associate> + </collection> +</auxiliary>
\ No newline at end of file |