[<<][c][>>][..]
Mon Nov 10 17:34:00 CET 2008

RPC and ad-hoc protocols

This is about different ways of looking at procedure calls, mostly
from an object-oriented pov (modify object in-place) vs. functional
programming view (share + copy).

  * In the OBJECT model, the client passes a data object to the
    server, which is modified in place and returned back to the
    client.  (I.e. Unix IOCTL).  The advantage here is that server is
    relieved from memory management.  In the setting of FP, linear
    memory management can be used.

  * In the FUNCTION model, there is no mutation of shared data between
    client and server.  The client passes a copy of the necessary data
    to the server over a message channel, and the server returns a
    reply over a different channel.

The problem I ran into is having to implement an RPC interface over a
unidirectional message protocol.  This happens when what you want is
really a shared library of data objects and function calls, but it
needs to provide control operations behind the scenes (i.e. it has an
event loop that's not triggered by the clients).


An interesting road is to investigate what is necessary to write an
RPC generator: eliminate the red tape by hiding the message protocol
from the user, and expose only procedure calls on both client and
server side, where client calls, and server gets called.

The problem with automating RPC generation is data-sharing: often in
C, a function will allocate or mutate an object, and thus creating a
side-channel.  So it looks like this abstraction is going to be
somewhat leaky, since it needs to be purely functional (copy instead
of mutation).



[Reply][About]
[<<][c][>>][..]