[coyotos-dev] Endpoints and replies

[Bas Wijnen]

Hi,

While seeing this discussion, I am wondering if we are not creating problems
which don't have to be there.

The normal situation is to have at most one receiver per end point.  More than
one is special, and need not be efficient.  Even more, it need not even be
possible.

First of all a question about endpoints: Can anyone who has an endpoint
capability receive on it?  If so, then reusing endpoints without severing them
after every contact seems unacceptable.  So I'm assuming that the capabilities
which are given to partners are send-only.

So in the normal case, there is one receive capability, and one or more send
capabilities.  Why not enforce that?  Just disallow copying of receive
capabilities.  Of course transferring them should be allowed, but that should
then disable the ability to read from it for the original capability (thus
turning it into a send-only capability, or if that is more efficient,
destroying it completely).

I can see exactly one useful situation for allowing multiple receivers: When a
server wants to handle many requests, it is useful to eliminate the dead-time
during the handling of one request.  Even if the server only passes it on to
an other thread and starts listening immediately, there will be some time that
it is unavailable.  In some cases there is no trust and blocking is not an
option (for example for a notification server on an untrusted application).
In such a case, multiple receivers will make sure there is no dead time at
all, until the load is so high that all the receivers are handling a request.

For this, it may be useful to assign a "receiver queue".  The holder of the
receive capability may assign such a queue to an endpoint (from its own
storage, of course).  The queue really holds different types of capabilities
for the endpoint.  Each of those can perform a receive operation.  When
someone sends to the endpoint, the capabilities in the queue are tried in
order to see if there is a receiving thread on it.  If there is, it will
receive the message.  If there isn't, the next one is checked.  All these
capabilities have the property of "lose receive right on copy", so at most one
thread is actually receiving on each of them.  If no capability in the queue
is receiving, then the send blocks (or returns, depending on the flags).

I think this is much simpler than the schemes proposed so far.  Do I miss any
big problems here?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.coyotos.org/pipermail/coyotos-dev/attachments/20060118/210f3cb2/attachment.bin