[rc5] Personal Proxy Key Server

Andrew Glazebrook andgla at hna.com.au
Fri Jun 20 22:55:33 EDT 1997


	I've written up a poor attempt at a personal proxy key server to try and
pass on some of my experience with it. It is probably full of mistakes -
if you see any, feel free to let me know (except spelling/grammar ones, as
I'll proof read it tomorrow sometime :-). It also has a rather poor
layout, but I'll look into tidying that up sometime later. If people like
it, I'll make it into a nice WWW page as well :-).

Korig's Entirely Unofficial Personal Key Server FAQ, version 0.01.

1 Introduction
2 Command line and configuration file.
2.1 Log format.
3 Operating hints.
4 Questions & Answers.
5 A plug for Team HNA and contact information.
6 The readme.txt file for the personal proxy keyserver.


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

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
of your abilities, and you have a very weak, unreliable, or intermittant
connection to the Internet to directly contact one of the real proxies."


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).

ppks &

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 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.


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 since the linux machine that I run the PPKS runs
through an IP Masqurading OS/2 box on a dialup connection and doesn't have
access to the full internet DNS.


I don't know what benefit would be gained from changing this. My
suggestion to you would be to leave it as it is (I would guess that it
wouldn't work if you changed it, but I don't know).


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


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 a maximum of 50, though it may get less in certain conditions).

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.


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).


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


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.


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


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 0 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).


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).


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.


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 (
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 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
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 has completed checking a key
6/20/97 11:16:38--Client at requesting key block.
6/20/97 11:17:01--ready=94  notify=6  uptime=23.1 hrs  avgrate=0.3

For this later stage in key checking:

ready=94 means that there are 94 blocks of keys waiting to be given to
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
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
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

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) Operating Hints.

Firstly, 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

Secondly, make sure that your connection is working 100% before you try
and get the PPKS to pass on the notifications or (less importantly) to get
new blocks. If the connection is only partially operating, the PPKS can
get stuck trying to pass on the new blocks. Sometimes it will time out,
and sometimes sending a HUP signal (kill -1 pid in linux here) will wake
it up, but sometimes you may have to kill it which may be annoying. I
wouldn't worry about this unless you have had problems with your ISP, or
if your PPKS runs into problems.

Thirdly, 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.

Fourthly, 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). 

4) Questions & Answers.

Q) How many blocks can I collect from the main key server for my PPKS at a

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

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.

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. I've just whipped this
up this evening (20/6/97) because I felt that the readme.txt file which
goes with the PPKS was confusing and not specific enough. I think my
document may be just as confusing now that I look back, so if you have any
suggestions feel free to send them to me (though they should be sent to me
rather than to the Bovine mailing list :-).

Since this has all being typed in one setting, it is probably full of
mistakes (and mistakes due to my ignorance no doubt), so please excuse
them. Corrections will certainly be appreciated. I will put this document
up on the Team HNA web page
(http://www.geocities.com/Athens/8217/hnabov.html) sometime in the next
few days (after I have re-read this and made some corrections). Hopefully
a copy of this will also be placed with the PPKS along with the
readme.txt, but that is up to the people in charge of Distributed.Net.

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 only officialish 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
one of the "full proxies".  This will allow your clients to waste less
trying to connect to one of the main proxies, since the personal proxy
already have more key blocks waiting for your clients when they're ready.


Download the appropriate binary for your platform and also the sample
proxyper.ini file in this directory.  You will need to rename either the
file or the binary such that they both have the same "basename" or else
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
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
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
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
may still be some unresolved issues in its operation.


===== Korig / Andrew / The Chancellor =====
E-Mail: andgla at hna.com.au
WWW: http://www.geocities.com/Athens/8217
Newcastle, NSW, Australia.
No Christ, No Life. Know Christ, Know Life.


More information about the rc5 mailing list