[cap-talk] OO interoperation via OCap, presentation level issues

[Baldur Johannsson]

2008/5/16 Raoul Duke <raould at gmail.com>:
>> I think the essential and minimal base of ocap communication is
>> asynchronus messages
>
> Given that Caps are in the security field, should one worry about the
> asynchronous default leading to buffer resource consumption? One can
> build async on top of sync with more explicit buffering. (Dunno if
> that matters; Erlang sure seems to do OK with async as the default,
> although in a perf not necessarialy security way.)
>

Depends on how the asynchronity is achieved (that is, how are the
messages actually passed)
Three ways of how comes to mind:
a) using buffers/mailboxes Erlang/Actor style (handy for over-network),
b) using interrupts/signals UNIX style and
c) meet-me principle MINIX3 style.

The meet-me principle: the sending process is blocked in sending until
the receiving process does receive if the receiving process is not
blocked in receiving. And vice versa. When both are ready the kernel
copies from the sending process to receiving process directly.

The possibilities of denials-of-service due to:
  a) overflowing the mailbox. (Can be mitigated by "postage" digital
silkroad style)
  b) hyper-frequent interrupts/signaling. (Can be mitigated by masking
interrupts/signals)
  c) receiver never doing an receive. (Can be mitigated by timeout in
kernel in the basic scheduler).

But also note that with synchronus call/return one would be in the
same boat as c) by
the receiving/invoked process never returning to the sending/invoking process.

Conceptually async messages as I described earlier is the essential
and minimal base as systems using any of the three methods above can
communicate with each other.

So, indeed, inter process communication without possibility of denial
of service is hard.

Thoughts? Comments? Need for clarification?
-Baldur Jóhannsson