[rc5] http://rc5.distributed.net/

Friedemann Baitinger baiti at herrenberg.netsurf.de
Mon Jun 9 20:14:50 EDT 1997

On Wed, 8 Jun 1994 estaga at ilink.nis.za wrote:

> Hello, I've just downloaded your personal proxy server (Linux) and tested it
> a bit. I've got an dialup connection (ppp) to the net and so I thought
> that a personal proxy would do the thing. Well, it works just wonderfull
> but I take my personal hdd to work so I need to turn off my pc. Isnt there
> some way of letting the proxy server shutdown and SAVE all the keys it got
> from your proxy server, and then when I run the proxy server again, it'll
> first check the keys which it already got from your server on my hdd and
> if it dosn't exist, it gets it from yours again? I hope you understand what
> I mean (:

You have a very good point here. As far as I understand the situation,
the proxy server hasn't been designed to be used by 'end users' like us.

Once, I was trying to send a 'HUP' signal in order to let the process
know that it should flush its notification buffer. Well, that worked,
but only _once_. When I tried to let it flush its buffers again later,
it just terminated. Not only did it just dump half a day worth of 
completed keys, but also, by just exiting it lost all the unchecked keys
it had already requested from the 'master'. I discussed this with Jeff
and he already found the problem. The reason why I am mentioning it
here is because I want to help you such that you don't fall into the
same pitfall.

What I do now if a reasonable number of completed keys accumulate on
my machine and I am dialed up to the net anyway probably for some
other reason is: I edit the proxyper.ini file and temporarily set the
threshold down to zero and save the file. The running proxy process
periodically checks the file and it flushes the cached key blocks
immediately. Once it's done, I reset the threshold value to its previous

While this is a nice way to lower the risk that a machine failure
takes a lot of already checked keys down the drain, it still doesn't
help to save the already requested _new_ blocks. I don't have a 
workaround for this and I am sure many users already requested lot's
of blocks which they will not be able to return ever because the
personal proxy server (or some buffering clients) lost them.

I'd love to have a personal proxy which saves it's newly requested
blocks as well as the status of it's completed blocks on disk such
that the process can be terminated without losing track on what's going
on. The same logic should also be implemented in the clients.

For instance, I am using the Win95 'TimC' buffered client. It can buffer
20 key blocks and get back to the server when it is done with these
20 blocks. I figured it would be nice to let this client talk to
my personal proxy on some other machine, request 20 blocks. Tell the
client over it's 'hot-keys' to terminate, take the machine (Notebook)
into work, let it work on the 20 buffered blocks during the day, and
when I get home, let it synchronize with my personal proxy. Well, it
doesn't work this way, I tried it. The first 2 steps worked just nicely.
But once I tred to start the client at work, it immediately wanted to
communicate with the server although it already had 20 keys buffered
to disk (The TimC client does buffering to disk). It simply didn't
continue the work on the blocks from disk. Then I plugged the machine
into my intranet and thought I'd request another 20 blocks through
some socks gateway, let em buffer the results to disk and still flush
them through my personal proxy at home. Well, this didn't work either.
When I came back home and started the client, it didn't remember any
blocks it had checked during the day.

To summarize, I'd like to have a client which can checkout a user
definable number of blocks and _not_ immediately start to process these.
I want to be able to take the (portable) machine away from the network
and let it work on the keys 'offline'. The results should go to disk,
and finally I'd need a mechanism to just transfer the completed blocks
to a proxy server. Ideally the requesting and the returning servers
should be allowed to be different machines. How about the following
three standalone programs (or one program with appropriate commandline

   getblocks -c <count> -a <keyserver> -o <diskfile>

   checkblocks -o <diskfile>

   putblocks -o <diskfile> -a <keyserver> <email team>

Friedemann Baitinger           baiti at herrenberg.netsurf.de

To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list