Good, spirited discussion by all! But because I'm not feeling like I've pulled the answer(s) from you, I'll clarify:
The model I'm writing will, indeed, keep version information regarding what each client has, and what it needs. I'll just purge based on % HDD space left, taken, etc. Peter is right in that I've thought this through, and I do not want to store everything on a continually updating client install base. I base this on the kind of work being requested. Among the many categories of work, there are/is also that work which involves passing about configuration files, re-establishing closest (fastest) link (and other methods for reducing server communication directly). There are also cases where there are dependencies for work, and each client needs to be able to pass on communication between clients for this and other reasons. Overall, the vast majority of time the result of the work will be less than 1kb of data. The client may take in a lot to come up with that answer, and this is why a grid, or distribution, is a good idea (among others). These problems are more computational than I/O bound. There are also cases where I'll need the client to update the data that it is using for certian kinds of lookup/classification work. There will be a dictionary (to use an example) with words and a value, say. Two things happen: 1. the word is looked up (has to exist), and 2. the value for the word needs to be returned. While suggestions involving 100% MS from end-to-end are interesting, my back end will definitely be J2EE/EJB3. Each client will request work, and submit the results, via a call to a simple web service. This conversation, therefore, is solely concerning the clients. So I come up with, say, a dll in VS and I "upload" it to a WS on the server along with the entry point. Putting issues of versions needed aside, when work requiring this dll is encountered, the dll is copied to the "consumer" of the WS, along with a manifest, metadata, etc.- probably as a single zip archive to save hassle, is the way I'm thinking. Who needs to troubleshoot WSDL when you don't have to? The client, which is just a bare bones shell (no pun) receives the package and unzips it. It reads the standard format manifest and decides it must call (run) the dll at the entry point, passing it some work parameters that were in the metadata, or a place pointed to by the metadata. All of this is no problem to/for me at all. It is the next step that I start feeling a little lost at. I want no more than to: -Drop the package's contents into a folder on the client unzipped. -My client will read a manifest (standard filenames, all) and verify the contents exist. -The client will read the instructions, which are nothing more than an entry point to the dll (in this example), pass it any arguments specified, and off it goes. -Now because I wrote it, I ensured that there were ways to both ask the dll, and have the dll submit, a progress/status/pending state so that the server can ask, or the client can periodically tel lthe server "Hey, I'm still busy with job 123". (this interprocess communication between running assemblies/programs (all .NET) is at the heart of the question to this esteemed group, the other 1/2 is calling/running that copied/downloaded dll, exe, etc.) - The dll tells the client it is done, and hands off the results of the work. The client turns around and sends the results: "I'm done with job 123, and the result is 42". - That is it. So you can see I'm asking this group the best way(s) to: 1. Start a program asynchronously (or at the least non-blocking) from within a .NET program, and 2. How best to facilitate communication between the 'host' nad 'guest', to use VM parlance. I hope this helps! I appreciate the discussion, though, as it is. Don't get me wrong! I just hope we also cover these points! :) TIA! pat :)
