<\body> |> 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. 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> Naming of files on a local or distant file system Naming of devices in the virtual filesystem on Unix machines Naming of networked machines (with IP adresses and DNS records) Naming of internet ressources over protocols such as HTTP, IMAP, IRC, specfic web services, ... 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 : and . <\itemize> are ressources that may implement different semantics : bidirectionnal communication (such as sockets) ; unidirectionnal communication (FIFO-like) ; file semantics ; etc. are a way of naming objects, querying the interfaces they implement, and multiplexing communications with them 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 , or just . 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. A NARP service is basically any object that implements the following operations: <\itemize> : get information on a ressource identified by name : know the names of ressources presented by the service (possibly in a specific sub-path) : get an object interface for accessing a ressource, identified by name A NARP object is basically any object that implements the following operations : <\itemize> : send a message (an arbitrary byte string) to the object : recieve a message from the object (this may be done asynchronously with handler functions) : delete object connection 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> : initialize a connection, check version information, ... 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) , and appropriate response messages : get information about the available ressources and appropriate response messages : give an identifier (a descriptor) to a ressource in order to communicate with it and appropriate response messages : send a message to an attached ressource, identified by its descriptor : close a descriptor and detach from a ressource , , , : requests the creation or modification of a ressource in the namespace The server may also at any moment send a message, including: <\itemize> a response to a query : a notification of a message sent from the object to the client : the connection to the object has been terminated by the object server 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.

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. ). A client wishing to act as a reverse object server may use the following commands: <\itemize> : listen for attach requests on a servable (empty) object created in the server namespace (if authorized) and : accept (or reject) an attach request to the object : close connection between object and client (this is the same detach message as in standard communications) : stop serving for the object. Attached clients continue to be attached. The server may in turn send the following messages concerning the server object: <\itemize> : 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. 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. 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 . Small files may implement the following interface: <\itemize> : erase the whole file and put the transmitted content : retrieve the whole file content Big files may implement the following interface: <\itemize> : write a portion of the file at a given offset : read a portion of the file at a given offset 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. Specific applications may define custom messages. Examples include: <\itemize> e-mail instant messaging collaborative editing of text-based documents and many other applications yet to be invented. 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 or on large files, or s and 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. 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. 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. 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. 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. 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. Several features to be implemented: <\itemize> user login and private user mailboxes bridge to standard SMTP/POP3/IMAP services private threads of conversation with access rights (the users don't each have a copy of the thread) synchronization between many servers public discussion forums <\itemize> user login and status notification online and offline private messaging public chat rooms, chat room logging independently of user being online or offline bridging and synchronization between many servers TODO... A protocol message is given in the following form: |||>||||>>>> The following element types apply: <\itemize> , , : 16-bit, 32-bit or 64-bit little-endian integers : a string, prefixed by a 16-bit length header > : an array of 's (where is another element type), prefixed by a 16-bit length header * (for the last element) : consider all the rest of the message as a byte string The basic format of a message is : ||>|||>>>> We will abbreviate by ``header'' the first 32 bits (4 bytes) of the message. The list of message types is given in section . Messages for communication with an attached ressource will have the following format : |||>||||>>>> 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: |||>||||>>>> Client messages have an up arrow (>) next to their name, while server messages have a down arrow |)>>. 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. \>> <\indent> ||>|||>>>> \ \ When a NARP connection is established, the client is always the first to send a message. The object may then respond either with a message indicating that the requested interfaces can be provided, or with an message. The two common error causes are and . For interface numbers : see table in section . >> <\indent> Generic error response message for any operation. |||>||||>>>> Common error IDs are specified in section . >> <\indent> |>||>>>> Generic acknowlegment message for commands that require it. An acknowlege implies the command has been sucessfully executed (otherwise an error message is sent). >> <\indent> ||>|||>>>> The request ID is an ID decided by the client so that it can identify the answer. >>Response to the message. <\indent> ||>|||>>>> Common interface numbers are to be found in section >. If a 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 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> ||||>|||||>>>> >>Response to the message. <\indent> One message is passed for each entry in the requested range: |||>||||>>>> 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. 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. >> <\indent> ||>|||>>>> >>Response to the command. <\indent> ||>|||>>>> (the handle, ie the ressource descriptor, is attributed by the server) >> <\indent> ||>|||>>>> This message does not expect a response. >> <\indent> Spontaneous server message indicating some data is sent by an attached ressource. This message does not expect a response. ||>|||>>>> >> <\indent> |>||>>>> This message does not expect a response. >> <\indent> Spontaneous server message indicating the object has been detached. |>||>>>> >>> <\indent> |||>||||>>>> 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, ...) >>Response to the command. <\indent> ||>|||>>>> Signals that the object has been created, and has corresponding interfaces associated to it. >> <\indent> ||>|||>>>> This message expects a standard response message. >> <\indent> |||>||||>>>> This message expects a standard response message. Semantics of the link object: <\itemize> attaching or serving on this objects corresponds to resolving the linked path and attaching/serving on the linked object stating the link will stat the linked object and add as an implemented interface the ``this is a symlink'' information directory listings follow links deleting the link will not delete the original file but only the link >> <\indent> ||>|||>>>> >>Response to the message. <\indent> ||>|||>>>> This will only return the first level of linking, ie the link data directly associated to the link object. >> <\indent> |||>||||>>>> This message expects a standard response message. >> <\indent> |||>||||>>>> This message is a request for the client to be a reverse server to an object. The response message to this message is an message. The handle attributed to the served object is known as the and is used in the and messages. To stop serving an object, the client simply sends a 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 message must be sent to all of them if we want to close them. The serves to answer messages on the object while we are serving it. >> <\indent> ||>|||>>>> 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 message. The client handle is a handle associated to the connection. The reverse server may reject the connection by issuing a command on the client handle, or may accept it using the message given below. >> <\indent> |>||>>>> Once a connection has been accepted, the reverse server may at any moment close it by sending a command on the corresponding client handle. >> <\indent> |||>||||>>>> Consider the handle as a NARP protocol service, and associate a handle in the outer layer to the handle of the inner layer with handle . Example : in connection A we have a connection open on handle 5 which contains NARP data that we will call B, and in connection B we have another connection open on handle 7. Issuing a Unbox(id, 5, 7) request on A will lead to the server creating a handle (say 12) where sending corresponds to sending a message to handle 7 on connection B, and such that all messages recieved on handle 5 (ie on connection B) are filtered and messages whose destination is handle 7 on connection B are removed from the stream and issued on handle 12 of connection A instead. The answer to such a request is an response giving a handle to the unboxed connection. Systematically unboxing open connections may lead in some cases to the network infrastructure being able to do simplifications in the interconnections. In other cases it may result to useless overhead on the server side : in such a case the server may refuse an unbox request. >> <\indent> |||>||||>>>> Ask the server to redirect all messages recieved on handle A to handle B and all mesages recieved on handle B to handle A. The messages recieved on either handle are not sent to the client anymore. The answer messages are standard / messages. >> <\indent> |||>||||>>>> Undoes a plugging. 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? ... >> <\indent> ||