$Id: Readme.txt,v 1.33 2000/01/30 17:20:49 jlawson Exp $

             distributed.net Personal Proxy build 3xx

Contents:
- Introduction
- Proxy build numbers and client versions supported
- Proxy buffer files
- Installation and operation of the Personal Proxy
- Configuration
- Consolelog and keyblocklog output
- Operations and signals
- Running on windows 95/98/NT
- Command line options
- Q&A
- CPU/OS numbers


INTRODUCTION
------------
This release of the v2 Personal Proxy will allow you to serve all recent
v2 distributed.net Bovine clients. It allows you to establish one of
your own machines as a buffer between your clients and one of the "full
servers" (keyservers) that are officially run by the distributed.net
organizers. 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 and need more.

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
intermittent connection to the Internet to directly contact one of the
real proxies.


PROXY BUILD NUMBERS AND CLIENT VERSIONS SUPPORTED
-------------------------------------------------
Personal proxies are distinguished by the "build number" that is
associated with each new version. Starting with build 300 of the proxy,
some very significant differences have been introduced in an attempt to
begin work on supporting arbitrarily many different types of contests.
Build 300 represents a complete rewrite of the previous proxy code, with
attention paid to making the code modular and easily extensible to new
contests or client differences.

Although the first build 300 was very experimental, the current builds
are stable. Everyone is encouraged to upgrade, pre-300 builds will not
be able to connect to keyservers anymore in the very near future.
Also, build 305 will start to have support for the upcoming
OGR-capable clients and these clients will not be able to communicate
with pre-300 proxies anymore at all. These client will be able to
flush rc5 and des blocks through a build 300 through 304 proxy, but
email/cpu/os/version information will be lost.


PROXY BUFFER FILES
------------------
The personal proxy uses buffer files to store all blocks that are
pending distribution to client, or awaiting transfer to an upstream
server. Every effort has been made to keep the format of these buffers
consistent across proxy versions, platforms, and operating systems.
There are currently 3 main types of proxy buffers that you need to keep
in mind before you considering transporting buffers:

    Format A: up to and inclusive of build 283. (obsolete)
    Format B: build 300 through 304, inclusive. (obsolete)
    Format C: build 305 to current, inclusive.  (current)

Format A is completely obsolete. Format B uses a new advanced
filesystemlike buffering system. Format C uses a less resource demanding
bufferingscheme more appropriate for personal proxy use and will have
support for OGR buffers.

Buffers from any operating system or cpu architecture from a proxy that
creates the same "format" above should be transportable. Note that
"transportable" does not mean that you can "share" buffers between two
*simultaneously* running copies of the proxy!!

If you are upgrading to a new proxy version that uses a file format
that is incompatible with the last version you were using, there is no
way to convert them. You must flush all blocks from the existing proxy
buffers. To do this, set maxkeysdone=1, then start the proxy. It
should flush all blocks to the keyservers. If you don't want clients
to connect to your proxy during this process, set the
"acceptincoming"-flag in the [ports] section to 0 (zero).

After you see a logentry with "rc564 r=x/x,
d=0/1" you know your buffers are empty. Shutdown the proxy and delete
all bufferfiles (ppdes*.des and pprc5*.rc5)
It is safe to simply delete the inbuff files, even if they have keys
left in them. They will eventually be reissued.

If you have blocks in an out buffer, and cannot flush them, please
rename the file to something else or delete it.



INSTALLATION AND OPERATION OF THE PERSONAL PROXY
------------------------------------------------
Since you have this file, you probably have already downloaded and
unpacked the proper distribution for your machine.  If not, see
ftp://ftp.distributed.net/pub/dcti/proxyper-rc5des/ and download the
proxy package for your machine.  Once the proxy is unpacked, you
will need to configure it.  You may rename the binary to anything
you like, but there must be a corresponding config file with ".ini"
as a suffix.  Then edit the .ini file with your favorite text editor
(configuration options are listed in the next section), and then
start the personal proxy in the directory you have installed it in.
The log and dump files will be created in this directory. Hint: If you
specify a relative path for a logfile entry in the .ini, the logs will
be created in a directory relative to the current directory.


CONFIGURATION
-------------
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.
Note that the proxy uses a sliding average that prevents you from
buffering more than 4 days worth of blocks. These numbers will be
adjusted according to your keyrate and should be reasonable stable
after 30 minutes after you started the proxy.

Note that the ini file is only read once (as the proxy starts up).
Modifications made to the ini file will not take effect until you
terminate and restart the proxy. On most platforms, there is a method to
trigger the ini file to be reloaded at will. See the "operations and
signals" section to determine the method that is applicable for your
operating system.

None of the settings in the ini file are actually required to be
specified.  All of the settings have default values that should work
for most people.  However, it is still recommended that you verify and
explicitly set all of the options.

Although we try to keep the format of the ini file consistent between
different builds of the proxy, there are occasionally changes made
between builds that affect the options that are available. Build 300 of
the proxy introduced a fair number of significant differences in the ini
file, so be aware of these differences and compare your current ini to
the one that comes with the new proxy-tarball.


CONFIGURATION: Buffer sizes
---------------------------
The personal proxy requires you to specify the minimum and maximum
number of "blocks" that it should try to keep ready at all times for
clients. However, when you specify the numbers for these two values,
please be certain that you only enter values that are reasonable for the
number of clients that you are planning to support.

Specifying numbers that are too large may cause your proxy to buffer a
more blocks than your installed client-base can use in a realistic
amount of time. It is important to avoid fetching too many extra blocks
to reduce the likelihood of a large number of blocks getting wasted if
your proxy crashes, or you decide to discontinue running a proxy.
Additionally by buffering a large number of blocks, you increase the
number of outstanding blocks that must be tracked and managed by the key
distribution system, which limits many aspects of distributed.net's
performance. On the other hand, specifying too few blocks will make it
more likely that your clients will run out of legitimate blocks should
short-term network outages occur, forcing them to compute randomly
generated blocks, which would have a greater possibility of being
duplicated by other machines.

In general, it is recommended that you buffer no more than about 3 or 4
days worth of blocks, so that you could potentially withstand a network
outage that long in the worst case. There is typically no reason to
want to buffer any more blocks than that. The appropriate number is of
course dependent upon the number and speed of clients that you have
connecting to your personal proxy, so you will have to determine this
value experimentally.

Builds prior to 305 of the personal proxy placed somewhat restrictive
maximum ready block limit of 10000, for the purpose of preventing people
from accidentally specifying an extremely large number of blocks before
realizing that it was too great to support their number of clients.
Unfortunately, this also limited the effectiveness for people who were
legitimately using the personal proxy to support an extremely large
number of clients.

Starting with build 305, the maximum ready buffer limit has been
increased to 200000 blocks, however additional logic has been added to
prevent accidentally fetching an inappropriate number of blocks:

    1) If you specify a buffer limit of 1000 or fewer, the proxy will
       respect this value, just like previous versions.
    2) For values larger than 1000, the proxy will internally treat
       the maximum ready value as if 1000 had been entered, until the
       proxy has been running for a period 30 minutes total.
    3) Beginning after 30 minutes of uptime, the proxy will periodically
       evaluate your average keyrate and allow maxready values as large
       as that sustained rate for 4 days to be specified. If the value
       entered within the ini file is less than the computed sustained
       usage count, then the value you specified will be obeyed.

Additionally, when your maxready value is being suppressed by the
proxy, it will simultaneously adjust the minready in an equivalent
proportion so that the ratio that was originally specified is
maintained. As you can see, the complexity has increased slightly, but
the flexibility has also been improved at the same time. You should
keep this behavior in mind when trying to configure your ready buffer
thresholds.

This automatic behavior is recommended for almost all people. The
proxy will adjust its buffer so there's always enough blocks for a
couple of days. People who use the proxies buffers to sneakernet need
be to able to download large numbers of blocks. For this purpose a
ini-setting [rc564]/expertmode and [desII]/expertmode is added. If
this option is set to 1 (one), the proxy will obey your settings of
maxkeysready and minkeysready.


CONFIGURATION: Dupechecking
---------------------------

The proxy now does limited timespan dupechecking, to reduce the
network-load of upstream servers a little bit. It works as follows:

A block is submitted, first it is looked up in the dupe-history
queue. If it is found there, it's a triple dupe. Just increment the
dupe-number (so it says: "block xx, 3 dupes" in the logs)

If it's not found in the dupe-history, look it up in the
"block-history" (explained later). If so, it a double dupe, log it as
"block xx, 2 dupes". Remove it from the block-history-queue en put it
in the dupe-history-queue.

If it's not found in the block-history, it's not a dupe. Add it to
the "block-history", so we can compare subsequent blocks to it.
This dupechecking can be turned off with a ini-option: Set
[rc564]/checkduplicates or [desII]/checkduplicates] to 0 (zero) and
this mechanism will be disabled. Note that this is not useful at all,
since the fullproxies (or the keymaster) will filter them out
eventually anyway!


CONFIGURATION: Settings
-----------------------

[KeyServer]/ipaddress: the IP address or hostname of the keyserver
from which the proxy will retrieve and send keyblocks from.

[KeyServer]/port: the port on the keyserver to communicate to.

[KeyServer]/connectperiod: determines the minimum delay (in seconds)
between sequential attempted network connections to the keyserver.
This value should typically *not* be adjusted to more than a couple of
minutes, but it should also not be made too short, or else your proxy
might attempt to make a connection as frequently as this amount, which
may prevent it from handling incoming client connections if your proxy
is unable to successfully make outgoing server connections.

[KeyServer]/connectivity: these modes are very much like the normal,
offline, lurk, and lurkonly modes that are available on the windows
clients. This option only has effect on the win32 version of the proxy.
  "normal"   : The proxy will attempt to connect to a server as needed.
  "offline"  : The proxy will not attempt to make any connections to a
       server automatically.
  "lurk"     : The proxy will automaticly send/receive blocks when it
       detects a network connection, but it may also initiate
       connection by itself if it needs to send or receive blocks.
       If you have autodial configured, then your modem will auto-dial.
  "lurkonly" : Same as lurk, however the proxy will not attempt to
       make connections unless it can explicitly detect that your
       modem is currently connected, so it won't ever cause auto-dial.

If you are behind a firewall and must use a proxy to make a connection
on either a telnet or http port, the following options will be useful.

[KeyServer]/uuehttpmode: 0=no special encoding, 1=uue encoding (non
8-bit clean redirect proxies), 2=http encoding, 3=uue+http encoding,
4=socks4 encoding, 5=socks5 encoding, 6=generic proxy, 7=generic proxy
with uue encoding. 
For an explanation on generic proxy support, see below.

[KeyServer]/httpproxy: The name of your site's http or telnet proxy.

[KeyServer]/httpport: The port to connect to the above proxy on.

[KeyServer]/httpid: User and password authentication needed to connect
to the above proxy. This field must be set to the *encrypted* value of
the username and password information. In order to get this value, use
the client's configuration option to specify the username and password,
then cut and paste that field from the client .ini to your proxy .ini.
Remember to restore the client configuration when you are all done with
this. For socks4 httpid is the "username" in plaintext. For socks5
httpid is the "username:password" in plaintext. For generic proxy, this
is the connection negotiation string.

[KeyServer]/bindip: Specifies the local interface address that should
be bound to when creating outgoing server connections.  This might be
useful if your machine has multiple interfaces and you wish to listen
for incoming clients on an internal network, and make outgoing internet
connections on a public network interface.  If you leave this option
unspecified, it allows the network stack to do default interface and
routing rules to create connections.

[KeyServer]/maxservers: Determines the maximum number of simultaneous
upstream server connections will be used to fetch or flush. It might be
useful to increase this number if you frequently need to upload or
download a large number of blocks at a single time, and it seems that
individual server connections are slow or have high latency. The default
value is 1 and the maximum number you can specify is 4.

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

[ports]

[ports]/listenaddress: The IP address of the machine this personal proxy
is running on. This is optional and only needed if the machine has
multiple IP addresses. If you use one ip address for local connections,
and you have a dialup account that you use to fetch and flush blocks,
you do *not* need to set this.

[ports]/port: the port on *your* machine to listen for incoming
clients on.

[ports]/port2, port3, port4: these allow you to specify additional
listening ports on *your* machine to listen simultaneously for incoming
clients on. Typically these additional ports aren't needed, but this
ability is here if you need it.

[ports]/testport: the port on *your* machine to listen for incoming
clients on and distributed test blocks to. This value can be
unspecified, or set to 0 to disable this functionality.

[ports]/acceptincoming: if this is set to 0, clients will not be able
to connect to the proxy at all. Defaults to 1.

[ports]/advertisedaddres: This value is normally not needed and is only
needed if you are having problems serving HTTP clients and your personal
proxy machine has a different address by which it is reached on than
what it listens on. (This is usually the case when you are attempting to
serve clients with a machine behind a NAT firewall, or a port-redirected
environment.) This value should be the public IP address that is usuable
by clients to connect back to your personal proxy with. If you do not
specify this value, the value you specified for the listenaddress is
used, otherwise no address is used.


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

[misc]

[misc]/statusperiod: this is the number of seconds between the status
reports from each of the current contests are printed out to the console
log. The contest status reports indicate the number of current ready and
done blocks, their set values, and also the sliding window average
keyrate, and total number of completed blocks since startup.

[misc]/logfilecompressor: the name of a script or program to run
once per log file rotation with one parameter, the name of the just
completed log file. This function is enabled since build 305.

[misc]/proxymessage: an optional text message displayed to all
connecting clients.  If you leave this value blank or unspecified, a
default message including the build number will be displayed to
clients.

[misc]/pidfile: if specified, this is the filename that will have
the process id (pid) of the proxy when it is started up.  This is
only for Unix perproxies.

[misc]/scheduledupdate: this is an internal value is is automatically
updated and maintained by the proxy itself each time it connects to the
keyserver. You should not modify or adjust this value.


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

[console]

[console]/logfileconsole: name of console log file

[console]/logfileconsolerotation: interval to rotate console log at,
options are none, hourly, daily, monthly, yearly, or startup

[console]/consoleverbosity: control verbosity of the console log output.
It is specified with a list of space-separated keywords:

  all        : display all message types (default)
  none       : no console output at all
  general    : General logging (Status: Slot X LISTENING, and others)
  stats      : Periodic statistics reports
  keyblock   : Block numbers
  server     : Upstream keyserver communications
  client     : Downstream client communications
  buffers    : statistics (ready=X/X, done=X, Xd XX:XX:XX, X.X Mkeys/sec)
  timestamp  : Include UTC timestamps on each line (screen only)
  attention  : Keyspace change, time change, dialup events
  errwarn    : Unrecognized opcodes/version
  errlow     : Invalid settings
  errsevere  : Operation inhibiting problems

If the very first keyword is "not", the verbosity will be "all", minus
the keywords specified. For example, "not keyblock client" will prevent
messages in the keybload or in the client categories from displayed; all
other messages are displayed.

[console]/timestampflags: controls the format that is used to display
timestamps on screen, logged in the console log, and logged in keyblock
logs. Note that timestamps in the onscreen console log can be hidden
entirely with the "consoleverbosity" option above. The integer that is
specified for this value is actually the result of adding one of the
format mode values, plus optionally one or more of the additional flags.
The format mode values available are:

  old-style MM/DD/YY HH:MM:SS             1
  new-style YYYY-MM-DD HH:MM:SS           2
  client-style Mmm DD HH:MM:SS            3

And the multiple flags that you can choose are:

  show timezone name                     64
  timestamps should be in UTC           128

Note that the "show timezone name (64)" only has an effect if timestamps
are being "displayed in UTC format (128)". When that is the case, the
letters "UTC" will be appended to all timestamps that are displayed
on-screen (not in console log files, or keyblock files).

The default format is 193, and will provide output that is identical
to that used by personal proxies before build 313.

Also notice that the timestampflags will not affect the numbering
sequence used to generate filenames for automatically rotated logfiles.
Rotated log filenames are always generated from the current UTC time.

Be aware that changing the timestamp format may affect your ability to
use log parsing or log processing utilities. You should contact the
authors of your utilities to obtain a version that is able to parse the
new 4-digit year format, and accomodate localtime timestamps.


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

[rc564]

[rc564]/logfilekeyblock: name of log file of all completed keyblocks

[rc564]/logfilekeyblockrotation: interval to rotate keyblock log at,
options are none, hourly, daily, monthly, yearly, or startup

[rc564]/maxkeysready: approximate maximum number of keys to keep
ready for serving clients.

[rc564]/minkeysready: minimum number of keys to keep ready for
serving clients.  This differs from the maxkeysready in that once the
available keys drops below this value, the proxy will "try harder" to
fetch additional keys from the server.

[rc564]/maxbufferdays: the personal proxy by default will buffer as
much blocks needed for 4 days. If you want to change this default
behavior, this option specifies the number of days the proxy should
buffer blocks for.

[rc564]/minkeysdone: number of completed key blocks that will always
be kept resident and not transmitted.  There is probably no reason
for this to be anything other than 1.

[rc564]/maxkeysdone: number of completed key blocks that must be done
before an outgoing connection to the keyserver is made to flush the
completed blocks.

[rc564]/timeaverage: number of chunks to use for the sliding-average
window.  The default is 288 (1 week in 5 min chunks), the valid range
is 6-2016 (5 hour - 1 weeks). 

[rc564]/timeavgchunk: number of seconds to use for a chuck in the
sliding-average window. The default is 300 (5 minutes). Valid range is
between 1 minute and 30 minutes. This option is added for people who
desperately need a window bigger than 1 week. Beware that changing the 
defaults of "timeaverage" and "timeavgchunks" is not recommended. Too
high values can lead to an increase in resources needed to track the
stats.

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

[desII]/[csc]/[ogr]

see the rc564 section for the entries that you can put here, and
what they do....


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


[ignoredip]/[allowedip]

These two sections provide functionality for allowing and denying
certain ipaddresses or ipaddress ranges.
The rules are:
a. if there are entries in [allowedip], only allow clients in that
   section, else
b. if there are entries in [ignoredip], deny all clients in that
   section, else
c. allow the connection

This is equivalent with the behavior of the tcpd wrapper in Unix
systems.

After the section header, ip(-ranges) are listed in the form:

    anything=1.2.3.4,maskbits

one line for each block of IP addresses you want to ignore.
To ignore a class C subnet (255 addresses, x.x.x.*, /24), maskbits
will be 24.  For an entire B network (65536 addresses, x.x.*.*, /16)
you will want to use a maskbits of 16.  Note that this format is
different from the format that was used in build 280 and prior of
the personal proxy.

Additionally, you can enter masks using any of these forms:

    anything=1.2.3.*
    anything=1.2.*.*
    anything=1.*.*.*


CONFIGURATION: Generic proxy mode
---------------------------------
Build 306 of the personal proxy introduced a new method of firewall
compatibility communications, known as "generic proxy" (a name also used
by the programs CRT and SecureCRT). This new method of communication
allows you to establish redirected TCP/IP connections through an
intermediate machine/proxy that requires a login or negotiation
sequence. This includes connecting to a gateway machine to log in and
then telnetting to the destination keyserver, and also connecting
through a WinGate "telnet proxy" that requires you to specify the
destination hostname and port.

In the generic proxy modes, the interpretation of the "httpid" value is
changed to represent the login sequence string, which is merely a
vertical-bar ("|") delimited string of alternating things to transmit,
and things to wait for. Note that the first sequence in the string is
assumed to be a send string, so if you don't need to send anything first
just include a vertical-bar as the first thing in the httpid. The tags
\n, \t, \r, \1 (keyserver address), and \2 (keyserver port) can only be
used in send strings. Be aware that the maximum length of the entire
httpid string is very limited, so you cannot include sequence strings
that are too complicated currently. Also understand that since the
sequence string is of course stored in plaintext in your ini file, if
you include connection passwords, they could be compromised if you do
not protect your ini file.

One example for connecting to a gateway machine is:
   "|login:|bovine\n|Password:|moocow\n|%|telnet \1 \2\n"
An example for a WinGate telnet proxy is:
   "|WinGate>|\1 \2\r\n"


OUTPUT: Console log
-------------------
While the proxy is running, it displays countless numbers of messages to
indicate its current status. Because of the potentially large volume of
messages that can be generated, a console verbosity option has been
added to the proxy ini files to allow you to select only specific
classifications of messages to be displayed.

There are also methods for causing the console output to be saved to a
file, either for remote log viewing purposes or record keeping. Although
there exist a number of third-party utilities that permit the user to
analyze console logs to produce statistics regarding your proxy's
operations, though console logs were not really intended for any type of
mechanical analysis. The format and style of the console messages are
purely intended to be human readable and will tend to be modified
slightly between proxy builds.

Some messages explained:
- contest <contest> r=<a>/<b>, d=<c>/<d>, <avg>Mkeys/s, total=<blocks>
	a/b = a blocks currently in inbuffer, b is threshold
	c/d = c blocks done, d is threshold
- Server xx.xx.xx.xx changed state from x to x
	state 0  is a no connection
	state 1  is waiting for connection to be set up
	state 50 is a connected connection
	state 51 is a dead connection
- Contesthandler <contest> didn't handle a packet
	For some reason the proxy couldn't process a clientrequest for
        a packet (block). Most of the time due to empty proxybuffers
- Client: rejecting unscrambled communication
	Client tries to send a packet that doesn't comply.
	Most of the time due to too old clients
- rc564-dupe: limits adjusted to historybuf xx, dupebuf xx (and)
  Removing xxx rc564 blocks from [block|dup]-history
	The proxy now does dupechecking. This is implemented by 2 
	queues, the blockhistory and the dupehistory. The sizes of these
	queues are dynamically adjusted and sometimes (if the queues
	are full) the proxies purges some of this history. 


OUTPUT: Keyblock log
--------------------
The personal proxy will also output so-called "key logs" which record
details of each completed block that is reported to it by a client.
These files are intended for automated processing and so they have a
very regular, comma delimited formatting. Each line of a key log has the
following fields, in order:

	date/timestamp of format "mm/dd/yy hh:mm:ss"
	IP address of the reporting client
	email address of the client
	first block number in completed packet (16 hexadecimal digits)
	itersize of packet (number of 2^28 blocks)
	operating system identifier of client (0=unknown).
	cpu type of client (0=unknown).
	build number of client (middle segment of version number).

01/15/99 07:39:16,0.0.0.0,rc5@distributed.net,6404AF4970000000,10,0,0,6400

See bottom of this document for a list of OS and CPU types and
numbers.


OPERATIONS AND SIGNALS
----------------------
On UNIX, sending a TERM or INT signal will cause the personal proxy to
shut down nicely, resaving all keyblocks that are still in memory to
disk, and closing all open network connections.

On UNIX, sending a HUP signal will cause the personal proxy to reload
its ini configuration file and reread most of the settings specified
within it.

On UNIX, sending an ALRM signal will trigger the personal proxy to
create an outgoing server connection. This is done even if your
connectivity mode is set to offline. This behavior is intentional, and
permits clever scripters to automate periodic dialups and forced server
flushes.

On Win95/98/NT, when running the proxy in a window you can press
Ctrl-Break at any time to perform the equivalent of a HUP+ALRM signal on
UNIX. To actually close the proxy, press Ctrl-C or close window.

On OS/2 you can press Ctrl-C to force a reload of the ini file and
create an outgoing server connection. Ctrl-Break is used to close
the proxy.



RUNNING ON WINDOWS 95/98/NT
---------------------------
The personal proxy can run on successfully on a Windows 95/98
workstation, however it is discouraged that this be done on a machine
that is being heavily used as a normal user workstation, due to the
frequent crashes and relative instability of Win95/98 when it is
actively being used. If you really need to run a proxy on a Windows
machine, it is recommended that you use an NT machine, if possible.

On Windows NT, the proxy can be run either as a foreground console
application or installed as a service and run transparently in the
background, unaffected by user logins. (See the "command line options"
section for instruction on service installation and removal).

Under Windows 95/98, the proxy can only be run as a foreground console
application. There are no plans to support running the proxy as a
"hidden" or "service" application in this environment.

Please be aware that if you are running the proxy as a foreground
console (and not as an NT Service), you should avoid simply closing the
console window directly. Instead, when you want to shut down the proxy,
you need to focus the window and press Ctrl-C to initiate a shutdown.
Failure to do this will cause the proxy to not have an opportunity to
shutdown nicely, possibly corrupting your buffers or causing some blocks
to be lost.

Notice that the personal proxy requires Winsock 2 services to be
available. Most original distributions of Windows 95 (but not Win98 or
WinNT4) come with only Winsock 1.1, so you must install the update from
Microsoft. You can download this update from Microsoft's website at
(the following URL has been wrapped for readability):

http://www.microsoft.com/windows95/downloads/contents/wuadmintools/
	s_wunetworkingtools/w95sockets2/default.asp



COMMAND LINE OPTIONS
--------------------
The personal proxy allows several command line options that tell it to
enter one of several exclusive and session-lasting modes of operation.

On Windows NT only, you can install the proxy as a service by first
running it with the "-install" option to register it as a service. You can
then start and stop the proxy from the standard Windows NT services
Control Panel. You can use the "-uninstall" option to remove it from the
services registry.

Previously a detached mode option existed in the ini file to allow the
proxy to be started as a daemon-like service on your UNIX machine. This
has now been made available only as a command-line option, and must be
invoked by starting the proxy with "-detach" on the command line.



QUESTIONS?
----------


Q. My proxy's connection is frequently disconnected from the Internet
and is always too busy trying to make outgoing server connection to
handle connections from my clients. Why is it ignoring my clients?

A. Your connectperiod is so short that by the time the last server
connection attempt times out, another connectperiod has already passed
and the proxy decides that it needs to attempt to make another one.
Increase your connectperiod to at least several minutes, or (preferably)
set your connectivity mode to offline (or lurkonly on win32).



Q. How does offline mode work?

A. In offline mode, the proxy will never attempt to initiate an outgoing
server connection by itself, so it will eventually run out of blocks if
it is never given an opportunity to make a connection. You can
explicitly force the proxy to make a server connection at any time by
sending it a SIGALRM signal on UNIX, or pressing Ctrl-Break while its
window is in focus on Win32 (there is currently no equivalent for doing
this while the proxy is running as an NT service).




Q. How many clients can a personal proxy handle concurrently?

A. The personal proxy can have active and open connections to 32 clients
at any one time. Since clients connect infrequently, a personal proxy
can serve several hundred clients.



Q. Can my clients share my personal proxies buffer files?

A. No. The ppbuf*.rc5 files are not compatible with the client keybuffer
files, so clients cannot share the keyproxy's dump files.



Q. How does the personal proxy report email address, IP address,
platform, OS, and client version information to the master keyserver?

A. The proxy transmits to distributed.net the email, platform, OS, and
client version information exactly supplied to it by the client.
However, the IP address that is reported to distributed.net will be that
of the personal proxy, not the client. See the end of this file for a
list of CPU types and OS types.



Q. Where can I get more help or ask other questions about the personal
proxy?

If you have any options questions or difficulties using this proxy, you
should address your messages to "proxyper@lists.distributed.net" or to
"rc5help@distributed.net"

Note that the first address is a mailing list, and it is recommended
that you join it before sending a message to it, or you may not see the
responses to your original message.

To subscribe to the proxyper mailing list, send a message containing
the text "subscribe proxyper" to "majordomo@lists.distributed.net"

You may also be able to obtain help on the EFNet channel #distributed.
This is not an official support mechanism, but there are frequently other
experienced personal proxy operators who are often able to answer
questions and help solve your problems.



CPU/OS NUMBERS
--------------

CPU types:
	UNKNOWN     0
	X86         1
	POWERPC     2
	MIPS        3
	ALPHA       4
	PA_RISC     5
	68K         6
	SPARC       7
	JAVA_VM     8
	POWER       9
	VAX         10
	ARM         11
	88K         12
	KSR1        13
	S390        14
	MASPAR      15

OS types:
	UNKNOWN      0
	WIN32        1  // win95 + win98 + winnt
	DOS          2  // ms-dos, pc-dos, dr-dos, etc.
	FREEBSD      3
	LINUX        4
	BEOS         5
	MACOS        6
	IRIX         7
	VMS          8
	DEC_UNIX     9
	UNIXWARE     10
	OS2          11
	HPUX         12
	NETBSD       13
	SUNOS        14
	SOLARIS      15
	OS9          16
	JAVA_VM      17
	BSDI         18
	NEXTSTEP     19
	SCO          20
	QNX          21
	OSF1         22    // oldname for DEC UNIX
	MINIX        23
	MACH10       24
	AIX          25
	AUX          26
	RHAPSODY     27
	AMIGAOS      28
	OPENBSD      29
	NETWARE      30
	MVS          31
	ULTRIX       32
	NEWTON       33
	RISCOS       34
	DGUX         35
	WIN32S       36    // windows 3.1, 3.11, wfw (32-bit Win32s)
	SINIX        37
	DYNIX        38
	OS390        39
	MASPAR       40
	WIN16        41    // windows 3.1, 3.11, wfw (16-bit)

