JeffJournal

Had some interesting thoughts about minime yesterday while driving up from Louisville:

• Currently, there are two kinds of endpoints for conduits: unix sockets and TCP sockets. How about creating a third kind -- an internal endpoint. This would allow modules within a single minime to be able to talk to each other across the already-existing conduit abstraction.

• The minime boot service should be a module. I think that this has been stated before, but the ramifications of this really only occurred to me yesterday. The core minimed will be really dumb, meaning that it only knows how to:

  • launch itself

  • listen for messages (on three different fronts)

  • make connections (on any of the three fronts), which will include authentication and/or encryption

  • receive messages on these connections and give them to the module that will handle them, or handle them itself (e.g., "shutdown" messages)

  • shut itself down in an orderly fashion
    

• Astute readers will realize that the previous bullet precludes routing messages across multiple minimed's -- messages always go from one minimed to another, and no further. No problem -- have a "router" module in the minimed that handles this kind of message passing (for non-fully-connected networks, for example) to get from point A to point B -- a la nsend in LAM (although implemented completely differently).

• Hence, we're looking at a small minimed with probably the following core set of modules:

  • network minime boot: ability to launch minimed's on other hosts and build the minime mesh. Currently only planned to execute once -- not add/delete from the mesh.

  • init.d minime boot: ability to launch minimed at boot up time and either look around to see who else is up and join a mesh (this will be hard) or have a pre-defined mesh (a la a config file, which is much easier) that indicates what other nodes should exist, and just join that mesg. This may be repeated multiple times to add/delete nodes as nodes go up and down. Although I'm defining this to be in the core, I'll likely add this part last.

  • message router: transparently move user-level messages from point A to point B through some route in the minimed mesh. This will be a higher level of messages that conduits/self-executing messages. High-priority messages should use a "c2c"-like routing (which may still involve multiple hops -- i.e., from gateway to gateway, such as A->gateway1->gateway2->B -- but not have to go all the way through the mesh), where low priority messages can go through the minime mesh (i.e., potentially more hops).

  • group operations: perform an operation (or set of operations?) on some group of nodes in the minime mesh, and collate the results in a scalable fashion (most likely using some kind of tree over the minime mesh).

  • uptime: report uptime and some other useful stats (first real useful tool and proof of concept). Will probably use the group operations module to get the uptime for all nodes in a cluster, for example.

  • fork/exec: run arbitrary user programs.
    

  Obvious security questions have to be addressed, such as only allowing specified authentications to do certain actions such as shut down, run arbitrary programs, etc., etc.