Hi all, I have been thinking about the implementation of a dll cache, and am starting to realise a few of the constraints that are necessary for a generic solution for Alchemi (i.e., not just our potential situation where all executors would be dedicated servers...). One of the concerns is security - how can we guarantee that a dll has not been tampered with? I am not sure this is a big issue but wanted to see if anyone else had any thoughts. My original impression was that it would be a problem, but the executor either executes as the user (who needs the password to connect to the grid, so we can assume is trustworthy), or as system, who we can also assume is trustworthy. There are very probably nuances to Windows security that I am missing however... (my *nix security knowledge is much stronger...). The next is speed. Clearly, a dll cache has an interest for both reducing network traffic and speed. What is the best we are reasonably going to get? It seems clear that some sort of storage mechanism is necessary. But do we go for a (embedded) DB? Do we need for the executor to remember across restarts? If we have a restart and the executor has to reflect all the dlls in his cache to get what he has got... if we can use a db (like db4o, for example), then this info can be stored. But is this a big deal? Should we keep the dlls loaded? Will this work with the appdomains? We would have a potential situation where 5 meg+ of dlls (yes, they are definitely doing cleanup, and no, I didn't write any of the code!) would be needed for each thread, so even copying locally is something to be avoided. I definitely think that the Manager should store the dlls in the DB.
Anyway, my first idea was the following, which would probably require reimplementing the relation between ModuleDependency and EmbeddedFileDependency as one of has-a instead of is-a (sorry, I forget the terms :-)). 1. application starts, basically as is. 2. application adds module dependencies and starts. 3. In GApplication Init(), application says "My app needs this". 4. Manager replies with the modules he needs. 5. app loads file dependencies and sends off (a couple of extra lines in init()). 6. Manager does his usual thing. 7. Manager schedules a thread on an executor, sending the new module dependencies. 8. Executor replies with a "well you had better send x, y, z then!". 9. Manager loads the EmbeddedFileDependency's that the executor needs in the module dependencies. Does this sound like the best way to go? An OK way to go? Any ideas or abuse most appreciated. Cheers Anton -- echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc This will help you for 99.9% of your problems ... ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Alchemi-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-developers
