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

Tobias Hunger <[email protected]> Mon, 19 Jan 2004 13:47:02 +0100
Newsgroups gmane.comp.video.fresco.devel
Message-ID <[email protected]>
Nathaniel Smith <[email protected]> wrote:

<snip>

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

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

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

> 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;-)

<snip>

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?

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?

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?

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?



Independent of this:

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

-- 
Gruss,
Tobias

------------------------------------------------------------
Tobias Hunger           The box said: 'Windows 95 or better'
[email protected]                      So I installed Linux.
------------------------------------------------------------
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAC9HGv0FZW3NyoqURAsDFAJ9MxlM76gzvgRRjvEPlmjjdGuAfSACgj+EJ
kkirpkbdjvL6Rb5l/iwnIOo=
=l5D2
-----END PGP SIGNATURE-----