[RC5] A few questions ...
wooledge at kellnet.com
Mon Nov 24 20:06:46 EST 1997
sundae (sundae at technologist.com) wrote:
> >Third, how are the stats going to do when v3 comes out and we start
> >having multiple projects at the same time?
> It's the same project. Just different versions of clients.
No, the long-awaited v3 is something quite different than "yet another
RC5 cracking client". v3 will be an open specification for a protocol
which allows distributed computing clients/servers to be written. Of
course rc5-64 will be ported to the v3 specs (unless of course we're
on rc5-72 by then!!) -- but that will be just the beginning.
Or at least that's the theory.
> >Fourth, am I still cruching keys while my computer is trying to
> >connect to the internet (I still have blocks in buff-in.rc5)?
> Confused again.. totally confused this time... can someone with more
> knowledge on how the client works and better English explain this please?
The multi-threaded clients (of which the linux-mt client and the win32
GUI client are examples) are able to continue cracking "one last block"
while trying to connect to the key servers to get/put blocks.
This is one of my favorite recent changes, personally. I use demand
dialing here at home, and when rc564 tries to connect during "peak" times
it can sometimes take 20 minutes or more(!) to establish a connection.
During that time, that last block is still being processed.
> >What should I do if the server is connected to the internet constantly,
> >only sporatically, or is never connected? Should I set up a personnal
> IMO, for a network that isn't connected to the net all the times, it's
> better to run the personal proxy on the gateway machine.
In that particular case, how does the personal proxy get its blocks? I've
never used any of the pproxies.... Does the pproxy have a "-frequent"?
If your computers are directly attached to the internet (in other words,
*basically*, if you can surf the web without having set up an HTTP
proxy in your browser) then it's best not to use any sort of proxy at all --
just let the clients talk directly to the key servers.
If your computers are connected full-time through a firewall, then I
recommend using the HTTP proxy method to let the clients talk to the
key servers through HTTP. This is not as efficient or as reliable as
talking directly to the key servers, but recent changes to the HTTP
"tunneling" code have made this a good method to use.
If your computers are connected to the Internet through a demand-dialed
network, then you may wish to use a personal proxy to minimize the number
of "dial demands" that will be generated. In general, each client
running will be on its own schedule; they'll drift apart no matter
how closely you try to synchronize them. If your computers generate
"dial demands" every 15 or 30 minutes that could be really annoying
or worse.... By using a pproxy here, your computers will all talk to
the pproxy, and only the pproxy will actually talk to the key servers.
Or at least that's my understanding of pproxies.
If your computers are connected to the Internet only when someone
initiates a connection manually, then you have to be creative. One way to
approach this is to use "-frequent" so that the clients will continually
try to connect; that way, whenever the connection is brought up, the
clients will be ready to take advantage of it. DO NOT DO THIS IF YOUR
NETWORK DIALS ON DEMAND!
> If the computers
> are connected to the net, then the proxy isn't necessary. If they are never
> connected... that's a good question... maybe run rc5 on a floppy as some
> people suggested 2 or 3 days ago?
That's another approach, though if the number of computers is large
enough, it may be worthwhile to use the floppy to tend to a pproxy;
that way, you only have to feed and care for one computer instead of
some large number of them.... The disadvantage to that is that you're
putting all your eggs in one proverbial basket; I'd probably copy to
two different floppies just in case.
The concept of "one last block" assumes the in buffer and out buffer
are the same size. What actually happens is that the first block
pulled from buff-in.rc5 when the client starts up is "reserved" by an
idle thread, and is cracked when the client connects to the keyserver
(in a different thread). It doesn't actually have to be the last block.
Of course, it's possible to be directly connected for outgoing HTTP
traffic (and responses on the nonprivileged ports) but not to be able
to connect to arbitrary outgoing ports (like 2064). This is dependent
on firewall configuration and is beyond the scope of this message.
When in doubt ask your friendly neighborhood sysadmin (or closest
# Greg Wooledge # "Daddy, why do those people have to
# wooledge at kellnet.com # use Microsoft Windows?"
# http://kellnet.com/wooledge/main.html # "Don't stare, son; it's not polite."
# -- Crack RC5-64 now! http://www.distributed.net/rc5/ --
To unsubcribe, send 'unsubscribe rc5' to majordomo at llamas.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5