Request for HUP-ing Unix clients

Garance A Drosehn (gad@eclipse.its.rpi.edu)
Tue, 27 May 97 01:55:45 -0400


The deschall project is an interesting example of a distributed
application, and I'm toying with the idea of running it on more of
our Unix machines whenever a machine has no real user logged onto
it. I pretty much have to blow the process away as soon as someone
does log in, simply because these machines were bought for the
people who are logging in, and were not bought to run deschall
clients. So, when someone logs in I send a HUP signal to the
deschall client, and it politely goes away.

On some of the SGI's I tested this on, the client picks up 2^29
key-pairs per test-block, and then takes over an hour to test all
of them. I can't help feeling "what a waste!" whenever I have to
stop a client. This is particularly true if I find a bug in my
RPI-specific wrapper, and thus have to kill the client on 25-30
workstations all at once just to restart it on all of them about
10 seconds later.

Initially I was going to suggest that the unix client support an
option to set the maximum time-period. The workstations here at
RPI range quite a bit in how rapidly they can check keys, so I
don't want to set a specific maximum number of key-pairs. I just
want the client to limit itself so it'll never try to do more than
(say) 15-minutes worth of work.

However, if you did implement this then it would increase the load
on the server, which is probably not a good thing. So, instead,
I'd like to suggest the following for unix clients:

If the client receives a HUP signal, then stop all calculations of
new keys, but report back to the server with the progress made on
the current block. Maybe just report the progress to the nearest
complete block of 2^22 or 2^24 keys, so you don't end up with
absurdly small lots of numbers. At the very least, report back to
the server that this client is shutting down immediately, so the
server can assume this client will never return a reply for the
current block of keys.

I imagine this still implies a bit of work, and will increase the
load on the server a bit (and maybe some extensions to the protocol).
Still, I think do it'd make a significant difference when I'm about
to shutdown 25-30 deschall clients, each of which is about 5 minutes
away from reporting on 2^29 or 2^30 key-pairs...

An additional possibility is to suport a signal to tell the client
to shut down as soon as it finishes the current set of keys (without
picking up a new set). Perhaps make base this on the USR1 signal.
This would be useful in different situations than the HUP-based
option, and it would not require any protocol changes, or put any
additional load on the server.

I realize a lot of effort has been put into this deschall project
already, so I'm only offering these as suggestions that the client
developers might want to consider. At the very least, I wanted to
have this included in the email archives, in case someone looks at
deschall for good ideas on distributed programming projects (and I
do expect that will happen, given the magnitude of this project).

Cheerio. :-)

---
Garance Alistair Drosehn     =     gad@eclipse.its.rpi.edu
Senior Systems Programmer        (MIME & NeXTmail capable)
Rensselaer Polytechnic Institute;           Troy NY    USA