[info] [croquet-dev] Few quick questions about Croquet Router facets.

[Eugen Leitl]

----- Forwarded message from Howard Stearns <howard.stearns at qwaq.com> -----

From: Howard Stearns <howard.stearns at qwaq.com>
Date: Mon, 12 Nov 2007 08:21:01 -0600
To: croquet-dev at duke.edu
Subject: Re: [croquet-dev] Few quick questions about Croquet Router facets.
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
Reply-To: croquet-dev at duke.edu, Howard Stearns <howard.stearns at qwaq.com>

I've learned from David Reed and from Andreas to think of the developing 
Croquet abstractions as "invention in public." Some abstractions are 
quite clearly defined (e.g., island replication), yet there are still 
plenty of areas to be developed, and anyone's ideas are just as valid as 
anyone elses. It's sometimes hard to know the difference between what's 
been worked out and what has not.

At this moment, I think there is some basic, customizable machinery for 
gaining admittance to a collaboration, and for knowing how things 
operate after that. For example, as I understand it, the initial 
connection to the router is the application programmer's responsibility, 
and the hooks are designed to allow you to follow various well-known 
mechanisms for doing so. Assuming that this initial connection is 
secure, the existing machinery encrypts traffic using a per-user, 
per-session key so that observers can't peek, and per-user, per-session 
facets so that others can't forge.

But what things should have their own facet? My undestanding of the 
simple model so far is that the model does not distinguish capabilities 
within the replication: Messages to the router itself have individual 
facets, but messages to replicated objects that are merely forwarded 
through the router all use the same facet.

This supports the idea of an island as a symmetric group of peers, but 
it doesn't limit you to that. It sounds like you are thinking that 
replicated messages to on-island objects should have individual facets. 
I wondered about that, too. But I'm not completely clear on what problem 
that would solve. For example, if I don't trust logged-in participants 
to send valid messages, then I'm not sure I want them denying service by 
sending any messages. And I think the hard part of what you describe is 
not implementing facet messaging, but implementing facet management. 
(What facets do I have? How did I get them? How do I lose them?) But if 
individual facets for replicated object/messages are the right thing for 
some specific application, then by all means, do it! Let us know how it 
goes!


-Howard

Baldur Johannsson wrote:
>On 11/11/2007, Andreas Raab <andreas.raab at gmx.de> wrote:
>>Baldur Johannsson wrote:
>>>On 11/11/2007, Andreas Raab <andreas.raab at gmx.de> wrote:
>>>>Baldur Johannsson wrote:
>>>>> I am wondering for the reason of why facets are 128 bit as the set of
>>>>>facets are often inside 256 at any given time.
>>>>To create unguessable IDs.
>>>>
>>>Why would unguessable IDs for facets be required?
>>So that they cannot be fabricated by guessing about the ID.
>>
>>>Isnt the mapping from an facet ID to facets local to each Router Client?
>>No.
>>
>Hmm... but the router checks if an TMessageRouterClient has that facet
>in its facet dictionary, yes?
>>>>>So why dont we hit two flies in one blow by dynamicly mapping
>>>>>TObjectIDs and selectors of invocations of TFarRef futureSend: onto
>>>>>Croquet Router facets there by lower the bandwith usage and instating
>>>>>POLA for those objects in TIslands?
>>>>I have no idea what you mean by that.
>>>>
>>>Ah, my mistake of not expanding the acronym of POLA which stands for
>>>Principle Of Least Authority/Access. (Dont give an program more access
>>>than it needs to run and do its task)
>>I know what POLA stands for. What I don't get is is what you mean by
>>"dynamicly mapping TObjectIDs and selectors of invocations of TFarRef
>>futureSend: onto Croquet Router facets there by lower the bandwith usage
>>and instating POLA for those objects in TIslands".
>>
>Mapping of ((TMessageData reciver) (TMessageData selector)) onto an
>router facet is what I was meaning. So instead of an remote client
>using the send facet to send an replicated message it would use an
>facet spefic for that reciver selector pair.
>
>>>I hope that I am not trying your patience with these questions and ideas.
>>>If I do then please notify me so I can stop pestering you.
>>You aren't. I just have no idea what you're trying to say.
>>
>And I am trying as hard as I can to clarify.
>But sometimes one has proplem serializing ones ideas into text ;-)

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE