[RC5] RUFR implementation (was: Really useful feature request)

Peter Hugosson-Miller pehu at im.se
Wed Apr 8 18:59:30 EDT 1998

On Mon, 06 Apr Jim C. Nasby wrote:

>I will agree whole-heartedly that your idea is a good one, but we
>don't have the resources to impliment it right now, especially
>since there is a work-around.
 <!-- Snip -->
>We have taken note of your request and will keep it in mind.
>D.Net User Interface

Ok, now I know the idea has gotten through to the coding team, I'll
let it rest for a while. But first two important reminders to them:

*  This is not just a new feature, it's a performance enhancement!!
*  All the code needed to make this work is already in the client!!

If I had the source code, my three _tiny_ modifications would look
something like this (if the client were written in Smalltalk):

Assuming the presence of the following two globals:

>  inBufferFileName               "The string 'buff-in.rc5'"
>  workingBuffer                  "The buff-in.rc5 file from which
>                                  the client processes blocks."

and the following three methods:

>  #refilWorkingBuffer            "Refills the working buffer."
>  #fetchBlocksFromServer         "Fetches blocks from the server."
>  #fetchAllBlocksIn:             "Fetches all blocks from a buffer
>                                  file to the working buffer.
>                                  This is used today, to recover
>                                  blocks from the checkpoint file."

Here's how I would do it:

> _/  _/  _/  _/  _/  Modification #1  _/  _/  _/  _/  _/
> In the initialize routine, add a line to read the global variable
> <localDirectory> from the ini-file (defaults to ./local), and
> create the directory if it does not exist.
> _/  _/  _/  _/  _/  Modification #2  _/  _/  _/  _/  _/
> fetchBlocksFromServer
> "Fetch blocks from the server. Sent by the existing method
> #refilWorkingBuffer, and by the method performed when the user
> asks the client to fetch more blocks."
>   | localBuffer |
>   localBuffer := localDirectory openFileNamed: inBufferFileName.
> "All the existing code in #fetchBlocksFromServer is used, but the
> client writes blocks to <localBuffer> instead of <workingBuffer>.
> (If the network is not available, the client still generates random
> blocks, and if <localBuffer> is a non-existing file, it still creates
> an empty file there, i.e. no more changes)."
>   localBuffer close.
> _/  _/  _/  _/  _/  Modification #3  _/  _/  _/  _/  _/
> refilWorkingBuffer
> "The Working in-buffer has run out of blocks, and needs refilling.
> First, fetch blocks to the <localBuffer> file, if it does not exist
> or is empty."
>   | localBuffer |
>   localBuffer := localDirectory openFileNamed: inBufferFileName.
>   (localBuffer isExistingFile not or: [localBuffer isEmpty not])
>      ifTrue: [self fetchBlocksFromServer].
> "Second, fetch all blocks from the <localBuffer> file. If the
> <localBuffer> file is still empty, the following will have no effect,
> but the random blocks generated in #fetchBlocksFromServer will be
> processed as normal."
>   self fetchAllBlocksIn: localBuffer.
>   localBuffer close.
> _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/

That's it! Three minor modifications, to give a non-stop, very
low-maintenance client that runs all blocks FIFO, with _no_ loss in

I realize, of course that the clients are not written in Smalltalk,
but the above is so simple to understand, that even a non-programmer
could see what is happening. Even if the client were pure Assembler,
this modification wouldn't take more that a couple of hours, including
testing. I've done all the hard work already ;-)

Funny that the original point of the exercise (to simplify the
sneaker-net movement of blocks between clients) starts looking like a
side effect!

When assigning priorities to future anhancements, remember that this
one is more than just a new feature, it's an major overall performance
improvement for the mega-computer called distributed.net!

Best regards,

Peter Hugosson-Miller

Send some money to distributed.net today. Visit EyeGive:
Just visiting does good and telling your friends makes it meaningful
"Windows: The CP/M of the future!"

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