I did a distributed scheme for something else that had two levels, a master and a group of slaves. Only the slaves talked to the master. For this effort I think a variation of the idea would be better. Have all of the brutes contact the master, who will, in the first transaction assign them to the next slave in a round-robin fashion. Then all of the transactions from that point would take place between the brute and the slave:) (Sounds kind of like Conan or the Princess Bride.) The slaves would each be delegated large chunks of the keyspace, but not keyspace/numslaves. Maybe 1/16th or something like that, and could ask for more when their space was depleted. Periodically, perhaps when requesting more key space, and/or when a timer pops, the slaves could report results. What I mean is that every so often they'd report even if they didn't need more keyspace yet, iff they had any new stats to report. The nice thing here is that the work of the master and of the slaves is almost the same. The slaves don't have to do the initial assignment of slave, and the master doesn't have to report results, but everything else is the same. With careful design you could use the same daemon for both with a command line argument to tell it if it was the master (-m) or the slave (-s). Of course I'm sure you see that this allows you to add as many levels as you want to the hierarchy. A slave doesn't care whether a slave or a brute talks to it. The only thing that changes with the levels is the max size of an allocated chunk. For each daemon it would be nice to have the minimum, maximum and default chunk size configurable. The master might have all three the same, since it would be expected to talk only to slaves. That doesn't mean you couldn't get more than, (for example), 16th of the keyspace to work on. It just means that you'd have to make more than one request. You could make the slave software available as well, and a site with many machines could have only the slave contact the master to get assigned a slave to talk to, and could configure all of their brutes to talk to their own slave. Software like this is easy to write, (and fun), and we should go for it:) Of course I do everything like this in C++, but I suppose perl would be the most portable. It's a shame it's so aethestically displeasing to the eye. perl's never a pleasant read. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick@verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/
I did a distributed scheme for something else that had two levels, a master and a group of slaves. Only the slaves talked to the master. For this effort I think a variation of the idea would be better. Have all of the brutes contact the master, who will, in the first transaction assign them to the next slave in a round-robin fashion.
Well, imagine my suprise .... [[ reference to ISIRTA ]] One of the things that the latest brloop does is make a call to the master server asking for a list of servers to contact :-)) Note that it is a list, and it tries them in order (all A RRs).
Then all of the transactions from that point would take place between the brute and the slave:)
Currently just all the "allocate" transactions -- I haven't written my ACK reflector yet, so all ACKs go direct th the ACK master.
The slaves would each be delegated large chunks of the keyspace,
No -- the slaves will not "be delegated" (as in pre-assigned address space), they will just ask the master for it as they need it. Sure, the'll do it in reasonable sized chunks, but not (2**16)/16 ....
but not keyspace/numslaves. Maybe 1/16th or something like that, and could ask for more when their space was depleted. Periodically, perhaps when requesting more key space, and/or when a timer pops, the slaves could report results.
Nah - results still go direct pro tem.
What I mean is that every so often they'd report even if they didn't need more keyspace yet, iff they had any new stats to report.
Sure.
The nice thing here is that the work of the master and of the slaves is almost the same.i
You got it !
The slaves don't have to do the initial assignment of slave, (slave -> slaves I assume)
and the master doesn't have to report results, but everything else is the same.
Yup -- code sharing !
With careful design you could use the same daemon for both with a command line argument to tell it if it was the master (-m) or the slave (-s).
Well, not even that ! The slaves don't have the config file with the key info in it ...
Of course I'm sure you see that this allows you to add as many levels as you want to the hierarchy.
Indeed. BUT .... These cache servers are asking for non trivial amounts of keyspace. As such there should not be *too* many, and then need to be "managed" ... If one crashes, the logs need to be scanned to see how to restart it (so that it starts by doling out the segments that it had no sub-doled to its clients).
A slave doesn't care whether a slave or a brute talks to it.
Indeed -- that's how it was designed ... However, note that with big cache servers (as opposed to Local CPU Farm servers where all clients are the same "ID") reports of sub-allocation have to be passed back to the root :-(
You could make the slave software available as well, and a site with many machines could have only the slave contact the master to get assigned a slave to talk to, and could configure all of their brutes to talk to their own slave.
Indeed -- the Local CPU Farm cache server is just about ready for ALPHA testers
Software like this is easy to write, (and fun), and we should go for it:)
Done ...
Of course I do everything like this in C++, but I suppose perl would be the most portable. It's a shame it's so aethestically displeasing to the eye.
Yeah -- but being based on C, C++ didn't stand much chance ...
perl's never a pleasant read.
... but better than C++ -- sure. PS1: PERL gurus: Anyone know how to test whether there is input waiting on a file handle ? I know about seeing if there is data waiting for the next sysread type read, but not on the next <SERVE> type read. Ideas ? PS2: PERL gurus: I fixed the SGI Challenge problem by HACKing it -- as I thought it was a probleb with stdio in and out on the same socket. The perl mand page warns: If your stdio requires an seek or eof between reads and writes on a particular stream, so does perl. (This doesn't apply to sysread() and syswrite().) so I change the one "print SERVE" line to a "syswrite(SERVE" and that fixed it. However, does anyone know the "correct" way to use stdio for I/O? PS3: I'd like to get the raw date in brloop (a sh script). In perl I'd just use "time", and I can't see a way to get "date +" to yield the raw time. I could use "date=`perl -e 'print time'`" but that seems OTT, and perl may not be on teh users PATH. Any suggestions ?
In message <"swan.cl.cam.:216660:950828181616"@cl.cam.ac.uk>, Piete Brooks writ [...]
PS1: PERL gurus: Anyone know how to test whether there is input waiting on a file handle ? I know about seeing if there is data waiting for the next sysread type read, but not on the next <SERVE> type read. Ideas ?
I don't think there is one. I would just use select() on FD, and then a subrutine much like this: sub syswrite { local($FH, $buf) = @_; local($len, $offset, $wlen) = (length($buf), 0, 0); while($len) { $wlen = syswrite($FH, $buf, $len, $offset); die "Bad write $FH: $!" if (!defined($FH)); $offset += $len; $len -= $wlen; } } Actually if you can use perl5 for the server (I assume this is the server code you are worrying about) I have code that deals with I/O from multiple sockets at once and drives an independant state machine for each socket.
PS2: PERL gurus: I fixed the SGI Challenge problem by HACKing it -- as I thought it was a probleb with stdio in and out on the same socket. The perl mand page warns: If your stdio requires an seek or eof between reads and writes on a particular stream, so does perl. (This doesn't apply to sysread() and syswrite().) so I change the one "print SERVE" line to a "syswrite(SERVE" and that fixed it. However, does anyone know the "correct" way to use stdio for I/ O?
For bi-directional pipes I tend to use sysread/syswrite anyway, but you could just sprinkle "seek(SERVE, 0, 1)" liberally through the code.
PS3: I'd like to get the raw date in brloop (a sh script). In perl I'd just use "time", and I can't see a way to get "date +" to yield the raw time. I could use "date=`perl -e 'print time'`" but that seems OTT, and perl may not be on teh users PATH. Any suggestions ?
"date '+%s'" does it under BSDI, but I'm not sure how portable it is.
In message <RAA13233.199508282105@garotte.va.pubnix.com>, "Josh M. Osborne" wri tes: [...]
sub syswrite { [...]
So sorry. I gave out the wrong code. Let me try again: sub sysreadln { local($FH) = @_; local($len, $line, $offset) = (0, "", 0); while("\n" ne substr($line, $offset-1, 1)) { $len = sysread($FH, $line, 1, $offset); die "Bad read from $FH: $!" if (!defined($len)); $offset += $len; } return $line; } There. That should help. (yes, this is slow since it asks the OS for a single byte at a time, but in practice it isn't too bad - I use it for small tasks and my multi-stream state-machine monster for the rest)
participants (3)
-
Josh M. Osborne -
patrick＠Verity.COM -
Piete Brooks