[Fresco-devel] Caprice CXX
Tobias Hunger <[email protected]> Thu, 10 Jun 2004 20:53:35 +0200
| Newsgroups | gmane.comp.video.fresco.devel |
|---|---|
| Message-ID | <[email protected]> |
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Now that my mail connectivity to the fresco.org domain is back up again I n= eed=20 to write up some mail about stuff I have been talking about on IRC for some= =20 days now;-). Some of you might know this text already... you might want to= =20 read on anyway as I updated it in places. I played with the ideas from Nathaniel (see ReFresco postings to this list from Feb. 2004) about a capability based message passing system and came up with some C++ code. I further included Nathaniel's experimental python code for comparison. The Idea: =2D -------------- =46or those too lazy to refer back to Nathaniel's mails: To address an object we are using Capabilities (Caps for short). Those are= =20 128bit random numbers. You can't guess those since the existing ones are=20 basically hiding in a vast number space (2^128 is a *HUGE* number!). This=20 basically guarantees that nobody can accidentally communicate with an objec= t=20 he was not told how to reach (by telling him the Cap of the object). Nathaniel suggested a connection based Hub-Spoke model. The Hub of course i= s=20 the Fresco display server, the clients are at the end of the spokes. They m= ay=20 send each other messages via the hub. While Nathaniel is suggesting a message based communication protocol my C++= =20 implementation is using a more TCP-ish approach: Each message is split up=20 into packets that pass down Connections. At the end of each Connection is a= =20 Router (one per address space). That object will examine the Packet's heade= r=20 for the recipient's Cap and look that up in his RouterTable, finding out=20 which Connection to pass this Packet to. One special Connection called ObjectAdapter accepts messages from an=20 associated object, turns those into a (stream of) Packets and passes those = on=20 to a Router. The ObjectAdapter further acts as a Connection and accepts=20 Packets send to it by the router, turning the Packets back into messages th= at=20 it passes on (via a function call) to its associated object. You can find a UML diagram of my C++ implementation here: http://www.fresco.org/~tobias/caprice_diagram.pdf Status: =2D -------- BOTH VERSIONS (Nathaniel's Python one and mine in C++) ARE ONLY MEANT TO HA= SH=20 OUT IDEAS. They are not functional and in no way ready for use. Mine manages to pass messages between two objects in the same address space= =20 now. With that breakthrough I decided to show it to all of you for some=20 comments:-) =46eatures of the C++ version: =2D ----------------------------- Some tests can be run if you have Fresco-Test. Limitations of the C++ version: =2D -------------------------------- * Some of the tests leak memory. The leak is in the test code, so I didn't bother to fix this yet. * Only objects in the same address space can communicate. Network code is to be added next. * Capability creation drains entropy pool at an astonishing pace. Adding so= me pseudo random number generator like the one in the python code is require= d. This should significantly speed things up as well. * Authorisation, etc. which might be required to get an initial (set of) Caps is not implemented: This will happen in some Object(s) on top of the message passing code you can see so far. * Propagation of existing Caps between Routers (in a secure way). The RouterTable returns a default Connection for all unknown Objects. So forwarding Packets to the hub router should work now. That will need to g= et informed about all known Caps somehow... that part still needs to be work= ed out;-) I do not want to simply push all generated Caps into the hub router. That way someone getting access to the hub routers data would have instant access to all existing objects and the hub router might get flooded with fake Caps by a malicious client (50 Caps plus Connection are about 1KiB of data the RouterTable will need to hold). Requirements: =2D -------------- You will need Prague (from the Fresco tree) to build caprice-cxx. In additi= on =46resco-Test will be required to run the tests (you will need a new versio= n=20 from CVS of the latter). ToDo: =2D ------ In addition to fixing the limitations: * Add a test that gives an estimation on the randomness of the generated Ca= ps. The whole notion of security depends on that, so we should test it thoroughly! Please comment. P.S.: The code is here: http://www.fresco.org/~tobias/caprice-r345.tar.bz2 P.P.S.: Nathaniel: It would be great if you could put a HTML-ified version = of=20 your mails up on our website (or at least the Wiki). =2D --=20 Gruss, Tobias =2D ------------------------------------------------------------ Tobias Hunger The box said: 'Windows 95 or better' [email protected] So I installed Linux. =2D ------------------------------------------------------------ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAyK4zv0FZW3NyoqURAi1oAJ9JYsLGeQ2r3Gp0zKzwX4Yen6F26QCghac0 G1w2IlbbCaf1HSTOdRcNyDk=3D =3DqTSl =2D----END PGP SIGNATURE-----