[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Jonathan S. Shapiro |
Subject: |
Re: Reliability of RPC services |
Date: |
Mon, 24 Apr 2006 16:45:36 -0400 |
On Mon, 2006-04-24 at 22:09 +0200, Tom Bachmann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Marcus Brinkmann wrote:
> > I don't think there is a general
> > answer for M to the question when it needs to recover.
> >
>
> can't C just tell M?
I think that there must have been a private message here, or perhaps I
have not received Marcus's message yet.
The answer in general is "no", for two reasons:
1. C may not be entitled to know what M will do. It is hard to predict
how to recover from unknown actions.
2. It would make the interface impossibly complicated.
This is why I was very careful in my description to say that "the
recovery boundary is between M and S". This means that C trusts M fully
to recover in whatever way is appropriate (i.e. C and M fail as a unit).
If we are also concerned that M may fail to respond to C, then it is the
obligation of C to implement a recovery strategy.
The point of using three parties in my example was to illustrate that
all recovery boundaries are IPC boundaries, but not all IPC boundaries
are recovery boundaries.
shap
- Re: Reliability of RPC services, (continued)
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/24
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/24
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/24
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/24
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/24
- Re: Reliability of RPC services,
Jonathan S. Shapiro <=
Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/23
RE: Reliability of RPC services, Christopher Nelson, 2006/04/25
RE: Reliability of RPC services, Christopher Nelson, 2006/04/25
RE: Reliability of RPC services, Christopher Nelson, 2006/04/26
RE: Reliability of RPC services, Christopher Nelson, 2006/04/26