On Thu, Dec 06, 2007 at 05:50:04PM +0100, Karsten Otto wrote: > Why all the indirections? Wouldn't it be enough to put one or more > lines of the kind > <host addr="interreality.org" port="4231" protocol="vip"/> > (port and protocol being opzional) into the site replica document? It > *is* a signed document already, isn't it? > So if you already got one from somewhere, you only need to check the > signature once. > You would omit this on an "abstract site" like your interface > definitions, and imply that the user should choose randomly from the > given hosts when establishing a connection.
I haven't implemented this yet, so I haven't committed to a particular
way of doing it. The main reason for having hosts identified with
distinct ids is so that there is an unambigous identifier without having
to get into the ambigities of comparing hostnames and IP addresses. So
for example, if a host is hosting multiple sites, you don't make
separate connections to the same host for each site. I'm also
considering that VOS messages might be sent over multiple different
transports, such as TCP/VIP, or HTTP/XML-RPC, or XMPP, or email, etc.
So the host->network address binding is very fluid.
That said, where available, it does make sense to bundle site->host and
host->network address bindings in the same document, for convenience.
> Well, these are two separate things really, aren't they? The first ist
> a matter of key management and distribution, including trust in the
> fact that a key really belongs to the person claiming to own it. I
> don't really see a need to invent something new here, people may
> either use certification hierarchies (X.509) or grassroots cross-
> signing (GPG) at their choice.
Well, what I am fundamentally trying to acomplish with VOS is the
ability to publish an object store identified using my public key and
using the signing ability granted by knowing the private key to control
who can issue authorized updates associated with that site. The only
guarantee that clients have on receiving the data is that it was
authorized by the entity holding the corresponding private key.
You're right, particularly when not using human-readable names, there is
a significant danger of social engineering attacks -- you don't need to
spoof the actual site, you just need to fool someone into thinking that
your site is the authentic one. Some kind of certificate PKI system
will be necessary. I haven't studied it enough to have a design for it
in VOS yet (whether leveraging an existing system, or coming up with
something ourselves).
I picked elliptic curve cryptography due to fact that the keys are very
short (relative to RSA) which facilitates using the complete public key
as the primary identifier. At the moment I'm using 128 bit ECC keys,
which grants 64 bits of security. Since the public keys are used as
public identifiers (effectively GUIDs), there is a tension between
providing adequate security, and using keys which are short enough to be
used as identifiers without causing message bloat.
> Well.... do we really need names for site IDs? I mean, web pages
> don't have names either, do they? If you want, a site replica
> document could contain a line of the form
> <title>My Cool VOS Site</title>
> or similar that would show up in history bookmarks and other places
> requiring human readable labels.
The naming I am concerned with in this case is more like domain names
than individual page names. Which is tied up in the issue of
certificates, and generally associating an abstract numerical ID with
some actual individual or organization.
> Uh... by "user" I meant someone just surfing a site, or simply
> accessing existing information from some program. This kind of user
> would only ever see a bunch of FooWrappers and wonder about them...
Somebody who is "just surfing" isn't going to see that stuff anyway, any
more than you have to wade through a bunch of weird HTML tags just to
visit Google.
The "FooWrapper" terminology should just be considered an implementation
detail specific to the C++ binding. Ideally a scripting language
binding to VOS wouldn't expose that, you'd just see objects of type
"Foo". In the actual application, you just see a green "foo" ball in 3D
that you can grab and move around.
> The kind of user you seem to have in mind is actually an author or
> developer, who indeed would need to mess around with FooImpls.... so
> that "users" in the sense above can "use" them. There should be a
> distinction between the two... and the system should be more
> convenient for the user than the author. Like, how many people author
> web pages, and how many just browse them?
This doesn't make sense. The only people who are exposed to this will
be developers, and C++ developers at that.
> I was thinking in the way the established systems like CORBA or RMI
> handle this issue. They already do distinguish between author and
> user, and are optimized for use by the latter on the assumtion that
> there are more of them. I.e. if i want to access a remote Java
> object, I only need its MyType interface and an remote object
> reference. If I want to *create* a new remote object, I have to
> design the MyType interface for the users, and create an MyTypeImpl
> with the actual functionality. There is a hidden third class, a
> MyTypeStub, which is usually autogenerated, and which handles the
> marshalling for remote (or local!) invocations - this is what users
> handle, though they are never aware of it, only of the fact that they
> got a MyType object to use.
> So, how is this didfferent from what VOS s5 is supposed to do?
In your example, "MyTypeWrapper" in VOS is roughly equivalent to the
marshalling stub. The difference is that (and correct me if I am wrong
on this) the semantics of CORBA and Java RMI are that on local objects
method invocations are made directly and executed in the same thread,
and on remote objects method invocations are synchronous, blocking
calls. In VOS, my intention is for all method invocations to be
asynchronous, nonblocking calls, including calls between different
threads in the same process. As a result, *all* objects in the system
need that stub harness, even if the common case (invocations in the same
process, in the same thread) still just pass through to the underlying
concrete implementation.
Because you're calling between threads on a shared memory system, it
doesn't make sense to create "heavy" remote stubs that are managed by
the framework for objects which already exist in process. Wrappers are
not managed by the framework but are instead lightweight stack objects
that can decide whether to marshal (or not) the method call based on the
circumstances.
My concern is that if the wrapper class is named with just the name
stem, the following situation is very confusing:
{
Vobject* foo = getFoo();
delete foo;
// Oops. I think I deleted foo, but all I did was delete
// the wrapper. The underlying object is actually still there.
}
{
VobjectWrapper* foo;
delete foo;
// I know it is a wrapper, so I know I'm just deleting the wrapper
// and that the underlying object is untouched.
}
This is a little contrived, since wrappers are usually stack-allocated
(although the confusion is still there, just not as obvious), but
similar cases can be made for other common operations such as assignment
and comparison.
It's ugly, but it should be considered an artifact of the
implementation. Languages with better metaprogramming facilities (meta
object protocols, in the traditional academic sense) and hopefully
script language bindings should not require this technique.
--
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
