BugTraq.Ru
Русский BugTraq
https://bugtraq.ru/dnet/faq/client/

Клиентская программа

Информация о клиентской программе distributed.net, устанавливаемой на машинах участников.

Установка, конфигурация и массовая установка

Общие вопросы по взаимодействию клиента с сервером

Модемное соединение

Общие стартовые вопросы

Частично обработанные блоки, возобновление работы

Производительность

Перенос на другие платформы

Разное


[http://n0cgi.distributed.net/faq/index.cgi?file=40]
Существует ли базовое руководство по установке клиента?

Yes there is.
You can find the "client download, configuration and operation" tutorial at:
http://www.distributed.net/docs/tutor_clients.html


Как запустить клиента?

Simply start the client from the directory you put it in.
If you have never run a client from that directory before, the client will automatically start in "configuration mode". Change the configuration as desired, save and quit when done. Then restart the client.


Как удалить клиента из системы?

If you are uninstalling an unauthorized installation of dnetc, please e-mail help@distributed.net so we can fully enforce our policies on unauthorized installation, and so we can provide you with the most current information.




Как запустить Windows-клиента с иконкой в трее?

Instead of using the -hide, -quiet, or -install parameters, create a shortcut to DNETC.EXE in your startup folder.
Once you have created the shortcut, edit its properties and set the Run: dropdown to "Minimized."


Автоматический запуск клиента при загрузке системы

Many clients support the -install switch to have the client set itself up to start automatically when the machine is booted. Others do not support this feature, and must be manually inserted/deleted from the boot sequence scripts. Those client that do support -install, also support -uninstall to stop the client from automatically starting.

Before configuring the system to launch the client on boot, please ensure that it can start normally.

Note: many clients provide some form of feedback on successful -install and -uninstall. To suppress those messages, use the -quiet switch, but make sure to specify it *before* the -[un]install switch (for example: dnetc -quiet -install), because the options that follow -install are the ones that the client is then 'installed' with (this feature is not available everywhere).

Special notes:
(Answer) MacOS
(Answer) OS/2
(Answer) Windows (32bit)
(Answer) Unix
(Answer) (Category) distributed.net Faq-O-Matic : (Category) the Client software : (Category) Automatically starting the client at boot time : (Answer) MacOS MacOS client distributions include an AppleScript that you can place in your Startup Items folder to cause the client be launched and the "Hide dnetc" option in the Applications Menu to be automatically activated. The client is still visible and can be re-activated from the Applications Menu however.

Alternatively, if the MacOS FBA (faceless background application) version of the dnetc client was distributed with your MacOS download, then you may use that version. The FBA version completely lacks any user interface at all, and will not even be visible from within the Applications Menu.

Newer distributions (2.8012.466+) of the client for MacOS may include a client that runs as a system extension. This enables the client to be launched before the finder starts and run without a user interface.
(Answer) (Category) distributed.net Faq-O-Matic : (Category) the Client software : (Category) Automatically starting the client at boot time : (Answer) OS/2 The client for OS/2, unlike most other clients, does not insert itself into the boot up sequence. Instead, it creates a shortcut in the startup folder.

(Answer) (Category) distributed.net Faq-O-Matic : (Category) the Client software : (Category) Automatically starting the client at boot time : (Answer) Windows (32bit) 32bit Windows clients are capable of running as 'services', which start when the machine starts, and don't shut down until the machine does. (ie, they survive logouts). The -install option configures the system to launch the client as a service the next time the machine is booted.

Although services on Win9x and WinNT are dramatically different in terms of implementation, dnetc attempts to make the behavior between the two environments approximately equal.
Note that the (WinNT) client cannot run with "Allow service to interact with desktop" enabled. This is because when the client starts, it does not know whether it was started as a service or not (it does not depend on the -svcrun switch). If it tried to initialize itself as a service, and wasn't actually started as a service (from 'net start' or whatever), it would take ages to start. So, since, under normal circumstances, the shell isn't active/visible when the service starts, it uses this condition as an indication of whether it should try to initialize itself as a service or not.

In order to reduce its footprint and other overhead, the client runs with an implicit -quiet when started as service, so, even if it did not use the check-for-shell described above, you wouldn't see anything.
The distributed.net client will fail to start as a service if the directory is marked for encryption. This limitation applies not specifically to the distributed.net client, but to any service or process that is running from a different logon context than the user the file is encrypted to. Encrypted directories and files can only be accessed by the user who created them, and services generally are started from within the "LocalSystem" user context.

Explicitly unencrypting each of the individual files within the directory is not sufficient, since new files created in that directory by the client will inherit the encryption from the parent directory.

Configuring the service to login as me (instead of as LocalSystem) seemed to fix it, but the safer approach is to keep the distributed.net client in an unencrypted directory, where no parent directory is encrypted either.

This limitation will also be apparent if you ever try to encrypt your Windows directory itself, or the base "Documents and Settings" directory (that contains the profile directories for multiple users, not just yourself), or the root directory of a hard drive that contains things that multiple users or the system itself needs to access. Generally speaking, only sensitive documents should be encrypted, and not application directories, or entire hard drives.
Older clients (<=.463) running as a WinNT service had a problem detecting modem connections. This is no longer an issue (it continues to be one for perproxy though), and to ensure that newer clients update their dependancy tables, you will need to re-"-install" the client.

Although not specific to NT service, be sure that the interface name that you've told the client to monitor is the correct interface name of your modem connection. However, typing the interface name incorrectly will prevent the client from detecting your modem connection when running as an NT Service or as an interactive process.
(Answer) (Category) distributed.net Faq-O-Matic : (Category) the Client software : (Category) Automatically starting the client at boot time : (Answer) Unix All Unix systems are capable of starting the distributed.net client from a boot script or script in a boot script directory.

The quick and dirty way:

The long way:


This was submitted by Marc Barilley (barilley@noos.fr), and apparently works on Mandrake (but should work as well on RedHat).


Here it is. Distributed.net client is supposed to be in /home/dnetc and a user called 'dnetc' must exist on the system. The script launches dnetc as user 'dnetc' instead of 'root'. This is to controll the user's rights.

#!/bin/sh #Source function library. if [ -f /etc/init.d/functions ] ; then

   . /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ] ; then
   . /etc/rc.d/init.d/functions
else
  exit 0
fi
RETVAL=0
start() {
 echo -n "Starting Distributed.net client: "
        if [ -f /var/lock/subsys/dnetc ]; then
  failure
  else
   daemon --user=dnetc /home/dnetc/dnetc -quiet
   RETVAL=$?
          [ $RETVAL -eq 0 ] && touch /var/lock/subsys/dnetc || RETVAL=1
  fi
  echo
        return $RETVAL
} stop() {
 echo -n "Shutting down Distributed.net client: "
 killproc /home/dnetc/dnetc -TERM
  RETVAL=$?
  echo
         [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/dnetc
         return $RETVAL
}
if [ -x /home/dnetc/dnetc ]; then
 case "$1" in
   start)
        start
      ;;
   stop)
    stop
    ;;
   restart)
    stop
    start
    ;;
   status)
    status /home/dnetc/dnetc
    ;;
   *)
    echo "Syntax: $0 [start|stop|restart|status]"
    exit 1
    ;;
  esac
fi exit 0


Какие параметры командной строки поддерживает клиент?

Starting the client with /? or -? or -h or --help (or any unrecognized word actually) will give you a list of valid command line switches.

eg: dnetc --help

Although not recommended since it is then a 'static' reference, the output of -help can be redirected to a file on all OSs except those that don't support redirection (NetWare), or those that only have a GUI (MacOS, Win16).

On 32bit Windows, for instance, 'dnetc.com -help > dnetc.hlp.txt' will work just fine.


Можно ли сконфигурировать несколько клиентов/машин, использующих один и тот же идентификатор dnet(почтовый адрес)?

Yes, multiple clients/machines may "share" the same distributed.net ID (email address).

It is also possible to specify individual addresses of course, and has its own set of advantages and disadvantages: Specifying multiple addresses may become cumbersome and difficult to track, particularly if you are maintaining a large number of computers. On the other hand, specifying separate email addresses has the advantage of allowing the stats server to show you block count information that is specific for each machine you are running the client on.


Как заставить клиент использовать все процессоры на многопроцессорных системах?

Most clients can take advantage of multiple processors, and those that do, will by default run with as many threads as there are processors.

The clients that cannot take advantage of multiple processors even when the OS supports it, do so because of library or compatibility issues. Clients that fall in this category are HP/UX, SunOS 3, and Linux/S390. Under such circumstances, run one instance of the client per processor.



Как автоматически установить/обновить клиента на нескольких машинах, входящих в локальную сеть?

Some systems that other people have successfully used include:

If anyone has experience or advice with deploying the distributed.net client in these manners or any other way, your comments in this section would be welcome.
I put the following in my NT login scripts to install dnetc as a service (located in the root of the windows directory) on both 95 and NT workstations. If your users do not have rights to install an NT service on their machines, then you'll need to use a utility like RemoteCows (available on the dnet site) to deploy dnetc on NT workstations.
The following works for NetWare startup scripts as well.
REM dnetc install
SET INSTALLDIR="%windir%\dnetc"
IF EXIST %INSTALLDIR%\dnetc.exe GOTO ENDOFSCRIPT
COPY \\server\sharename\dnetc.exe %INSTALLDIR%
COPY \\server\sharename\dnetc.ini %INSTALLDIR%
%INSTALLDIR%\dnetc.exe -quiet -install
%INSTALLDIR%\dnetc.exe -svcstart [1]
:ENDOFSCRIPT
[1] newer clients support -svcstart (for both 9x and NT) to start a client previously installed as a service. Older clients require:

IF "%OS%" = "Windows_NT" GOTO NTSTART
rem win9x can't start services from the command line
rem so start it hidden
%INSTALLDIR%\dnetc.exe -hide
GOTO ENDOFSCRIPT
:NTSTART
net start dnetc

As a warning for users of windows9x/ME who might be attempting to upgrade clients with "dnetc.exe -quiet -shutdown", copying a new client in place, and then restarting it...:

You will likely want to use "start /wait dnetc.exe -quiet -shutdown" since 9x/ME will typically not wait for GUI processes to run and finish before moving onto the next line in your batch file.


Как задать разные настройки для клиентов, запускаемых с разделенного сетевого диска?

By default the client looks for an .ini file (where client configuration information is stored) with the same name (and directory) as the client [1]. You can make the client use a different .ini file with the '-ini ' switch.

Thus, 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 solution would be to have all machines sharing one copy of the client, where they would all end up sharing the same .ini file.

[1]On OSs where the client's directory cannot be determined when the client is in the search path, the client will use the current directory.
Alternatively, you could create local batch files/scripts/shortcuts/etc. (depending on OS) that execute a common client w/ different -ini options on the command line, either pointing to a local .ini file or to a bunch of different .ini files w/ different filenames on the network drive. Even more elegantly, if the path to the local .ini file is the same across all machines running from the shared volume, you could have one batch file/script/shortcut on the shared volume that points to a local .ini file w/ a custom configuration.


Существует ли базовое руководство по взаимодействию клиента с сервером?

Yes there is.
You can find the "client networking" tutorial at:
http://www.distributed.net/docs/tutor_netopt.html


Что, если я нахожусь за межсетевым экраном?

All clients support SOCKS4 and SOCKS5, as well as allow communications to go through HTTP proxies.

For a large number of machines behind a firewall it may be simplest to run a personal proxy within the firewall through which all client machines will transfer keyblocks.

If you suspect that your computer is being blocked by a firewall, it can be helpful to see how your web browser is configured. If you can figure out how it manages to talk freely with the world then perhaps the same strategy can be used for the client. For instance, from within Netscape you can select "Options" / "Network Preferences" and see if it is configured to communicate through a firewall. Often, you can just take this information and plug it directly into the client and everything will work perfectly.
Consider also looking at the following document:
http://www.distributed.net/docs/tutor_netopt.html#no_firewall


Как заставить клиент осуществлять запуск/остановку/передачу блоков и т.п. по расписанию?

Simply use the schedule facilities within your operating system to script executions of "dnetc -pause" or "dnetc -unpause" or "dnetc -flush" (or whatever).

Virtually all operating systems support crontab or "at" events. Win9x systems can use the "Scheduled Tasks" feature.


Почему я получаю сетевые ошибки, или ошибки с распознаванием имен хостов?

The most common reason is because you are located behind a firewall and the client can't get directly out to the internet. There are work arounds as described in the next section. Intermittent network errors can also occur due to poor conditions on your LAN, poor phone lines, or heavy traffic on the internet itself. There have been some problems with earlier versions of the client being overly sensitive to response times. These problems have been mostly resolved.
If you are getting "Unable to resolve..." messages from the Linux client, you may be having a compatibility problem with the "glibc" library. There are two common, incompatible versions of glibc: glibc2.0 and glibc2.1. You will notice that there are two Linux clients with "glibc20" and glibc21" in their file names. You must choose the correct version in order for name resolution to work. If you are not sure which glibc version you have, just try the other client to see if it works better.

Starting with build v2.8008-459 of the client, there is now a single unified Linux binary (for each processor architecture type), instead of separate ones for each architecture and library combination. The name resolution incompatibilities have been worked around by using "clever" dynamic symbol loading techniques, but this didn't work very well (problems ranged from segfaults to hanging threads to simply not-working).

So, from 2.8011-463 on, the client does not even bother trying to work around the insanity introduced by glibc, and instead pipes/parses the output of 'host'.
I noticed that (at least on Unix) a running client does not take any notice if you change DNS servers. Look out for spurious UDP packets to the old nameserver (netstat -tn), and a failure to flush buffers once the old nameserver has packed up and gone home. Restarting the client will fix this. This applies to any application that uses the ISC resolver, which only loads /etc/resolv.conf (into static storage) once.
If you find that your Linux client is reporting this error, it's because you do not have the bind tools installed on your computer. Look for a "bind-tools" binary package in whichever packaging format is appropriate for your particular flavor of linux.

Unfortunately, the only alternative to requiring bind-tools would be for distributed.net to release multiple, conflicting versions of the client for all the various libc permutations that exist.
To simply set the address manually, also solves the problem. By using nslookup or ping, I found the IP address of the name it failed to resolve. Then it was just to start the client with:

$ dnetc -a 145.89.128.249

If they change the ip address, or that server goes down, the client will fail. So I have the client running in a detached screen. And I check the output from time to time.

[Ed: This solution is not recommended.]

You can also setup dist.net to run offline, and setup a cron job to grab the IP of the keyserver and update the cache hourly. You may have to adjust the grep/sed expressions depending on your local flavor.

/usr/local/dist.net/dist.net:
#!/bin/bash
# script to start, stop, restart, or update cache for the dist.net client
# is dist.net client on?
distnetON=$(ps --no-headers -o %c -C dnetc)

function start() {
  # run dist.net client offline
  /usr/local/dist.net/dnetc -quiet -runoffline
  echo "Started distributed.net client"
}

function stop() {
  /usr/local/dist.net/dnetc -quiet -shutdown
  echo "Stopped distributed.net client"
  sleep 2
}

function update() {
  # ping the keyserver, grab the ip from the output, and update the caches
  /usr/local/dist.net/dnetc -quiet -update -a $(ping -n -c 1 us.v29.distributed.net | grep \( | sed -e 's/^PI.\+\.net (//g' -e 's/) fro.\+$//g')
}

if [ -x /usr/local/dist.net/dnetc ]; then
  case "$1" in
  start|restart)
    # make sure that there are no clients running
    if [ "$distnetON" = "dnetc" ]; then stop; fi
    # now start it up
    start
    ;;
  stop)
    if [ "$distnetON" = "dnetc" ]; then stop; fi
    ;;
  update)
    if [ -e /var/smoothwall/red/active ]; then update; fi
    ;;
  *)
    echo "Syntax: $0 [start|restart|update|stop]"
    exit 1
    ;;
  esac
fi
exit 0
/etc/cron.hourly/updateksip:
#!/bin/bash
# cron.hourly script to update the dist.net clients key server IP address

# if dist.net client not running, then start it
if [ "$(ps --no-headers -o %c -C dnetc)" != "dnetc" ]; then
        #/usr/local/dist.net/dist.net start;
        echo "not running"
fi

# check if red interface is connected
if [ -e /var/smoothwall/red/active ]; then
        # update in/out caches
        /usr/local/dist.net/dist.net update

        # write to smoothwall log
        logger -t smoothwall "dist.net: cache updated"
fi
exit 0

Just put the dist.net file in the directory where your dist.net client is, and adjust the paths, and it should work.




Как подключить к работе компьютер, не имеющий сетевого подключения?

To simplify these directions, assume that "Laptop" refers to the non-networked machine. On the networked machine:

  1. Ensure buffers are full
  2. MOVE the buff-in.* (look where you installed the client) to floppy.
On the laptop:
  1. Download the client and install it on the laptop.
  2. Set a "Checkpoint file" on the laptop (for example, use ckpoint.cp)
  3. Sneakernet the floppy to the laptop.
  4. For each buff-in.* file on floppy...
    1. Stop the Laptop client.
    2. Run the Laptop client with the "-import" option and specify the filename of the buff-in.* from your floppy. This will merge the in-blocks from the floppy into your Laptop's existing buff-in, preserving the blocks it already contains.
    3. MOVE the matching buff-out.* from laptop to floppy.
    4. Start the Laptop client.
  5. Sneakernet the floppy to the networked machine.
  6. flush buffers.
  7. MOVE the buff-out.* from floppy to networked machine.
  8. flush buffers again.



Можно ли получить/отправлять даныне по электронной почте?

Yes you can! If you are sneakernetting clients, or you are having problems with the client connectivity through a firewall you can always get (fetch) and send (flush) work units via email.

You actually would send or be sent a complete buffer file.

Up-to-date instructions can be found by sending a blank email to:
   fetch@distributed.net and/or
   flush@distributed.net


Можно ли организовать совместный доступ по сети к файлам с заданием?

Yes! The clients are designed for this and the file locking that exists in network file systems will prevent multiple clients from updating a buffer file at the same time. The client implements file-locking and automatic retrying so that it is pretty safe to allow multiple computers access the same buffers at the same time time.

Examples of supported file sharing mechanisms include Windows file-sharing (SMB/SAMBA), UNIX NFS, Netware server volumes, AppleShare, and others.

This is in fact one of the recommended ways if you have a small number of machines that are not directly connected to the Internet, but have at least one machine that is connected and can share a buffer file to the others.

However, if you have more than 20 or so machines, then you may want to consider running a personal proxy on the "Internet-connected" machine, and allow all of the other computers to retrieve blocks from the proxy.
Be sure to understand that while it is possible to share input and output buffers between multiple clients over network filesharing, checkpoint files must not be shared! This is very important, because doing so will cause all of your clients to do the same duplicated (wasted) work.

To work around this, you can either disable checkpointing entirely, or set the checkpoint file to be saved to a path that is local (or at least different) for each machine.


Я сконфигурировал клиента так, чтобы он использовал блоки определенного размера, но заметил, что иногда забираются блоки меньших размеров.

The block size is really only a "request" by the client. Depending on the fragmentation of the current keyspace we are working on, the keyproxy may be forced to give you a block smaller than requested. This is not a problem, just an oddity.


Клиент пытается запустить автодозвон, но это ему не удается из-за того, что требуется пароль.

If the client is auto-dialing itself (or triggering your Operating System to automatically dial) too frequently, then that is because it does not have enough work to process during the time that you are offline. So you need to configure the client to keep enough workunits ready so that it will not run out. See the link below for information about how to configure your work thresholds.
Additionally, since your dialup requires a password, it is silly to allow the client to ever trigger auto-dial by itself. Therefore, you should configure the client to use the "Lurk-Only" mode, that is described in the link below.
This question has already been answered with this post:
(Xref) I use a modem. How can I get the client to download enough packets?



Я использую модем. Как заставить клиента скачивать достаточное количество пакетов?

The client actually cannot be configured to download a specific number of workunits--you instead configure how much "work" it try to maintain. When the client makes network connections, it will fetch enough additional workunits to fill itself up to that specified level.

The amount of work can be configured by specifying either one of the following for each contest:

a) number of workunits to buffer for that contest. Once you've determined how long it takes your computer to process a single workunit, you can approximate how many you will need to last the timeperiods when you are disconnected from the Internet. This value is set in the "Fetch work threshold" option in the client configuration.

b) number of hours to buffer for that contest. This will allow the client to do a quick-benchmark the that it can estimate how many workunits it will need, saving you the trouble of doing the above calculation yourself. This value is set in the "Fetch time threshold" option in the client configuration. (Note that you must be sure to set "Fetch work threshold" for that contest to "-1" for the "Fetch time threshold" to be obeyed).

One last note for modem users. It is beneficial to enable the "Lurk-only" mode. This is available under: "Buffer and Buffer Update Options" / "Keyserver-client Connectivity Options" / "Modem Detection Options" / "Dial-up Detection ONLY mode".

"Dial-up Detection ONLY mode" will ensure that your client AUTOMATICALLY updates the total number of packets it has to process when you connect to the Internet. (That is, it will not ever trigger an autodial by itself--it will wait for you to establish an Internet connection.) At the same time, it also will automatically send back all completed data packets. This is all done without any intervention on your part
If you don't mind allowing the client to occasionally cause an auto-dial, then instead of "lurk only" mode, try the "lurk" mode ("dialup detection mode"). In that configuration, the client will opportunistically fetch/flush when it sees your modem is connected. However, it will also automatically dial (and automatically disconnect when done) if it ever runs out of blocks.

If you configure reasonable enough work thresholds that match your normal dialup usage behaviors, then the client will not usually need to make connections by itself because it will already have enough blocks.


Клиент пытается дозвониться слишком часто, или не прерывает связь.

If the client is auto-dialing itself (or triggering your Operating System to automatically dial) too frequently, then that is because it does not have enough work to process during the time that you are offline. So you need to configure the client to keep enough workunits ready so that it will not run out. See the link below for information about how to configure your work thresholds.
If your client is causing your Operating System to auto-dialing your network connection for you, but the client doesn't ever disconnect your modem, then that is because you have not told the client that you have a dialup connection. See the link below for information about how to configure the "lurk" or "lurk only" mode.
This question has already been answered with this post:
(Xref) I use a modem. How can I get the client to download enough packets?


Как забирать достаточный объем данных для оффлайновой работы?

My network is not connected to Internet permanetly, it's on dialup. Often it is not online for a couple of days, so when i check my clients, they have begun to work on random keys.
This question has already been answered with this post:
(Xref) I use a modem. How can I get the client to download enough packets?


Что-то я запутался во всех этих ключах, юнитах, узлах, пакетах, блоках...

Terms used by the distributed.net client

Obsolete, historical terms:

The first and second generation of clients ran only crypto-projects: RC5 and DES. These two projects were sponsored by RSA and had a winner (and the prospect of monetary award), and as such were called contests.

Since a computer is capable of processing many hundreds of thousands of RC5 and DES keys per second, counting in single keys quickly becomes onerous, and the very first generation of clients introduced the unit of 228 keys, as a handier unit of measure. These first generation clients worked solely with this number, both as the number of keys it sent/received/processed as well as the number of keys used to represent "effort", or the "unit of of work" done, and what was displayed on the stats server. Consequently, this number of keys came to be known as a work-unit.

The second generation of clients introduced the ability to send/receive/process many more than 228 keys at once. For the purpose of (backwards-compatibility and) statistics, the 228 key "unit of of work" retained its meaning, but the term used to represent the number of keys being sent/received/processed at once had to be changed. Since the number of keys being sent/received/processed continued to be a multiple of 228, the unit being sent/received/processed was called a "block of work-units", or in short, a block.

With the introduction of non-crypto projects such as OGR, the terms contest, work-unit and block had to be reconsidered. OGR neither had a winner, nor did it use keys, nor did it have a fixed number of iterations ('keys' in crypto-parlance) per "unit-of-work", nor could multiple "units-of-work" be combined into "blocks of work-units" for sending/receiving/processing. Indeed, for OGR, there was a tendency to revert to the older meanings, since a stub is a work-unit in the oldest sense of the term, both as a literal "unit of work" and as the unit that is sent/received/processed.

To overcome this confusion, more generic terms project, stats-unit and packet came to replace the older contest, work-unit and block respectively.
  First Generation Term Second Generation Term Current Term
endevour/undertaking contest contest project
unit used by stats work-unit work-unit stats-unit
unit sent/received/processed work-unit block packet

However, old habits die hard, and the old and new terms are often used interchangeably. While not technically correct in the generic sense, the old terms are still perfectly valid for the crypto-contests, errr... crypto-projects. :)


Клиент использует 100% процессорного времени!

No, its not.

Unless configured otherwise, the client only uses *idle* time, ie, the cpu time that would go 'wasted' because no other task or application wanted it.

While you're watching cpu time statistics, you aren't doing anything else that might be consuming cpu time, and consequently you see the client using 100%. If however you were to have another task running in the background that needed/was using cpu time, you'd see the client use that much less.


Клиент переключается между различными проектами вместо того, чтобы работать над тем, который я указал первым.

This is intentional behavior.

The client's configuration includes a "load-work precedence" setting that allows you to select the load order (and optionally disable specific ones). However, this setting does not prevent the client from working on other available contests if it does not have any more "ready work" for any of your earlier priority contests.

Notice that the normal behavior of the client is to not automatically attempt to fetch more blocks (for any contest) until blocks for all enabled-open contests have been depleted. Because of this, if you do not like the fact that your client is not working "solely" on the first contest that is enabled and open, you can do any of the following:




Как заставить клиента работать X% времени над OGR и Y% - над RC5?

> how can I tell the client to spend 50% of time doing OGR and 50% doing RC5 .. ?

time:you can't and neither can the client. Its not possible to predict how much time it takes to do an OGR packet.

packets: But, if you were to count in completed packets rather than time, then all you'd need to do is ensure that the thresholds are equal, and over the long run client will do 50% OGR and 50% RC5.
Obviously, if you wanted to crunch, say, 20% RC5 and 80% OGR, you'd simply set the OGR thresholds to be 4 times that of the RC5 threshold.

If you want to work in just one project, simply disable all but that one project. For more information, refer to the description under Load-work precedence under the Buffer and Buffer Update option of the configuration menu.


Что происходит при перезагрузке (или зависании машины)? Теряются ли блоки?

Normally the client is able to shut down cleanly, the block is saved and will be resumed at the point it left off when you restart it later.

However, in the event that your computer crashes or you lose power and the client is not able to properly save its place. Blocks that have not been returned to the keyservers will eventually be redistributed. In order to accommodate slower clients and to minimize duplication of work there is a long period after which a keyblock is assigned, minimally 90 days. If we reach the end of the keyspace without finding the winning key, we will start back at the beginning and assign the unreturned blocks.
One other way to make sure your computer doesn't lose it's work even when your computer crashes and you have to reboot is to use a checkpoint file. [In the client configuration under "Buffer and Buffer Update Options" >> "Checkpoint Filename"].

This checkpoint file will keep track of your work and update itself every few minutes. If your computer does crash (or you have to do a sudden reboot) the client can pick up almost right where it left off and not lose or discard a data packet.
In some short term projects, such as DES, blocks may be reissued in less than 90 days. In these situations it best to keep your buffers small to avoid duplicated effort. When such projects are underway please check back the .plans frequently to monitor the status.


Клиент показывает неверное время.

The time reported by the clients is based on your computer's internal clock however it is converted to and reported in UTC: see (Xref) What is UTC? Is that like GMT or something?. This makes comparing logs and updating the stats simpler.


Что означает буква R в полоске с результатами?

A 'R' in the middle of a percentage bar stands for 'resume'. This is the point at which the client was working on last time it was shutdown; it just resumed and jumped to that point in the block. Note that as a result of not having to process the entire block, resumed blocks will be processed faster than normal blocks; the time difference this makes obviously depends on where in the block it resumed.


Только что были обработаны два блока с R, как такое возможно?

Partially completed blocks can be 'buried' in the buff-in.* files; if you routinely shut the client down and then fetch new blocks, new, full blocks will be added to the buff-in.*. The partially completed blocks will not resurface for a while, perhaps a couple of days.


Что означает сообщение "Read



  Copyright © 2001-2024 Dmitry Leonov Design: Vadim Derkach