[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Michal Suchanek |
Subject: |
Re: Reliability of RPC services |
Date: |
Wed, 26 Apr 2006 11:08:01 +0200 |
On 4/25/06, Jonathan S. Shapiro <address@hidden> wrote:
> On Tue, 2006-04-25 at 18:14 +0200, Pierre THIERRY wrote:
> > Scribit Bas Wijnen dies 25/04/2006 hora 16:51:
> > > However, as far as I see it, only the performance problem is actually
> > > valid for the move-only-send-exactly-once capabilities.
> >
> > IIRC, move-only capabilities add a check in the copy process which
> > impacts performance.
>
> Yes. But truthfully this is a small issue. The bigger issue is that an
> application cannot perform a copy without knowing what "type" of
> capability it is copying. It needs to know this because the copy
> behavior depends on the capability type.
>
> Notice that this is not the same as the interface type, and it
> introduces a significant application complexity.
>
> Note further that not all reply capabilities are invoked by a reply.
> Some are invoked by a send or a call!
>
I would expect the interface to the service to define what kind of
capability is accepted. This way the program will always assume the
right capability type, and no complexity is needed.
If the type is not directly checked by the kernel when performing the
IPC the application may have to check for capabilities that are
insufficient to perform the service.
Another question is if client submitting a send capability instead of
reply capability (or non-counted reply instead of reference-counted
reply capability) is violating the protocol. The capability should be
sufficient to perform the service but giving more authority than
needed can cause risks for the client.
Thanks
Michal
- Re: Cancellation forwarding protocol (was Re: Reliability of RPC services), (continued)
- Re: Cancellation forwarding protocol (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/27
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services,
Michal Suchanek <=
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/24
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/24
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/23
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/22