Re: Improving object mobility within the Hurd

[Carl Fredrik Hammar]

Hi,

On Sat, Jan 10, 2009 at 08:50:28AM +0100, olafBuddenhagen@gmx.net wrote:
> > I have dropped the channel concept and have opted to focus on
> > arbitrary Hurd objects.  I've adopted term ``mobile object'' from
> > similar frameworks such as Java's RMI, where it is usually used when
> > the transfer may load the objects' required code base.  It's short and
> > sweet.
> 
> I don't know the term from other contexts, but indeed it seems pretty
> nice :-)

Perhaps I should add that the context in question is distributed systems.
The main difference from what I'm doing is that they usually assume
communication over network.

> > I've split the project into three main parts: improving authority
> > verification, improving code transfer and an object system that can
> > emulate Hurd objects.  This because while they reinforce each-other in
> > respect to mobility, they are orthogonal and might be useful in other
> > areas.
> 
> I must admit that I don't see it (yet)... Can you please explain how you
> imagine these to be useful in different contexts?

The first two parts could be used to improve mobility in libstore
directly, without porting stores to the new object system.  It could
also be useful for alternative mobility framework, which might want to
use a tailored object system.  Most likely they might consider my object
system overkill if they don't actually want to emulate Hurd objects.

The object system itself can be used in contexts outside of mobility.
For instance, libstores mechanism for specifying stores on the command
line.  Thus the process don't need other translators to provide the store
for it (using it remotely or transferring it).  This is useful for the
root file system translator during boot, e.g. if the file system is on
some RAID configuration.

The command line mechanism can ignore many of the issues that arise in
mobility, e.g. consistency between different copies.  Looser restrictions
means a larger class of objects can be implemented.

> > By ``code transfer'' I mean how the code base of an object is
> > specified so it can be found and loaded by the receiver.  The receiver
> > must also be able to determine if it can trust the code.  Again
> > chroots and sub-Hurds makes this more fun, e.g. what if the two
> > parties use the same name for different code bases?
> 
> As I said before, I believe it is best for the server to provide the
> object code directly (by an RPC), rather than letting the client look it
> up somewhere. This would entirely remove the naming problem, along with
> some others.

This is one of the methods I'm considering, i.e. ``naming'' the code with
a port to the .so file.  I do not have high hopes for this method though,
mostly because it's hard for the recipient to determine if it can trust
the code.  More on this in later mails.

> Regarding trust, I think this is complementary to authority. Probably
> they should be considered together.

Really?  Being allowed to do something is quite distinct from trusting
that it really does what it claims to do IMHO.

> > Interfaces that aren't possible through RPCs that utilize the fact
> > that the receiver is in the same address space should also be
> > possible, though naturally these can't be used through a wrapper port.
> 
> That means the objects can't migrate in a transparent fashion. What use
> cases do you see for non-transparent object migration?...

I thought you'd be cheering this feature. It allows for interfaces which
don't have to assume that the object is remote, e.g. it can use pointers,
globals, etc.

This is done at the cost of transparency.  I don't know a particular use
case where it would be worth losing it, I figure it's mostly a question
of not introducing any artificial limitations.

> > Lastly, these parts will be tied together into a library, which I
> > think I'll call ``libmob''.
> 
> LOL... Is the pun intended? :-) (herd vs. mob)

It is now!  ;-)

I was mostly associating it with its use in MUDs for monsters which can
roam from room to room, where it's short for Mobile OBject.  I like the
idea of little monsters running through the translators by themselves,
though technically this would be a mobile agent, not an object.

It is interesting to note that ``mob'' is derived from ``mobile vulgus'',
which is Latin for ``the easily movable crowd''.  (Thanks goes to
Wikipedia.)  So its also associated with mobility.

> > And I'll do some simple performance benchmarks, which should show when
> > using mobile objects instead of IPC is a good idea if at all.  This
> > will hopefully give a substantial result without committing myself to
> > find concrete use case.  Though optimization is probably one of
> > mobility's least interesting possibilities, it's the one that
> > instantly springs to mind.
> 
> What other possibilities do you see?

Maybe my statement was a bit premature, as currently my thoughts on this
are a bit vague.  But I have high hopes  :-)

One idea I have been toying with is using it for alleviating the problem
of resource accountability.  I.e. making the client load an object which
manages state needed by the server.  Consider an object that maintains
the current position within a file, then the translator wouldn't need
to maintain such session state.

Since this is an idea in the making, there are many issues I haven't
worked out.  But I don't have time to spend on it at the moment.

I'm also sure there are interesting use cases that skip the transparency
requirement.  Though I haven't come up with anyone yet.

Regards,
  Fredrik