Networking options

Introduction

The following information describes the various options available to get work to the clients and report completed work back to distributed.net keyservers. Please read carefully the section that best fits your situation and follow instructions on how to configure your client accordingly.

Permanent connection (Always Online mode)

If you are using a conventional permanent connection through a local area network (not behind a firewall), cable, DSL or ISDN, you should find the client will communicate correctly with the proxies without the need to change any of the client network configuration options from their defaults.

Warning: If you connect to the Internet via a dial-up connection, make sure that you do not leave the client in the default Always Online mode. Otherwise, the client reserves the right to trigger on its own at any time a connection to a distributed.net proxy. You should select the Modem Dialup Lurk or Modem Dialup Lurk-Only options described below instead.

Modem dial-up connection

If you are using a conventional dial-up connection, you should find the client will communicate correctly with the keyservers without the need to change any of the client network configuration options from their defaults, except from changing the connection mode from 'Online Always' to either one of the two modes described below:

• Modem Dialup Lurk: This setting is meant to be used if you have a modem connection to the Internet. Watch out! In this mode, the client may trigger on its own at any time a connection to a distributed.net proxy. If you do not want the client to initiate a connection to the Internet when you are offline, you should select the Modem Dialup Lurk-Only (don't trigger autodial) connection type instead.
• Modem Dialup Lurk-Only (don't trigger autodial): This setting is meant for modem users who do not want the client to connect to the Internet at any time. The client will check that you are currently online before fetching and flushing work units to distributed.net proxies.

Computers behind firewalls

If your machine is behind a firewall, please note that it may not be necessary to make any particular changes to your client configuration. Some firewall environments do not impair the operation of the client.

If it turns out that your firewall is really blocking port 2064, there are several ways to connect to our proxies through your firewall. Each of these situations is described in detail below.

• The most reliable option is to set the firewall to allow connections through to port 2064 (the port the client uses for communication to the keyservers) either directly, through a "datapipe" or if you are using WinGate or Internet Gate, via "direct port mapping". All of these are require administrative access to the firewall host. If you choose the second option, be sure to configure your clients to connect to your firewall's IP address on the port that you've configured it to redirect out.
• The next most reliable option for communicating with distributed.net proxies through the firewall if you are unable to directly modify the firewall's configuration is to use SOCKS support (if your firewall supports it, of course). To configure SOCKS, enter the "Buffer and Buffer Update Options" configuration menu of the distributed.net client, then enter the "Keyserver<->client connectivity options" submenu and select "Firewall/proxy protocol". If you are using a SOCKS4 proxy, choose "SOCKS4", or choose "SOCKS5" if you know the firewall supports SOCKS5. If you are unsure as to which version of SOCKS you are using, select SOCKS4. Now, edit the firewall proxy name/address and port and make sure that they point to the SOCKS proxy you will actually be communicating through. If you must use a SOCKS userid/password, enter it in the appropriate field as well.
• The most compatible firewall communications method is to use the HTTP proxy support of the client. Enter the "Buffer and Buffer Update Options" configuration menu of the distributed.net client, then enter the "Keyserver<->client connectivity options" submenu and select "Firewall/proxy protocol". There, specify that you want to communicate via and HTTP proxy. Enter the name/address of the HTTP proxy in the "Firewall hostname" field and the port number of the HTTP proxy. If you have problems with HTTP encoding, you may wish to try setting the "Always use UUEncoding" flag.
• If the previous scenarios do not or cannot work with your firewall configuration, you might want to consider as a last resort to set up a personal proxy on the machine that runs the firewall. Note that running a personal proxy is definitely not needed by everyone, nor is it universally recommended. You should only run a personal proxy if you are very confident of your abilities, and you have no other option for your clients to connect to distributed.net proxies from behind your firewall.
• A personal proxy will receive connections from clients, buffer them, and then communicate with the main proxy network to send or receive blocks. The setup of this is simple and reliable; all you must do is download a personal proxy available at proxies and set it up to run on the machine that functions as the firewall. Then set up all clients behind the firewall to connect to that machine to receive blocks. (The name/address of the proxy may be entered in the configuration in the "keyserver" field in the "Buffer and Buffer Update Options" menu and "Keyserver<->client connectivity options" submenu. Naturally, you need to be authorized to run the personal proxy on that machine.

Finally, the following list accounts for firewall software that is known to work with the distributed.net clients.

• Wingate 2.x+ (Win32): HTTP proxy, Direct port mapping, SOCKS 4 & 5.
• Internet Gate (OS/2): Direct port mapping
• Microsoft Proxy Server (WinNT): HTTP proxy
• Novell BorderManager (NetWare): HTTP proxy
• Squid (Unix): HTTP proxy
• AltaVista 97 (Unix/Win32): HTTP proxy
• Gauntlet Firewall: HTTP proxy
• eSafe 3.0+: HTTP proxy
• Software602 602Pro Lan Suite (Win32): proxy server

Fetching/Flushing via e-mail

If it is not possible for your client to flush and fetch to distributed.net proxies via the methods described above, it is possible to retrieve and send back work units by email. To fetch work units by email:

1. Send an email to fetch@distributed.net with the following two lines in the body:

   project=RC5

   numblocks=[number between 1 and 20000]

   Within a few minutes, you should receive a message back with the specified number/size of blocks attached as "buff-in.rc5".

   Note: You can request RC5 or OGR keys. To choose which type you want include "project=RC5" or "project=OGR" anywhere in your message.

2. Stop the client running.
3. Rename the file buff-in.rc5 into the dnetc directory to the filename you've setup in the the configuration menu 'Buffer and buffer update options' item 4 'Checkpoint Filename'.
4. Extract the attachment from your mail program to the directory from which you are running the dnetc client.
5. Start the client running.

This will add the new work-units to your work units in progress.

To flush completed work units by email:

1. Send an email to flush@distributed.net with the file "buff-out.rc5" attached as MIME64 encoded file. You will be send a "receipt" of the proper flushing of the blocks a few minutes later.
2. Delete the buff-out.rc5 file so that you do not accidently send part of its contents twice.

Sharing buffers on local area networks

If you want to run the client on several computers from a shared network drive, you have a couple of options. By default the client looks for an .ini file (where client configuration information is stored) with the same name as the client. So for instance if your client is called dnetc it will look for configuration information in a file called dnetc.ini. One solution then would be to create several copies of the client, each with a different name; one for each of the required configurations. Another option is to set the RC5INI environment variable during each computer's start up sequence. The client will preferentially use configuration information stored in the configuration file pointed to by RC5INI. In this way you only need one copy of the client software but you can have several different .ini files, one for each configuration that you need.

Machines without Internet access

It is possible to allow machines that never connect to the Internet to run the client by using a floppy disk to move buffer files between such machines and machines that connect to the Internet and can fetch and flush these buffers. This process is known as "SneakerNetting" and is described below.

Directions for "SneakerNetting"

To simplify these directions, assume that "laptop" refers to the offline/non-networked machine. The following description also assumes you are using Microsoft Windows, though the theory is the same though for all platforms. The buffers are generically called buff-in.rc5 and buff-out.rc5 but this will work for other projects such as OGR by replacing rc5 by ogr in the buffer file names listed below.

1. Download the client and install it on the laptop.
2. Stop the networked client.
3. Use the networked client to fetch a fresh buff-in.rc5
4. MOVE the buff-in.rc5 to floppy.
5. Start the networked Client again.
6. Sneakernet the floppy to the laptop.
7. Run the laptop client using the "-import [buffer filename]" option.
8. The laptop client will import the buffer.
9. MOVE buff-out.rc5 from laptop to floppy.
10. Start the laptop client.
11. Sneakernet the floppy to the networked machine.
12. Stop the networked client.
13. Flush the networked client.
14. MOVE the buff-out.rc5 from floppy to networked machine.
15. Start the networked client.
16. Repeat.