[E-Lang] New Page: Partially Ordered Message Delivery

Karp, Alan alan_karp@hp.com
Fri, 16 Feb 2001 11:44:17 -0800


E-speak handles the policy with ordinary code.  In Beta 2.2 a proxy for the
remote machine handled all communication between that machine and the core.
That's where the policy on keeping state was embodied.  All "imported" state
was stored as transient, meaning it was kept as long as the connection with
the core was live.  If the connection was ad hoc, the proxy would drop the
connection to the core, resulting in all state being removed.  If the
connection was expected to be persistent, the proxy would keep the
connection live.  In the current release, the cores connect directly, one
being a client of the other.  In this case, the cores use either a transient
or a persistent context for the connection.

A consistent world view was not an issue for e-speak, because we assumed
things were inconsistent.  The whole system was built on the premise that
any piece of data, even from the local machine, might be out of date.  In
those rare cases where it mattered, it was up to the application to get the
latest version.  Of course, we provided mechanisms, such as events, to
automatically update state changes, but we recognized that delays prevent
truly dynamic systems from ever being totally consistent.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap@cs.jhu.edu]
> Sent: Thursday, February 15, 2001 6:34 AM
> To: Tyler Close
> Cc: Karp, Alan; Mark S. Miller; E Language Discussions
> Subject: Re: [E-Lang] New Page: Partially Ordered Message Delivery
> 
> 
> Tyler Close wrote:
> > 
> > Alan Karp wrote:
> > > We decided that it should be a policy decision based on who
> > > you're talking
> > > to as to which behavior you got.  Where we expected the
> > > connection to be
> > > there, all references were kept and were immediately available on
> > > reconnection. 
> 
> This discussion has also come up in the context of 
> distributing EROS. I
> think our take on it is going to come out as follows:
> 
> 1. Non-reauthenticatable connections outside the box are lost.
> 2. We will probably build a "helper" agent to rebuild cross-machine
> capabilities in a semi-automated way.
> 
> Unfortunately, this proves to be a place where transparent persistence
> is a bit of an annoyance, because the two machines may not have a
> consistent worldview after recovery. This is no different than the
> situation that now exists between "normal" clients and servers, but
> dealing with it requires a deviation from the "normal" 
> programming style
> in EROS (which is to assume that everything survives consistently).
> 
> As far as I can tell, the best way to deal with the problem is to wrap
> cross-machine things in transactions that are aborted by restart, and
> then keep some form of replay or undo log on both sides so that the
> logical connection state can be recovered.
> 
> My point, in the context of E/E-Speak is that this policy 
> decision does
> not appear to need to be made in the heart of the core runtime. It can
> be solved with helper code.
> 
> Question for Alan (others also welcome): in your experience with
> E-Speak, did it prove that there was some compelling reason 
> of trust of
> security that motivated moving things into the runtime, or did you
> basically handle this with ordinary code?
> 
> 
> Jonathan
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>