Re: [Fresco-devel] [ReFresco 03] Proposed network architecture overview

On Mon, Jan 19, 2004 at 01:47:02PM +0100, Tobias Hunger wrote:
> Nathaniel Smith <[email protected]> wrote:
> > Messages also contain a second cap, to which any return values or
> > errors are to be reported.  If a program does not wish to receive any
> > response, this cap should be set to all zeroes; this is a special
> > address whose object is the equivalent of /dev/null -- it will eat any
> > messages sent to it and never do anything with them.  This is the only
> > mechanism for matching requests with replies; we don't have sequence
> > numbers or anything like that, because replies need to not be
> > forgeable; only the object to whom we send the request should have the
> > capability to reply to it.
> 
> In a multithreaded environment one cap (object) may have multiple lending
> calls into other caps (maybe even into the same cap). How does it match up
> the replies it receives to the messages send out?

Objects don't send messages, programs send messages.  If you want to
send two messages, you need to be able to distinguish the replies.
(Well, sometimes you don't care about distinguishing the replies, but
that's the easier case, so don't worry about it.)  So there's a
fundamental question: you get a message back that claims to be a
reply; how do you know that it's telling the truth?

This is exactly the same problem that we're already solving with caps.
So, we apply exactly the same solution.  This does mean that you have
to generate a cap for each call, but that's a fundamental requirement,
not a problem with the design.

> I guess you intend to handle this situation with the promises described
> later?

Not sure what you mean.  I think promises orthogonal to this...?

> Once you know a cap you can answer several times or do other nasty things,
> can't you?

Yes.  It's not clear what "nasty" means here, anyway; I can imagine
scenarios where getting multiple replies is desireable.  (Maybe I sent
a message to a proxy object that broadcasts to lots of objects, and I
want to collect all the responses.)

> > Aside from messages to objects, clients can inform the server that
> > they now implement cap FOO, or that they no longer implement cap BAR;
> > this is how the server's master table is maintained.  If two clients
> > both attempt to register the same cap, whichever client does so first
> > wins, and the other's attempt is ignored.
> 
> Can this mechanism get abused to probe for existing caps? (OK, it is not
> likely to hit one in a 128Bit space;-)

Well, it depends on exactly how the server handles that case.  One
option is to just drop the request on the floor.  Another is to decide
that this means the client is being naughty, and simply kill it.
Neither of these would allow probing.  A third option is to send back
an error message, which would work as a way to probe, but just trying
to send a message will also usually work as a way to probe, so I don't
know that I'm terribly worried.

> Setting up some sockets and writing up a capability system sounds like it
> can be done in a reasonable time. How about the higher level issues though:
> How to marshal objects? How to define interfaces? Will there be some IDL-ish
> language? Who will write a tool like omniidl?

Actually defining an object marshalling protocol is pretty easy; I
think we just steal ICE's with some small modifications.  (It's
documented in the ICE manual, which I linked to in ReFresco2, I
think.)

Defining interfaces is trickier.  I think Stefan has a program around
somewhere that lets you read several existing interface languages
(e.g., OMG IDL, C++ header files) and then write out stuff based on
them using Python code? ;-) One option would be to not get all anal
about separate IDL files, and let people just write interfaces in C++
or Python or whatever, and then use Synopsis to generate glue code for
other languages.  (An interesting side effect would be that one could
have a really snazzy language mapping; if I write a servant method
with signature
   do_something(std::list foo)
then the mapping would generate code to unmarshal a sequence into a
linked list, and if I give it signature
   do_something(std::vector foo)
then it generates code to unmarshal a sequence into a vector.  I dunno
how important this truly is, though.)

Alternatively, we could do the traditional thing and make up a little
IDL-y language.  I have a framework for writing recursive descent
parsers in Python sitting around here, just waiting for someone to use
it...

> How will the C++ interface look like? Are you suggesting to hide the networking
> behind some pointerish interface like CORBA does it?  Or do you suggest not to
> hide the message-passing using some functions like "send_message(recv, send,
> octets)" and "recv_message(send)" to show when communication is going on?

I think a low level interface should be available, but yeah, there
should be convenience mappings onto language specific idioms.

> How about multiple language support? I think C++ and Python are a must,
> Java, Perl, maybe Ruby, would be nice to have, others not that important.
> Who is going to work on that?

I was thinking I/we'd prototype in Python, and then port to C++.  That
gives us two implementations, and for the most important languages;
that's enough to get started with.

> Fresco needs a working communication infrastructure, a switch from CORBA
> to anything else will result in a huge parts needing to get rewritten.
> So, if we decide to follow Nathaniel's suggestion to move away from CORBA,
> how can we minimize the "downtime" for Fresco?

Well, by writing the communication infrastructure, I suppose :-).  One
point of writing up documents was so I wouldn't be the only one able
to see what this code was trying to accomplish, so other people could
join in.  And it's not like Fresco has a lot of uptime right now to
interrupt...

But yeah, getting something working soon is definitely a good idea.

> Independent of this:
> 
> I think we should link to Nathaniel's documents on the website and document
> why we decided this way or that.

Agreed.

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."

This email may be read aloud.