Few quick questions about Croquet Router facets.

 H'lo Corquet-Dev-List

 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.

 One other thing I noted is that the send facet is, in most examples
of Croquet Routers,
 used to broadcast the replicated external messages headed for an
TIsland (or to its
 contents) regardless of weather the message originator has permission to invoke
 those methods on the recipiant objects or not.
 There by allowing anyone, that is connected to the Croquet Router and
has the send facet,
 to impersonate other message origniators and or invoke

 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?

 (attached, as demostration of what I am thinking, are two of my
classes that are still a work in progress)

 It might incurr changes in TFarRef or TIslandControler sendMessage.

 With hope of quick or comprehensive response.
 -Zarutian

 (ps. English isnt my native language and I have tendence for putting
too much of ideas into too little text. So forgive me if this tries
your patience)

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.

>  One other thing I noted is that the send facet is, in most examples
> of Croquet Routers, used to broadcast the replicated external messages
>  headed for an TIsland (or to its contents) regardless of weather
>  the message originator has permission to invoke those methods on the
>  recipiant objects or not.

Yes. That is intentional. The router itself does not implement security
policies. It simply broadcasts the messages to all connected islands.

> 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.

>  (attached, as demostration of what I am thinking, are two of my
> classes that are still a work in progress)

I'm not sure what I'm supposed to be seeing in these changes. They seem
very incomplete and without comments it is hard to get a grasp on them.


Cheers,
   - Andreas

On 11/11/2007, Andreas Raab <[hidden email]> 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?
Isnt the mapping from an facet ID to facets local to each Router Client? Aah, I got the implication that the router would do implement simplistic
security policies by mapping <the stuff encoded in TMessageData
objectId and selector>
onto router facets.
An implication that turned out to be a mistake of my part.
> > 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)

> >  (attached, as demostration of what I am thinking, are two of my
> > classes that are still a work in progress)
>
> I'm not sure what I'm supposed to be seeing in these changes. They seem
> very incomplete and without comments it is hard to get a grasp on them.
>
Indeed they are very incomplete because these are just in the early stages.
I should rather have omitted them instead of cluttering the discussion
with them.

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.
- Zarutian

Baldur Johannsson wrote:
> On 11/11/2007, Andreas Raab <[hidden email]> 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.

>>> 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".

> 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.

Cheers,
   - Andreas

On 11/11/2007, Andreas Raab <[hidden email]> wrote: Hmm... but the router checks if an TMessageRouterClient has that facet
in its facet dictionary, yes? 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 ;-)

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:

Baldur Johannsson wrote:
I see. I had this originally in mind but the problem with the approach
was that I needed to have at least a rudimentary feel for the kind of
messages to send (otherwise how do you know what receiver and what
selector to map) and when I wrote it I had zero experience with writing
this kind of code ;-) I still don't don't feel like this is sufficiently
understood although we do of course have some samples to look at (the
candidate list is basically all the external senders of #future). I'm
interesting in seeing what you can come up with - this area certainly
has room for improvement and cutting down on the message size by have
receiver x selector implicit in the facet could be a major gain.

Let me know when you have something that's worthwhile trying out.

Cheers,
   - Andreas