Unum - Revision history

Toby.murray: Reverted edits by 62.206.137.42 (Talk); changed back to last version by Kevin Reid

2011-04-21T05:32:55Z

Reverted edits by 62.206.137.42 (Talk); changed back to last version by Kevin Reid

New page

An unum can be described as a single conceptual object with a distributed implementation.
An object, called the "master presence", is replicated at different locations using smart proxies, called "presences".
The presences cache some state of the master presence and can be used to communicate with the master presence.
----
<div style="float: right;width:360px;font-size:80%;border:1px solid #aaaaaa;padding:5px;margin-left:5px;margin-top:20px;">
[[Image:Unum.png|Unum Example]]

A simple unum representing a circle. Using lamport slots, the non-authoritative presences on the right synchronize their state with the authoritative presence on the left. Mutating message calls are forwarded from the presences to their respective authoritative presence.
</div>

Note: At this point this page is directly copied from [http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]

The Unum Pattern goes back to Chip Morningstar's work at Electric Communities.

Each replica of an Unum is a "presence" of the Unum, and all the presences jointly are taken
to form the Unum. One of the presences is the "authoritative presence" --
its state is considered to be the "true" state of the Unum.
A1, being the
initial presence, therefore starts out as the authoritative presence.

The other presences are effectively smart remote references to the
authoritative presence. These "shadow presences" maintain a somewhat stale
cache of a copy of some state from the authoritative presence -- but only
state that can be useful even when it's stale. These shadow presences do
support immediate calls for those operations that can be sensible performed
using this stale data -- giving us another huge victory over network
latency. But operations needing accurate state must still be eventual, and
must be delegated to the authoritative presence.

The shadow presences also register themselves as observers (in E,
"reactors") on the authoritative presence. Every time the authoritative
presence changes replicated state, it notifies all its reactors, so that
they may update their cached copies. In the absence of partition, we can
say that these caches are always "eventually consistent" -- they are always
consistent with some past state, they only move forward in time, and under
quiescence they will always eventually become accurate.
(Does this capture
Lamport-like eventual consistency?)

During a partition, the presence can still give correct, even if
increasingly stale, service for the staleness tolerant operations. Of
course, it must refuse the accurate operations. Should the authoritative
presence again become reachable, the shadow should "heal". (Note: at EC we
didn't do this. Instead, we always invalidated shadow presences on
partition. So although both choices seem valuable, we don't yet have any
experience with shadows that survive partition.)

What happens when a shadow presence A2 is passed? Two simple possibilities are

# a new shadow presence A3 is created that takes the authoritative presence A1 as authoritative. A2 and A3 would both be registered as reactors on A1.
# a new shadow presence A3 is created that takes shadow presence A2 as authoritative. A2 is a reactor on A1, and A3 is a reactor on A2.

1. is Granovetter introduction, and supports grant matching. 2. is
proxying, and does not.

Answer #1 gives us a flat multicast fanout for state updates. Answer #2
turns the presences into a spontaneously malformed multicast tree. (I say
"malformed" because the topology of the tree is based only on acts of
introduction, and not on any sensible performance issues.) NetNews, DNS,
and Notes are all massively scalable systems that use Lamport-like eventual
consistency to distribute state updates.

== See Also ==

[[Pass By Construction]]

[http://www.erights.org/elib/distrib/unum/index.html The Unum: a form of distributed object]

[http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]

[http://www.erights.org/talks/uni-tea/index.html Uni-Tea - Towards a unified, parameterizable model of distributed "object"]

62.206.137.42: mcCtsdJPbtQ

2011-04-20T16:25:52Z

mcCtsdJPbtQ

←Older revision		Revision as of 16:25, 20 April 2011
Line 1:		Line 1:
-	~~An unum can be described as a single conceptual object with a distributed implementation.~~	+	That's not just the best asnwer. It's the bestest answer!
-	~~An object, called the "master presence", is replicated at different locations using smart proxies, called "presences".~~	+
-	~~The presences cache some state of the master presence and can be used to communicate with the master presence.~~	+
-	~~----~~	+
-	~~<div style="float: right;width:360px;font-size:80%;border:1px solid #aaaaaa;padding:5px;margin-left:5px;margin-top:20px;">~~	+
-	~~[[Image:Unum.png\|Unum Example]]~~	+
-		+
-	A simple unum representing a circle. Using lamport slots, the non-authoritative presences on the right synchronize their state with the authoritative presence on the left. Mutating message calls are forwarded from the presences to their respective authoritative presence.	+
-	~~</div>~~	+
-		+
-	~~Note: At this point this page is directly copied from [http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM~~'s ~~post to the E-Lang mailing list]~~	+
-		+
-	~~The Unum Pattern goes back to Chip Morningstar's work at Electric Communities.~~	+
-		+
-	~~Each replica of an Unum is a "presence" of the Unum, and all the presences jointly are taken~~	+
-	~~to form the Unum. One of the presences is the "authoritative presence" --~~	+
-	~~its state is considered to be the "true" state of the Unum.~~	+
-	~~A1, being the~~	+
-	~~initial presence, therefore starts out as the authoritative presence.~~	+
-		+
-		+
-	~~The other presences are effectively smart remote references to the~~	+
-	~~authoritative presence. These "shadow presences" maintain a somewhat stale~~	+
-	~~cache of a copy of some state from the authoritative presence -- but only~~	+
-	~~state that can be useful even when it's stale. These shadow presences do~~	+
-	~~support immediate calls for those operations that can be sensible performed~~	+
-	~~using this stale data -- giving us another huge victory over network~~	+
-	~~latency. But operations needing accurate state must still be eventual, and~~	+
-	~~must be delegated to the authoritative presence.~~	+
-		+
-	~~The shadow presences also register themselves as observers (in E,~~	+
-	~~"reactors") on the authoritative presence. Every time the authoritative~~	+
-	~~presence changes replicated state, it notifies all its reactors, so that~~	+
-	~~they may update their cached copies. In the absence of partition, we can~~	+
-	~~say that these caches are always "eventually consistent" -- they are always~~	+
-	~~consistent with some past state, they only move forward in time, and under~~	+
-	~~quiescence they will always eventually become accurate.~~	+
-	~~(Does this capture~~	+
-	~~Lamport-like eventual consistency?)~~	+
-		+
-	~~During a partition, the presence can still give correct, even if~~	+
-	~~increasingly stale, service for the staleness tolerant operations. Of~~	+
-	~~course, it must refuse the accurate operations. Should the authoritative~~	+
-	~~presence again become reachable, the shadow should "heal". (Note: at EC we~~	+
-	~~didn't do this. Instead, we always invalidated shadow presences on~~	+
-	~~partition. So although both choices seem valuable, we don't yet have any~~	+
-	~~experience with shadows that survive partition.)~~	+
-		+
-	~~What happens when a shadow presence A2 is passed? Two simple possibilities are~~	+
-		+
-	~~# a new shadow presence A3 is created that takes the authoritative presence A1 as authoritative. A2 and A3 would both be registered as reactors on A1.~~	+
-	~~# a new shadow presence A3 is created that takes shadow presence A2 as authoritative. A2 is a reactor on A1, and A3 is a reactor on A2.~~	+
-		+
-	~~1. is Granovetter introduction, and supports grant matching. 2. is~~	+
-	~~proxying, and does~~ not.	+
-		+
-	~~Answer #1 gives us a flat multicast fanout for state updates. Answer #2~~	+
-	~~turns~~ the ~~presences into a spontaneously malformed multicast tree~~. ~~(I say~~	+
-	~~"malformed" because the topology of the tree is based only on acts of~~	+
-	~~introduction, and not on any sensible performance issues.) NetNews, DNS,~~	+
-	~~and Notes are all massively scalable systems that use Lamport-like eventual~~	+
-	~~consistency to distribute state updates.~~	+
-		+
-		+
-	~~== See Also ==~~	+
-		+
-	~~[[Pass By Construction]]~~	+
-		+
-	~~[http://www.erights.org/elib/distrib/unum/index.html The Unum: a form of distributed object]~~	+
-		+
-	~~[http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM~~'s ~~post to~~ the ~~E-Lang mailing list]~~	+
-		+
-	~~[http://www.erights.org/talks/uni-tea/index.html Uni-Tea - Towards a unified, parameterizable model of distributed "object"]~~	+

Kevin Reid: Unum Pattern moved to Unum

2009-08-17T13:17:14Z

Unum Pattern moved to Unum

←Older revision

Revision as of 13:17, 17 August 2009

Mscheffler: image placement

2007-04-18T16:11:48Z

image placement

←Older revision		Revision as of 16:11, 18 April 2007
Line 3:		Line 3:
	The presences cache some state of the master presence and can be used to communicate with the master presence.		The presences cache some state of the master presence and can be used to communicate with the master presence.
	----		----
-	[[Image:Unum.png~~\|200px\|thumb~~\|Unum Example]]	+	<div style="float: right;width:360px;font-size:80%;border:1px solid #aaaaaa;padding:5px;margin-left:5px;margin-top:20px;">
		+	[[Image:Unum.png\|Unum Example]]

	A simple unum representing a circle. Using lamport slots, the non-authoritative presences on the right synchronize their state with the authoritative presence on the left. Mutating message calls are forwarded from the presences to their respective authoritative presence.		A simple unum representing a circle. Using lamport slots, the non-authoritative presences on the right synchronize their state with the authoritative presence on the left. Mutating message calls are forwarded from the presences to their respective authoritative presence.
-	~~----~~	+	</div>
		+
	Note: At this point this page is directly copied from [http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]		Note: At this point this page is directly copied from [http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]

Mscheffler at 15:58, 18 April 2007

2007-04-18T15:58:39Z

←Older revision		Revision as of 15:58, 18 April 2007
Line 2:		Line 2:
	An object, called the "master presence", is replicated at different locations using smart proxies, called "presences".		An object, called the "master presence", is replicated at different locations using smart proxies, called "presences".
	The presences cache some state of the master presence and can be used to communicate with the master presence.		The presences cache some state of the master presence and can be used to communicate with the master presence.
		+	----
		+	[[Image:Unum.png\|200px\|thumb\|Unum Example]]

-		+	A simple unum representing a circle. Using lamport slots, the non-authoritative presences on the right synchronize their state with the authoritative presence on the left. Mutating message calls are forwarded from the presences to their respective authoritative presence.
	----		----
	Note: At this point this page is directly copied from [http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]		Note: At this point this page is directly copied from [http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]

Mscheffler: added link to PBC page

2007-04-18T10:46:00Z

added link to PBC page

←Older revision		Revision as of 10:46, 18 April 2007
Line 60:		Line 60:

	== See Also ==		== See Also ==
		+
		+	[[Pass By Construction]]
		+
	[http://www.erights.org/elib/distrib/unum/index.html The Unum: a form of distributed object]		[http://www.erights.org/elib/distrib/unum/index.html The Unum: a form of distributed object]

Markm: fixed URL typo

2007-04-17T22:04:57Z

fixed URL typo

←Older revision		Revision as of 22:04, 17 April 2007
Line 5:		Line 5:

	----		----
-	Note: At this point this page is directly copied from [~~http://~~http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]	+	Note: At this point this page is directly copied from [http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]

	The Unum Pattern goes back to Chip Morningstar's work at Electric Communities.		The Unum Pattern goes back to Chip Morningstar's work at Electric Communities.
Line 62:		Line 62:
	[http://www.erights.org/elib/distrib/unum/index.html The Unum: a form of distributed object]		[http://www.erights.org/elib/distrib/unum/index.html The Unum: a form of distributed object]

-	[~~http://~~http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]	+	[http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]

	[http://www.erights.org/talks/uni-tea/index.html Uni-Tea - Towards a unified, parameterizable model of distributed "object"]		[http://www.erights.org/talks/uni-tea/index.html Uni-Tea - Towards a unified, parameterizable model of distributed "object"]

Mscheffler at 14:05, 17 April 2007

2007-04-17T14:05:21Z

←Older revision		Revision as of 14:05, 17 April 2007
Line 1:		Line 1:
-	~~The Unum Pattern~~ can be described as a single conceptual object with a distributed implementation.	+	An unum can be described as a single conceptual object with a distributed implementation.
	An object, called the "master presence", is replicated at different locations using smart proxies, called "presences".		An object, called the "master presence", is replicated at different locations using smart proxies, called "presences".
	The presences cache some state of the master presence and can be used to communicate with the master presence.		The presences cache some state of the master presence and can be used to communicate with the master presence.

Mscheffler at 14:04, 17 April 2007

2007-04-17T14:04:38Z

←Older revision		Revision as of 14:04, 17 April 2007
Line 3:		Line 3:
	The presences cache some state of the master presence and can be used to communicate with the master presence.		The presences cache some state of the master presence and can be used to communicate with the master presence.

-	---	+
		+	----
	Note: At this point this page is directly copied from [http://http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]		Note: At this point this page is directly copied from [http://http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]

Mscheffler at 14:03, 17 April 2007

2007-04-17T14:03:09Z

←Older revision		Revision as of 14:03, 17 April 2007
Line 1:		Line 1:
		+	The Unum Pattern can be described as a single conceptual object with a distributed implementation.
		+	An object, called the "master presence", is replicated at different locations using smart proxies, called "presences".
		+	The presences cache some state of the master presence and can be used to communicate with the master presence.
		+
		+	---
	Note: At this point this page is directly copied from [http://http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]		Note: At this point this page is directly copied from [http://http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html MarkM's post to the E-Lang mailing list]

Line 10:		Line 15:


-	he other presences are effectively smart remote references to the	+	The other presences are effectively smart remote references to the
	authoritative presence. These "shadow presences" maintain a somewhat stale		authoritative presence. These "shadow presences" maintain a somewhat stale
	cache of a copy of some state from the authoritative presence -- but only		cache of a copy of some state from the authoritative presence -- but only