From 1f27167dcfdddc75c83ab746bbd3589f003458b9 Mon Sep 17 00:00:00 2001 From: Alex Auvolat Date: Fri, 28 Nov 2014 16:52:51 +0100 Subject: Add Unbox, Plug, Unplug. --- doc/narp.tm | 136 +++++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 97 insertions(+), 39 deletions(-) (limited to 'doc') diff --git a/doc/narp.tm b/doc/narp.tm index 8fe4a04..30450f3 100644 --- a/doc/narp.tm +++ b/doc/narp.tm @@ -651,6 +651,56 @@ 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 @@ -762,7 +812,7 @@ / >||||>||>| / >||||>||>| / >|||| - / >||>|>||||||>|>||||||>|>||||||>>>> + / >||>|>||||||>|>||||>||>|>||||>||>|||||>||>>>> @@ -791,16 +841,19 @@ <\indent> ||>|||, - , >>||, >>|||, + >>|||, + >>|||>|||>|||>|||, - >>|||, - >>|||>|||>|||>>>> + arbitrary>>|||>||| command supported>>||| and commands + supported>>|||>|||>|||>|||>>>> \ This interface specifies that the object is currently @@ -835,11 +888,13 @@ 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). + to userspace. For instance, this would allow the simplification of useless + mux-demux chains taking place on the same machine. The mux-demux helper can + be implemented via the protocol message, handled at the + level of the root stream of NARP communication with the kernel. Another + possible helper would be to map a virtual memory region to a NARP ressource + implementing a standard filing protocol, much like memory mapped files in + standard OSes (only this would work with arbitrary ressources). TODO @@ -895,33 +950,36 @@ > > > - > + > > - > - > - > - > - > - > - > - > - > - > + > + > + > + > + > + > + > + > + > + > > - > - > - > - > - > - > - > - > - > - > + > + > + > + > + > + > + > + > + > + > > - > - > - > + > + > + > + > + > + > > > > -- cgit v1.2.3