[RC5] Really useful feature request

Peter Hugosson-Miller pehu at im.se
Fri Apr 3 14:52:57 EST 1998


On Thu, 2 Apr 1998 James Mastros wrote:

>On Wed, 1 Apr 1998, Peter Hugosson-Miller wrote:
>[...]
>> So here comes idea #1:
>>
>> For clients running in offline mode, give the option to specify a
local
>> fetch directory. Let the client check for the existence of a
buff-in.rc5
>> file in that directory each time the working buff-in.rc5 file is
empty,
>> and if it exists, move it to the client directory, and start
processing
>> those blocks. Otherwise, start generating random blocks as before.
>> Simple, easy to implement, and _very very_ useful.
>
>Hmm... if you can do this, then why not just point the client to this
>directory in the first place?

Oh, no! Idea #1 was the important and _really_ useful one! I guess you
would have to be sitting behind a firewall to really appreciate it. The
other two ideas were logical spin-offs, just "would be nice" kind of
things.

Allow me to explain with a scenario:

<SCENARIO>
You have a machine at your workplace which runs the client all the time.
It sits behind a firewall, and can't fetch/flush on its own. It has its
own private set of buff-in.rc5 and buff-out.rc5 files.

You have another machine at home, which runs the client whenever it is
switched on. Every now and then it is connected to the internet and has
the ability to fetch/flush buffer files.

Here's how you would work if my idea(s) were implemented:

At home, you fetch a nice big buff-in.rc5 file (1000 blocks). You mail
it to your machine at work. That machine doesn't need any new blocks
just yet, but you know that at about noon tomorrow it will. So you go to
work, read your e-mail you just sent yourself from home, and save the
buff-in.rc5 file in the client's local fetch/flush directory, and forget
all about it.

Come noon, the client says "Mooo, need some more blocks. Are there any
in my local fetch/flush directory? Yes! I'll use those!". It then moves
the buff-in.rc5 from its local fetch/flush directory to its working
directory, overwriting the now empty file that is there. Of course, if
it doesn't find the file, or if there is one but it's corrupt (or
empty!) it just ignores it and starts generating random blocks (maybe
sends a mail saying "Feed me! :-]" to your home address).

Before you go home that day, you just move the buff-out.rc5 file from
the client's working directory to its local fetch/flush directory,
rename it to mail001.rc5 (i.e. save it just in case it doesn't get home
in one piece), and mail it to yourself at home. Next time the client
need to write to its (now missing) buff-out.rc5 file, it will simply
create a new one (this already works today). Now you see where ideas #2
and #3 came from.

When you get home, you read your e-mail you just sent yourself from
work, save the attached mail001.rc5 file as buff-out.rc5, flush it, and
you're done! Maybe make a note in your diary that in four or five days
you will need to fetch another 1000 blocks to mail to work.
</SCENARIO>

Now, the maintenance of the firewall-handicapped client is at an
absolute(?) minimum. Those who are really into writing mail scripts,
would then even be able to take care of the received mails, saving the
attachments in the appropriate directory automagically. Why, the
firewall problem would be almost non-existent.

Hey, what about this for idea #4 (just came to me):

If a client has a local fetch/flush directory and detects a buff-out.rc5
in it (in the scenario, the home client detects those blocks you just
mailed from work), then it flushes them next time it does a flush,
fetches another 1000 blocks and mails them back to the work machine. The
circle is complete!

<!-- Snip -->
> are there really all that many machines that can email out where the
> client can't flush via the normal methods?

Well I don't think that a firewall that stops one from sending e-mail
would be particularly popular <G>. These firewalls that cause problems
for the rc5 client are simply the ones that do their job properly.

OK, now I don't think there can be any doubt about the validity of idea
#1 at least. Please start on it soon guys, a lot of people will thank
you for it. Ideas 2 through 4 (or variations on them, if you think of
anything better) you can do if and when you have a free moment, but idea
#1 would be pure gold.

--
Best regards,

Peter Hugosson-Miller

Send some money to distributed.net today. Visit EyeGive:
http://www.eyegive.com/html/ssi.cfm?CID=1098&email=hugge@bigfoot.com
Just visiting does good and telling your friends makes it meaningful
"Bill Gates: The man who gave cream pies a good name."


--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list