[rc5] Best setup for infrequent dial-up connection

James Mastros root at jennifer-unix.dyn.ml.org
Thu Oct 30 21:25:06 EST 1997

On Sun, 26 Oct 1997, Chris Arguin wrote:
> On Sun, 26 Oct 1997, James Mastros wrote:
> > [...]
> I don't think it involves any re-writing in the servers or the protocol. 
> To make this work, you would have one machine that uses the v3 protocol to
> request a block. That machine then gives out keys from that block to other
> machines. When all the keys are done, it hands back that block and request
> another. As far as the proxy servers are concerened, it's just another
> client. The only difference is it's method of computation. 
> Is this worthwhile? Maybe not. It lets people see what we are doing, so
> that hopefully they will be interested and get the full-blown version. But
> it might be a lot of coding effort for little gain.
> > > Maybe
> > > we could even change the banners around so that if the browser is java
> > > complient, the banner is actually the client :) With all the web pages
> > > (including mine) that link to the banner...
> > We would have to change the HTML code to link to the banner then... it 
> > would look something like:
> ??? Like what? You missed this part.  :)

Whops...  I forgot the synthax for a java applet anyway <G>.  Anyway, there
would be some minor changes (basicly, just wrap the whole thing in an
<applet> tag.  leave the current content inside, so non javafied browsers
will still get the gif.

> > It's probably not possible to glean firewall data from the browser, I would
> > think that that would be precived as a possible security risk.  However, we
> > could give simple easy instructions to look up the firewall data from the
> > browser settings dialog (do we NEED any data that you can't get from there?)
> Well, what data do we need? The current client wants to know why type of
> access you have. That includes whether there is a firewall or not. Like
> you say, we can just direct the user to that screen to find out. That's
> simple enough. We need their e-mail address (which hopefully they know).
> Is anything else really important?

The processor and OS.  That's the hard part.  We can have the client guess
the processor at runtime, but not relibably.  We can have the CGI guess at
the OS from the browserid (or the applet from navagator.browserVer).  Or can

> I'm beginning to think that by default we should have it download 50 or so
> blocks, with the -frequent option. Users who know what they are doing can
> change this. Dial-on-demand would be a bad default. Some people may have
> long-distance ISPs, and I'd hate to have this program dialing up behind
> their back. (you notice that we are getting back to the subject line of
> the message finally :)

Perhaps we should have the java version take you to a CGI on d.n.  That
would take the input gleaned from the java applet, and present a form, with
that data as defaults.  Have form feilds for stuff that should be in the
.ini file, and then have d.n package up a .zip (or .tar.gz or ...) with a
custom .ini, the client, and a little script to automaticly setup the client
to run at startup.

	-=- James Mastros

> Chris Arguin                 | "...All we had were Zeros and Ones -- And 
> Chris.Arguin at unh.edu         |  sometimes we didn't even have Ones."
>                              +--------------+	- Dilbert, by Scott Adams

When the annals of distributed computing are written, and the name 'Bovine'
appears in there, I can say "Hey, I was a part of that, I checked .0012% of
the keyspace".
	-=- Brian Wilson <wilsonb at mindspring.net>
Go to www.distributed.net before I come make you!

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

More information about the rc5 mailing list