Distributed.net Client FAQ

Originally created by Cedric Tefft
Currently maintained by Matt Perry
Last update: July 2, 1998

First, a couple of items you should be aware of that may not be addressed by any of the individual questions below:

Always make sure you are using the absolute latest version of the client. Clients can be upgraded frequently and the problem you are experiencing may be fixed in the current release.
Buffer files from clients that predate the DESII project (v2.6x and earlier) are NOT compatible with the post DESII project clients (v2.7x). Unfortunately, you won't get a message from the client that the buffer file is of the wrong vintage. Problems caused by using the older buffer files are many and varied (not to mention extremely hard to diagnose). Make ABSOLUTELY SURE you delete or otherwise remove your older format buffer files before starting the v2.7+ clients.

1. General Questions

1.1: What does the "MT" and "NON-MT" in some of the client names mean?: MultiThreaded. Basically this means that the client can split off a separate thread to take care of network communications while the "cracking" thread keeps working on keys. Without multithreading the client has to stop cracking keys in order to communicate with a keyserver (or personal proxy). You can benefit from a multithreaded client even if you only have one processor, so you should only use the non-mt client if you can't get the multithreaded client to work. In general, Linux distributions with kernel versions above 2.0 will support the MT client (run "uname -r" to find out which kernel version you are running). Solaris has MT and NON-MT clients as well, but the author is unaware of the system requirements needed to run the MT clients under Solaris. Anyone?

1.2: My Win32 client seems to crack keys at a fair clip during the day, but the rate drops through the floor overnight or at other times when I'm away from the computer for long periods.: Your screensaver is probably kicking in and using up most of the cycles that would have gone to your client. The screensaver runs at a higher priority than the distributed.net client at all but the highest niceness setting. The workaround is to choose a screensaver that uses very little CPU time (like "blank") or no screen saver at all.

1.3: I keep seeing references to an 'exitfile'. What is it and how does it work.: By default, the client periodically checks its working directory for the existence of a file called "exitnow.rc5". If the client finds this file, it shuts itself down gracefully. Therefore, you can stop the client by creating this file. The contents of this file do not matter; the client is only checking to see whether or not it exists. Also, the client will not delete this file when it exits, so you must remember to delete it yourself before you run the client again.

1.4: I've been cracking blocks for X hours (days), but my email address doesn't show up in the stats!: First, stats are updated once every 24 hours at about midnight GMT. What this means to you is that you may have to wait up to 24 hours after a block is submitted before it shows up in the stats. Be patient. Second, check the email address in your .INI files. The line "ID=" in your client's .INI file should have your email address in it. Third, any email addresses with the following characters in them = " , \ < > will be considered invalid by the keyservers and get rewritten to rc5@distributed.net. Make sure your email address does NOT contain any of the characters in that list or you will not get credit for your blocks. Fourth, DESCHALL clients do not track email addresses.

1.5: Would it help randomize things more if I changed the value of the "randomprefix" parameter in my client's .INI file?: NO! Under no circumstances should you change this entry. This entry will be changed by the client when it determines a need to do so. This parameter is designed to maximize the efficiency of random block generation over the lifetime of the project. Changing it yourself might cause you to waste your own (or other's) cycles on duplicated random blocks.

: data

2. Windows 95/NT Clients

2.1: Why does the Win32 GUI client seem to freeze after calculating <x> blocks?: The window that holds the log output is limited to 32K. Once the buffer fills up, the client appears to freeze, though it's just the GUI window that's frozen. The client is still cracking keys. (* I think *) This has been fixed in the latest versions of the client. If you are experiencing this problem you need to upgrade your client to the latest version.

2.2: The Win32 GUI and NT Service clients don't seem to recover their checkpoint files on startup.: Older non-command-line clients did suffer from this bug. It was fixed as of version 2.6403.335

2.3: The Win32 client seems to lose blocks when I reboot my machine -- even if I shutdown gracefully.: For some reason, the Win32 clients do not seem to recognize a system shutdown as a signal to exit and therefore do not shut down gracefully. In other words, they do not write their in-progress blocks back to the in-buffer(s). The current workaround is to turn on checkpoint files.

2.4: Why is the Win32 GUI client slower than the command-line version?: The author doesn't know. But it IS generally agreed that the GUI client is slower than the corresponding non-GUI client (at least in the Win32 world).

2.5: How do I get a Win32 client to start BEFORE the user logs in?: Start REGEDIT. Traverse the registry tree to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runservices. Add a new string value named "bovwin32". Edit the string and set its value to the full path to the client (i.e. "c:\rc5des\rc5des.exe" or whatever accurately reflects your installation). You may include in the command line any options you wish to pass to the client (-hide, etc). In most cases, running the client with the "-install" option will accomplish the same thing, but it also adds the above mentioned string value to the "Run" key (at the same level of RunServices in the registry) as well as the RunServices key. The author is not sure what the benefit of adding this second string value is.

2.6: What is the difference between running the Win32 hidden client and running the command-line client with the "-hide" option?: The command-line client (rc5des.exe) with the -hide option briefly displays a DOS-box when starting in hidden mode. The hidden client (rc5desh.exe) does not.

3. Buffer Files and Blocks

3.1: Can I have multiple clients accessing a single set of buff-in and buff-out files?: Yes, they are designed specifically with this in mind.

3.2: Can I have multiple personal proxies accessing a single set of buff-in and buff-out files?: NO! The personal proxy buffer files are images of what the proxy holds in memory. If multiple proxies shared a single set of buffers, the buffer files would be completely overwritten by the last proxy to do a disk flush.

3.3: Can I have multiple clients share checkpoint files?: NO! Checkpoint files are overwritten by each client without regard to the contents of the checkpoint file already on disk (except at client startup time).

3.4: Can I use my pre-DES client's (v2.64x) buffer files with the latest clients (v2.7x)?: NO! - The buffer files of the v2.7 clients (and DES-aware personal proxies) are incompatible with previous versions' buffer files. You should flush your output buffer and delete (or otherwise remove) your 2.6x buffer files before running the v2.7 clients. Failing to do so will cause difficult-to-diagnose problems.

3.5: If I set my input buffer threshold higher than my output buffer threshold (10:5 or somesuch), will the first blocks I retrieved stay at the bottom of the buffer indefinitely?: Yes; unless the client is unable to replenish is supply of new (unprocessed) blocks. In classical computer science terms, the input buffer is LIFO (Last-In-First-Out) , meaning the blocks will be used in REVERSE order of when they were retrieved.

3.6: I think I submitted some of the same blocks more than once. Will that mess up the stats?: No. The first person to submit a block as completed gets exactly one credit for that block. No one (not even that same person) can get credit for completing that block again. Duplicate blocks just waste bandwidth.

3.7: What happens if I accidentally delete my input buffer or otherwise "lose" some blocks that I am working on?: If we get to the end of the keyspace without finding the key that unlocks the puzzle, the master keyserver will begin handing out keys that were handed out before, but not returned. In other words, the "lost" keys will be reincarnated and passed out again.

3.8: I fetched too many blocks. Is there any way to return the "unprocessed" blocks to the keyserver?: Not currently. If you must, for whatever reason, abandon your buffer files, you can rest assured that you will not kill the project if the *magic* key is in a block you threw away. (see previous question for more info).

4. Network Related

4.1: When my client tries to connect to a keyserver I get "Network::Error Read failed 6/0". What does that mean?: Specifically? We don't know. We've never been told exactly what the numbers after a network error mean. In general, we can tell you that the client had problems communicating with the keyserver (or personal proxy). About the only recommendation we can make is to check all the settings for the keyserver and other network communication parameters in your INI file and make sure they are correct.

4.2: I'm having trouble getting my client to communicate through the firewall. All my settings are correct.: Some people have been successful in working around firewall issues by setting their preferred keyserver to a SPECIFIC keyserver rather than the round-robin DNS entry. (http://www.distributed.net/rc5/proxyinfo.html). If you want to do a manual lookup on any DNS entry (like us.v27.distributed.net) you can do it via the web at http://ds1.internic.net/cool/dns.html.

4.3: Why do I keep getting network errors on the Alpha Linux client?: Apparently, the Alpha Linux clients have historically had problems resolving DNS names. The solution is to pick a specific IP address of one of the keyservers and set that as your preferred keyserver. This problem existed as late as the early DESII clients (v2.7001.x), and may continue to exist in the latest versions... anyone?

4.4: How do I get the client/proxy to talk through a Microsoft proxy server?: According to one of our participants:

We have a MS Proxy server here and I managed to get RC5/DES running through it.

Specify network settings as follows (CLI client):

9) Network Communication mode ==> 4
10) Preferred KeyServer Proxy ==> alde.com
(actually, any individual keyserver should work here, but alde.com works fine for me, us.v27.distributed.net will NOT work)
12) Local HTTP/SOCKS proxy address ==> <IP address of YOUR MSProxy server>
13) HTTP/SOCKS4 proxy port ==> <probably 80, look in IE settings if not sure (View, Options, Connection)>

Then enter your NT domain login and password under option 15. MS Proxy server uses NT domain security for all its logging and access restrictions.

5. Personal Proxies

5.1: Will the "old" (v2.6x) clients still work with the current keyservers and personal proxies?: Yes, the v2.6x clients can communicate with the current keyservers and personal proxies. The reverse, however, is not true: The new DES-aware clients do not work with the older (non-DES aware) personal proxies. (I imagine they wouldn't work with any of the older keyservers either, but as far as the author is aware, the keyservers were all upgraded).

5.2: Can I interchange my personal proxy's buffer files with my client's buffer files?: No. The buffer file formats are incompatible.

5.3: Why does my personal proxy only fetch RC5 blocks and not DES blocks?: With older versions (pre-276 builds) of the personal proxy, you needed to add "allowdes=1" on the tail end of the [DES-II] block in your rc5desproxy.ini. This is no longer necessary with the latest personal proxies (build 276 or later).

6. DES Related

6.1: I thought cracking DES keys was supposed to be much faster than cracking RC5 keys. So why does it take as long or longer to crack a block of DES keys?: For each key in a DES block, the client cracks the key AND its compliment (a logical NOT of the primary key). This means that the DES core is cracking twice as many keys as an RC5 block of the same size. The reason is that it's apparently more efficient to check a key and its complement in the same calculation rather than checking the two keys separately.

6.2: What's all this business with the block size (2^28, 2^29, 2^30,2^31) of DES keys?: Just what the terminology suggests. The block size is the size of a block of keys in terms of the number of keys in that block. Therefore, a 2^28 block represents 2^28 keys (268435456). Keep in mind, however, that the DES client would actually have to crack 2^29 keys in order to complete this block (see previous question). All RC5 blocks are 2^28 keys in length. DES blocks are of variable size, presumably, so faster clients don't have to buffer as many blocks as they might otherwise have to do given the increased speed efficiency of cracking DES keys (versus cracking RC5 keys).

6.3: The number of keys in a block is wrong in the log file. A block size of 2^28 is 268435456 keys, not 536870912 as reported in the log file.: This is not a bug. See the previous two questions.

6.4: What about 2^32 sized DES blocks?: The first versions of the dual-core RC5/DES clients allowed you to request blocks as large as 2^32 keys in size. Unfortunately, we discovered there is some kind of bug which prevents the clients from processing these blocks correctly. The latest clients (v2.7001.384 and up) have been coded to disallow requesting block sizes greater than 2^32 keys, but you should still manually set your preferred block size to between 28 and 31 just to be safe.

6.5: How does the switch between DES and RC5 contests work?: According to one of the client coders: If you configure DES as your preference, then... The client will attempt to download DES blocks. If that fails, it will download RC5 blocks. If that fails, it will generate a random RC5 block. The client will never generate random DES blocks.

6.6: Why do I get only one DES thread running on my multiprocessor system?: The initial release of the DES core is not multithread safe. In order to run multiple DES threads, you will currently have to run multiple copies of the client. The programmers are working to get around this limitation in a future release of the client.

6.7: I seem to get pretty much the same DES cracking speed no matter which CPU core I pick. Why is that?: The CPU core on Intel x86-architecture chips pertains to the RC5 cracking project only. Currently, there is only one DES core for all x86-architecture chips.

6.8: If the block size for the DES contest is variable, what size blocks are the stats pages (http://desstats.distributed.net) measuring?: Here's the simplest way to explain this: Stats use blocks normalized to a 2^28 block size. Thus if you turn in a 2^28 block, you get credit for exactly one block (yes, you only get one credit for a 2^28 block, even though you've cracked 2^29 keys). For a 2^29 block you get credit for TWO 2^28 blocks. 2^30-sized blocks are worth FOUR 2^28 blocks, and so on.