Wow.. that is about the same speed as a bullet fired from a (hi-speed) rifle. Hmm makes you wonder, what would happen if you try to shoot someone on the ground (from the roof of the train for example) after you've passed him.
gcdaemon is a Grid-Computing-Daemon which means that it runs in the background and serves as both
client and server for distributed computations.
A grid topology is created as running daemons either broadcast their presence on a particular subnet or by announcing themselves to already known nodes. Once a node is up and running it will receive requests for running computations from other nodes. If such a request is accepted (this must be done explicitly) a client program is downloaded from the serving node and then executed. On the other hand, if you want to run/serve a computation from your node, you launch a server session instead. This will start two things, in the following order: 1. A client provider server (multi-threaded) ready to provide client nodes with the computation client program and 2. The computation server program itself. The daemon provides both server and client programs which ports they should run on. For clients it's which
server/port to connect to, and for servers it's which port to accept connections on.
Any given node can host/serve any number of computations. That is, it can run any number of clients as well as run any number of servers - each server having it's own multi-threaded client provider. Since both client and server programs are external binary programs, there are very few (if any) limitations on what can be run via gcdaemon. In most cases the server should be multi-threaded since it may receive connections from a possibly large number of nodes, but the client probably will be single-threaded and only perform some atomic computation. For now, it is assumed that the binary program is executable on the current node but it would be easy to add some sort of binary type detection and maybe run computations through a java/c# virtual machine. This has one obvious advantage: optimized clients.
All computations are identified by their client program's md5 checksum, guaranteeing no collisions and no running multiple instances of a computation on the same node.
Security
Running unknown, binary programs on your computeris of course a great security risc. This can be dealt with in a number of different ways. The two I have thought about is sandboxing and authentication. While the first would definately be a nice complement to the second, as well as a better solution for
automated, small-scale computations, it is both harder to implement and might introduce unwanted constraints on computation programs. Authentication on the other hand, is very easy to implement but requires more user interaction for accepting computations or some ad hoc auto-accept hack. To use authentication one would simply add an authentication tag to the computation struct (which is sent with the employment request) which would hold a) the receiving node's hostname (or some other identifier) assymmetrical encrypted, and b) a (trusted) reference to the public part of the encryption key. "Screenshot:" (not doing anything exciting though)
-- DaemonController: Running on PID 10250 / Reading./gcd.conf >> Listener: Running on PID: 10252 -- DaemonController: Running on PID 10250 / Telnet mode on port 14095 -- DaemonController: accepting connection from localhost:43922 >> Listener: Received ANNOUNCEMENT from mosix2.kling.se:14097, sending ACK. >> Listener: Received ACK from mosix2.kling.se:14097.
Femtosecond Microlasers Pikofor Nanosurgery (not to be confused with the article we had on MilliFemtominute Attolasers for Decisurgery last Centimonth).
Slashdot Mirror
Or maybe im just a morbid, bored office worker :->
- Gandalf for president!
What! If that's not a spoiler I dont know what is? (ie that Middle Earth is in fact a Republic and not a Monarchy as the title suggests).
Slightly to the left. (It goes there all by itself actually, not much organizing needed)
Wow, all this talk about horses...
Consider yourself notified by the department of redundancy department.
Thanks for clearing that up.
A grid topology is created as running daemons either broadcast their presence on a particular subnet or by announcing themselves to already known nodes. Once a node is up and running it will receive requests for running computations from other nodes. If such a request is accepted (this must be done explicitly) a client program is downloaded from the serving node and then executed. On the other hand, if you want to run/serve a computation from your node, you launch a server session instead. This will start two things, in the following order: 1. A client provider server (multi-threaded) ready to provide client nodes with the computation client program and 2. The computation server program itself. The daemon provides both server and client programs which ports they should run on. For clients it's which server/port to connect to, and for servers it's which port to accept connections on.
Any given node can host/serve any number of computations. That is, it can run any number of clients as well as run any number of servers - each server having it's own multi-threaded client provider. Since both client and server programs are external binary programs, there are very few (if any) limitations on what can be run via gcdaemon. In most cases the server should be multi-threaded since it may receive connections from a possibly large number of nodes, but the client probably will be single-threaded and only perform some atomic computation. For now, it is assumed that the binary program is executable on the current node but it would be easy to add some sort of binary type detection and maybe run computations through a java/c# virtual machine. This has one obvious advantage: optimized clients.
All computations are identified by their client program's md5 checksum, guaranteeing no collisions and no running multiple instances of a computation on the same node.
Security
Running unknown, binary programs on your computeris of course a great security risc. This can be dealt with in a number of different ways. The two I have thought about is sandboxing and authentication. While the first would definately be a nice complement to the second, as well as a better solution for automated, small-scale computations, it is both harder to implement and might introduce unwanted constraints on computation programs. Authentication on the other hand, is very easy to implement but requires more user interaction for accepting computations or some ad hoc auto-accept hack. To use authentication one would simply add an authentication tag to the computation struct (which is sent with the employment request) which would hold a) the receiving node's hostname (or some other identifier) assymmetrical encrypted, and b) a (trusted) reference to the public part of the encryption key.
"Screenshot:" (not doing anything exciting though)
Femtosecond Microlasers Pikofor Nanosurgery (not to be confused with the article we had on MilliFemtominute Attolasers for Decisurgery last Centimonth).