DIS: world wide system identifiers
Wed, 2 Nov 1994 19:04:19 -0800 (PST)
On Thu, 3 Nov 1994, Francois-Rene Rideau wrote:
> There are problems about a distributed system:
> - we must ensure that object numbering is unique and secure.
> This means a large object identifier size (64 to 128 bits typically).
> How will that be handled ?
> - now, and particularly if objects migrate, how to route efficiently a
> message from source to destination object ?
> for example, let's assume I was given some old (but valid) object
> handle; by the time ellapsed, the corresponding object may be anywhere
> in the world (if it still exists !). How will the system locate it ?
> Firstly, this should be transparent to the user; this is strictly a
> system implementor problem, which should be solved with maximal efficiency.
> What I propose is having host-dependent pointers to represent objects.
> Local objects (present on the same host) or faithfully represented by these
> pointers as usual, while remote objects are represented as a pointer to a
> record containing the full system-wide identifier for the object. Exported
> objects reciprocally are pointed at by a record containing the corresponding
> identifier. The system may also cache some route and migration information
> together with object identifiers.
> This allows very quick access to local objects, and equally easy (though
> slower) access to remote ones.
>From the programmers point of view (in my paradigm at least) tool boxes
store data and the code to manipulate that data. In order to get
something you call the tool box by its name (potentially a big fat
number), and potentially the slowest part of the operation, from there
everything is local. The arguments passed between tool boxes should be
as high level as possible, so as to minimize the number agents passing
The "kernel" manages moving agents whether locally or to other kernels.
Although the routing algorithm will be outside of the kernel.
I guess what I really mean, is that an "object" to me is data plus the
code to manipulate it. I don't see inheritance as part of my low level
view of this relationship. I also don't see any need to go poking around
in someone elses data with a handle (it wouldn't be nice). You access it
through a name. To minimize the possibility of two people having the
same name, use a bigger number (name).
In my model the name is variable between 1 and 127 bytes. That should
provide a pretty good range. If you want even more protection, add some
kind of checking function to the tool box gate. Slower again, but
safer. I don't want to make these compromises though, I want to leave
that up to the implementor of the HLL.
In another recent post about agent movement I mentioned the kernel
caching information about tool boxes references in calling tool boxes.
I think we are cranking out ideas again, don't forget the Friday
deadline. I'd hate to have to redraw my line in the sand!