[rc5] Personal Proxy Key Server: Unofficial MiniFAQ

Andrew Glazebrook andgla at hna.com.au
Sun Jun 22 14:56:59 EDT 1997


Hi.

	Here is my minifaq with some minor corrections and additions. If anyone
has any suggestions of recommendations for it, feel free to e-mail me.
Also, if sending this over the mailing list is annoying people, let me
know and I'll stop doing it (or perhaps only do it when there have been
very significant changes). Oh, and I've only just start the glossary, so
don't be too disappointed by it :-).

- - - - - - - - - - - - - - - - - - - - - - - - - - - -

Korig's Unofficial Personal Proxy Key Server MiniFAQ, version 0.02
(22/06/97)

1 Introduction & Disclaimer.
1.1 Glossary.
2 Command line and configuration file.
2.1 Log format.
3 Hints.
3.1 Operating Hints.
3.2 Reliability Hints.
3.3 Third Party Software.
4 Questions & Answers.
5 A plug for Team HNA and contact information.
6 The readme.txt file for the personal proxy keyserver.

[1] Introduction & Disclaimer

Disclaimer: I am not responsible for any incidents or accidents which
occur as a result of your having read this MiniFAQ. I am not involved with
the design or implementation of the Personal Proxy Key Server or any other
aspect of Distributed.Net, and neither they nor I can be held responsible
for any of your actions. This MiniFAQ is bound to have inaccuracies and
errors, mistakes and faults, grammar errors and generalisations, however
to the best of my knowledge the included information is correct. I will
modify the MiniFAQ daily if needed in an attempt to keep it accurate and
up to date as I gather more information on the Personal Proxy Key Server
(while I'm on holidays anyway :-).

The personal key server is useful for dialup users (and users with an
internal network which only has one computer connected to the internet)
for collecting a batch of keys (up to 100 blocks) to check at your
leisure.

To quote the readme.txt file for the personal proxy key server:

"Running a personal proxy is definitely not needed by everyone, nor is it
recommended.  You should only run a personal proxy if you are very
confident
of your abilities, and you have a very weak, unreliable, or intermittant
connection to the Internet to directly contact one of the real proxies."

Section 1.1 is a glossary of important terms related to the Personal Proxy
Key Server and the RC5 clients, and is to aid your understanding of the
later sections of the FAQ. Section 2 is all about the actual running of
the PPKS (Personal Proxy Key Server), while section 3 has hints based from
my experience with the PPKS. Section 4 is a series of Questions and
Answers, I expect this section will expand with time. Section 5 is contact
information for me and Team HNA, while section 6 is the readme.txt file
which comes with the actual PPKS.

[1.1] Glossary

Block of Keys, see Key Block.

Key block, A key block is a phrase I use to describe a collection of
268,435,456 sequential keys. Key blocks are typically originated from the
Bovine RC5 Key Server, and supplied to Bovine RC5 key checking client;
either directly, or by passing through a Personal Proxy Key Server (PPKS).

Notification, this is the confirmation of having checked a block of keys
(see Key Block), and notification is sent to the Bovine Key Server either
directly or through a PPKS. If a client or PPKS is lost whilst having not
passed on notifications, then those notifications are lost (unless the
client has Key Buffering).

PPKS, Abbrieviation which I am using for the Personal Proxy Key Server.

Workperiod, a field in the PPKS configuration file which specifies how
frequently (in seconds) the PPKS ought to recheck the configuration file,
and attempt any specific duties (eg. fetching new blocks of keys, passing
on notification).

[2] Command line and Configuration File.

I'd recommend you firstly rename the PPKS (Personal Proxy Key Server) to
something a little shorter. Perhaps even just ppks (which is what I will
use for the example).

nohup ppks &

That is the command I would use at the command line. This will have it run
in background, and let you continue working from that session (with the
update information appearing on your screen). The nohup is used so that
the program will continue running if you log out or are disconnected.

The next step is to make sure that your configuration file is named the
same as the PPKS (except with a .ini on the end), and that it is in the
same directory as the PPKS.

[keyserver]
ipaddress=rc5proxy.distributed.net

This is the IP address of the keyserver you want your PPKS to collect the
keys to be checked from, and that you want it to pass the results of the
checked keys on to. To the best of my knowledge this can be any of the
central servers (used with rc5proxy.distributed.net) or possibly even
another PPKS (I don't know whether this would work or not). I use an IP
address of 198.37.25.142 since the linux machine that I run the PPKS runs
through an IP Masquerading OS/2 box on a dialup connection and doesn't
have access to the full internet DNS.

port=2056

I don't know what benefit would be gained from changing this. My
suggestion is that you leave it alone unless you have a good reason for
changing it (such as tunneling through a firewall).

workperiod=30

This is how many seconds go by between network accesses. This includes
things such as re-reading the configuration file, and similar actions.

threshold=30

This means that when the PPKS has been notified that 30 blocks of keys
have been checked it will attempt to open a connection to its key server
to pass the notifications on, and will also collect new blocks to check
(up to the value of maxkeysready or 100, whichever is smaller).

This is the value I use for dialup. I have it set to 91 while I'm not
connected, and change it to 1 when I have connected. If you are using a
Dial On Demand script, I would recommend using this setting rather than
the minkeysready option to initiate connections (minkeysready does not
pass on notifications when it collects new blocks of keys, whereas a
connection initiated by the threshold will pass on notifications AND
refill the PPKS with new blocks of keys to check).

[keyproxy]
ipaddress=

Left blank it will use all the local IP addresses of the machine you are
running it on. If you enter an IP address it should only work when clients
try and connect to that specific IP address of the machine (this is of
little use if your machine only has 1 IP address).

port=2056

This is the port to listen to. If you want clients to use a different port
than the default to connect to your PPKS, then this is the setting to
change.

timeout=15

According to the readme.txt file, this is the timeout for dead incoming
connections. I guess that any client that connects and doesn't do anything
for this value (15 seconds I assume) will have the connection terminated.

backlog=5

>From the readme.txt file - "incoming TCP connection backlog"

[options]
minkeysready=10

With this setting the PPKS will attempt to get a new batch of key blocks
when the number of blocks it has waiting reaches 10. I wouldn't use this
value for a Dial On Demand connection, as it doesn't pass on notification
of checked blocks at the same time. This would probably be most useful if
someone was running a PPKS from you, and was likely to take a large amount
of blocks to check for sometime. I have it set to 1 here, as I think it is
pretty unlikely that I am going to run out of blocks to be checked (I get
a new batch of blocks atleast once a day).

maxkeysready=100

This is how many blocks of keys your PPKS is willing to keep on standbye.
While you are first tinkering with the PPKS it would be worth lowering
this to 20 or perhaps even 10, so that if you run into problems not too
many blocks of keys get lost (not that it is a major problem if you do
lose a few hundred). 100 is the maximum value this option will use (which
is a little unfortunate).

logfile=rc5proxy.txt

This means everything will be logged to a file called rc5proxy.txt in the
directory you are running the client. It doesn't log much, basically only
when people collect a block to check, send notification of having checked
a block, or when the PPKS interacts with another key server. This log file
does not save information on blocks that have been checked - if the key
server dies while there are notification of blocks checked waiting those
checked blocks will be lost (unless you logged from the client side, and
then you should ask at the bovine mailing list if the information you
collected was worthwhile.

[2.1]

Generally, your log file should contain information similar to this:

6/17/97 07:35:07--Now using 'rc5proxy.txt' for file logging.
6/17/97 07:35:07--Listening on all local IP addresses.
6/17/97 07:35:07--The personal proxy will listen to local port 2056
6/17/97 07:35:07--Using TCP connection backlog of 5
6/17/97 07:35:07--ready=0  notify=0  uptime=Long  avgrate=0.0 Mkeys/sec
6/17/97 07:35:08--Now using keyserver 199.45.111.6 (199.45.111.6)
6/17/97 07:35:10--The Bovine Proxy KeyServer (Build 1526)
6/17/97 07:36:33--Retrieved 50 keys from server
6/17/97 07:36:35--Client at 200.90.1.36 requesting key block.
6/17/97 07:37:05--ready=49  notify=0  uptime=1 mins  avgrate=0.0 Mkeys/sec

The basic information that is important from this is that:

ready=49 means that there are 49 blocks of keys ready to be given out to
clients.
notify=0 means that no blocks have been checked to need their information
passed on to a proper key server.
uptime=1 mins means that this PPKS has been running for 1 minute.
avgrate=0.0 Mkeys/sec means that this PPKS hasn't done much yet :-).

6/20/97 11:16:38--Client at 200.90.1.36 has completed checking a key
block.
6/20/97 11:16:38--Client at 200.90.1.36 requesting key block.
6/20/97 11:17:01--ready=94  notify=6  uptime=23.1 hrs  avgrate=0.3
Mkeys/sec

For this later stage in key checking:

ready=94 means that there are 94 blocks of keys waiting to be given to
clients.
notify=6 means that 6 blocks have been checked, and the results are
waiting to be passed on.
uptime=23.1 hrs means this PPKS has been running for 23.1 hours.
avgrate=0.3 Mkeys/sec means that in the 23.1 hours that this PPKS has been
running, enough blocks have come through to maintain an average rate of
checking 0.3 million keys per second (or 300 thousand keys per second).

6/20/97 09:07:50--ready=97  notify=2  uptime=20.9 hrs  avgrate=0.3
Mkeys/sec
6/20/97 09:08:23--Transmitted 2 keys to server
6/20/97 09:08:54--ready=97  notify=0  uptime=20.9 hrs  avgrate=0.3
Mkeys/sec
6/20/97 09:08:56--Welcome to rc5proxy.distributed.net (opus)
6/20/97 09:08:58--Retrieved 3 keys from server
6/20/97 09:09:28--ready=100  notify=0  uptime=20.9 hrs  avgrate=0.3
Mkeys/sec

This marks an exchange between my PPKS and a key server. I'm sure that by
now you have the hang of what everything means. Basically, the first line
is the last PPKS status. Then I connected to the ISP I used, and changed
the settings in the ppks.ini so that threshold=1 so that the keyserver
would pass on the keys checked. Then after passing the keys on, it
automatically collected a new batch of blocks to check, and then it
reported the status of the PPKS with the new blocks of keys. 

[3] Hints.

I've divided this up into three sections. Operating Hints, which are
general hints to make running the PPKS more effecting and efficient, and
Reliability Hints, which are hints on how to avoid killing the PPKS and
losing checked blocks etc, and lastly a Third Party Software section which
gives information on using other packages to enhance your use of the PPKS.

[3.1] Operating Hints.

1) If the PPKS shutsdown, you lose all the blocks that have been checked.
I have lost over 70 checked blocks of keys this way. If you think the
system is likely to be shutdown, then try and pass on your notifications
quickly before it occurs.

2) Sending a TERM or INT signal to the PPKS will cause it to close down
and attempt to pass any notifications on through the network to the
specified key server. Sending a HUP signal causes the PPKS to flush
buffers - I believe that this includes passing on notifications, so be
careful with its use.

3) Keep checking blocks and passing those notifications on :-) This PPKS
is a great idea, and something the DES efforts lacked (and which would
have been very useful).

[3.2] Reliability Hints.

1) I've found that if you copy over the PPKS's configuration file, that
the PPKS stops functioning properly. If you want to change settings, you
will need to modify them manually rather than having two different
configuration files which you just copy over the operating configuration
file (which was what I attempted to do).

2) Make sure that your internet connection is operating fully before you
make a change to the settings to the configuration file to have the PPKS
pass on notifications and fetch new keys. I've found that if the
connection is running poorly the PPKS can have connections stuck open,
which leads to problems (this could be partially caused by my IP Masq.
arrangement).

3) Run the PPKS on the most reliable machine on your network if you can.
Things are a little limited since the PPKS is only available on Unix like
OSs, however this is perhaps just as well as they tend to be more reliable
than the other OSs out there. There is a Win32 client out now which has
many of the features of the PPKS - if you only have one client running,
and it is on a Win32 machine (Win95 or WinNT), then you are probably
better off using that rather than the PPKS (which isn't available for
Win32 machines anyway).

[3.3] Third Party Software.

I will be listing third part software which makes the operation of the
PPKS more effective here. It will be things such as Dial On Demand
software and IP Masquerading packages. There should be information about
these in here by MiniFaq version 0.03. If you are using an IP Masq. or
Dial On Demand package, please send me an e-mail at andgla at hna.com.au so I
can gather more information on your setup. As many of these features will
be useful to regular client users and not just those using PPKS, I will
try and keep the instructions and information fairly general in this
section.

[4] Questions & Answers.

Q) How many blocks can I collect from the main key server for my PPKS at a
time?
A) From my experience, 50 blocks is the maximum that will be collected at
a time, although it can be less. Also, the PPKS will only collect a
maximum of 100 blocks or the value of "maxkeysready", which ever is
smallest.

Q) Is it possible to pass on checked blocks (notificiation) and collect
new blocks to check at the same time?
A) Yes. Use the "threshold" value to set how many blocks you want checked
before communicating with the upstream key server. If you collected a full
100 blocks to check, I'd recommend setting this to 90 so that there is
room for 10% loss of blocks. Once the threshold value is reached, the PPKS
will connect to the upstream key server, pass on the notifications on the
checked blocks of keys, and refill with new blocks to be checked.

Q) When will the next personal proxy key server be released?
A) The next batch of PPKS's are expected to be released at the same time
as the Version 2 clients are released.

Q) What features or improvements will the next PPKS have added to it?
A) I've no idea. However as the new PPKS may be released as soon as
tomorrow, it is best to just wait rather than speculate.

Q) Are there any plans for a PPKS for OS/2?
A) Oscar Chang has said that if there is a great demand, he would be
willing to port it to OS/2. I don't think there is a great demand for such
a port (though I would probably use it if it came out :-), and what demand
does exist is likely to diminish somewhat after the second round of
clients are released.

Q) Do you want a Web version of this MiniFAQ?
A) Let me know - send me an e-mail at andgla at hna.com.au if you think it
should be.

[5] A plug for Team HNA and Contact Information.

I can be contacted either by sending e-mail to andgla at hna.com.au, or if
you post a message to the Bovine mailing list, chances are that I will
read it. The Bovine mailing list is the most appropriate place to post, as
people who know much more about this than me can read your message there
and are more likely to give you a factual answer. If you have any
suggestions feel free to send them to me (they should be sent to me rather
than to the Bovine mailing list :-).

Now to Team HNA. The Hunter Network Association is a non-profit community
organisation which aims to provide affordable internet access to the
people of Newcastle and surrounds (which is in the Hunter Region :-). I
figured that since I wasn't in a team yet, it would make sense to form a
team which would donate the $1000 to the HNA if it found the key. $1000
would cover a good portion of a years operating costs of the HNA, and
would bring it one step closer to becoming a freenet. The Team HNA web
page includes more information about the HNA, as well as some speed
comparisons between the computers being run in the Team HNA effort (if you
want to provide the figures for the table, feel free to e-mail them to me
and I'll include you as well - you don't have to be helping Team HNA).

If you don't want to support Team HNA, then Team Warped is another great
one to become part of (I would have joined it if it weren't for the fact
I'd already started Team HNA before Team Warped was formed). Information
about it abounds at http://www.ionet.net/~colin/rc5.html 

[6] The distributed readme.txt

I don't have permission to include this here (if anyone objects, just let
me know and I'll pull it out). However I felt I should include it, as it
is the official instructions on using the PPKS.

- - - - - - - - - - - - - - - - - - - - - - - - 

This directory contains the personal proxy keyserver.  It allows you to
establish one of your own machines as a buffer between your RC5 clients
and
one of the "full proxies".  This will allow your clients to waste less
time
trying to connect to one of the main proxies, since the personal proxy
will
already have more key blocks waiting for your clients when they're ready.

Running a personal proxy is definitely not needed by everyone, nor is it
recommended.  You should only run a personal proxy if you are very
confident
of your abilities, and you have a very weak, unreliable, or intermittant
connection to the Internet to directly contact one of the real proxies.

Download the appropriate binary for your platform and also the sample
proxyper.ini file in this directory.  You will need to rename either the
ini
file or the binary such that they both have the same "basename" or else
the
personal proxy won't be able to locate its configuration file on startup.

Edit the ini file with a standard text edit and verify the settings.
Depending upon the number of clients you are serving, you may want to
increase or decrease the number of keyblocks that are kept in memory.

When clients connect through your personal proxy, it will be listed on the
main statistics page under the IP address of the personal proxy, and not
that of machine the client is running on.  Note that currently the
personal
proxy tries to talk out on the first available IP address, even if you've
specified to have the proxy listen to a specific address.  This problem
will
be addressed in a future version.

The proxy rereads many of the settings in the ini file periodically
automatically, allowing you to easily adjust the operation of it without
much hassle.

Sending a TERM or INT signal will cause the personal proxy to shut down
nicely, by sending all waiting notifications before it quits.

If you have a dialup connection and have dial-on-demand software
installed,
you may want to try and increase the threshold value to something close to
the maxkeysready value.  This will make the proxy not be so "anxious" to
keep its buffers filled.  Good values include:  maxkeysready = 100,
minkeysready = 10, threshold = 90

The workperiod value specifies how frequently the proxy checks its buffer
to see if the number of keys are below minkeysready or maxkeysready and
if it should connect to the server to get more keys.  You should probably
always keep this value set to 30 seconds or so.  Making it too large will
make the proxy get too "sluggish" about filling its buffers and will allow
the readypool to drop below minkeysready.



Build 121 (28 May):
   - initial release
Build 135 (31 May):
   - now responds to HUP signals to flush buffers
   - resolved problem with Linux, BSD, and possibly other platforms
   - fixed mishandling of right-sized packets, but unknown opcode
   - other minor internal code fixes and additions
        


Please keep in mind that this is the initial release of the proxy and
there
may still be some unresolved issues in its operation.


http://rc5.distributed.net/



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



More information about the rc5 mailing list