|
Клиентская программа
Информация о клиентской программе distributed.net, устанавливаемой на машинах участников.
Установка, конфигурация и массовая установка
Общие вопросы по взаимодействию клиента с сервером
Модемное соединение
Общие стартовые вопросы
Частично обработанные блоки, возобновление работы
Производительность
Перенос на другие платформы
Разное
- Существует ли базовое руководство по установке клиента?
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.
- Ensure that it is not running by starting the client with the
'-shutdown' switch. eg 'dnetc -shutdown'. Under Unix, you may wish
to kill(1) all instances of 'dnetc'.
- Windows: If it is installed as a service, uninstall it by running the
client with the '-uninstall' switch. If you're not sure do it anyway.
- Unix: The client may have been 'installed' to start automatically (see
 Unix) and
may require some steps to 'uninstall' it. Refer to the above mentioned
URL for more information.
- If the client was installed in its own directory then simply delete
that directory and all its contents.
- If the client is not in its own directory, you will have to find and
delete the following files manually. They will probably all be in the
same directory. There may also be log files in this directory.
dnetc.*, buff-in.*, buff-out.*, rc5des.*, rc5desg.*
- Windows: If there is a dnetc.scr in the windows or windows/system
directory delete that too.
- Unix: Maybe check the user's crontab if he scheduled the program to
run at certain times.
- Как запустить 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:
 MacOS
OS/2
Windows (32bit)
Unix
 distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time :
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.
distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time :
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.
distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time :
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.
distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time :
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:
- On BSD systems (FreeBSD, OpenBSD, NetBSD, BSD/OS, MacOS X etc):
simply add '/path/to/dnetc -quiet' to /etc/rc.local
- On SysV systems (UnixWare, Linux, Solaris etc):
simply add '/path/to/dnetc -quiet' to /etc/rc.d/rc.local
Note that this is not a good thing to do on SysV since the OS will
simply kill the client when it shuts down (to be more precise, it will
send a SIGTERM first, but a SIGKILL almost immediately after it).
The long way:
- On BSD systems, each application may have its own startup script. These are generally located in /usr/local/etc/rc.d/. A script to start the client
could look something like this:
#!/bin/sh
if [ -x /path/to/dnetc ]; then
/path/to/dnetc -quiet
echo -n " dnetc"
fi
The client will be stopped with a SIGTERM when when the machine is shutdown or
rebooted.
- SysV systems have a more complex init/shutdown sequence. Your OS probably
has a man page for it. init(8) usually, 'apropos init' may show more.
[2.8011-464 and above support -[un]install for Linux (SysV-style)]
Create a file called '/etc[/rc.d]/init.d/dnetc' that looks like this:
#!/bin/sh
if [ -x /path/to/dnetc ]; then
case "$1" in
*start)
#make sure we're only running one client
/path/to/dnetc -quiet -shutdown
/path/to/dnetc -quiet
echo "Started distributed.net client"
;;
*stop)
/path/to/dnetc -quiet -shutdown
echo "Stopped distributed.net client"
sleep 2
;;
*)
echo "Syntax: $0 [start|stop]"
exit 1
;;
esac
fi
exit 0
Then create a symlink in each of the /etc[/rc.d]/rc?.d/ subdirectories
as follows:
For the 0, 1 and 6 runlevels (halt, single-user and reboot
respectively):
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc0.d/K10dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc1.d/K10dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc6.d/K10dnetc
For the 2, 3, 4 and 5 runlevels:
(runlevels 7, 8 and 9 are also valid, but not many
unix variants have them)
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc2.d/S90dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc3.d/S90dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc4.d/S90dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc5.d/S90dnetc
On entering a new runlevel, init(8) will run the scripts in
the /etc[/rc.d]/rc<runlevel>.d/ directory of
the runlevel it is entering. 'K' scripts are 'kill' scripts,
and will be run with the "stop" command. 'S' scripts
are 'start' scripts, and will be run with "start".
More on how scripts are processed may be found in your init(8)
man page.
According to the above described scheme then, the client will
be started on entry into runlevel 2, 3, 4 or 5, and stopped
on entry into any other runlevel.
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:
- Novell ZenWorks
- Microsoft SMS
- Standard NetWare/WindowsNT login scripts
- Windows 2000 Microsoft Installer packages (*.MSI)
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:
- Ensure buffers are full
- MOVE the buff-in.* (look where you installed the client) to floppy.
On the laptop:
- Download the client and install it on the laptop.
- Set a "Checkpoint file" on the laptop (for example, use ckpoint.cp)
- Sneakernet the floppy to the laptop.
- For each buff-in.* file on floppy...
- Stop the Laptop client.
- 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.
- MOVE the matching buff-out.* from laptop to floppy.
- Start the Laptop client.
- Sneakernet the floppy to the networked machine.
- flush buffers.
- MOVE the buff-out.* from floppy to networked machine.
- 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:
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:
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:
I use a modem. How can I get the client to download enough packets?
- Что-то я запутался во всех этих ключах, юнитах, узлах, пакетах, блоках...
Terms used by the distributed.net client
- project: A long-term endevour in order to accomplish a specific, clearly defined goal. RC5, DES, OGR, CSC are all distributed.net projects. All distributed.net clients supports at least one project,
and all recent clients are capable of processing data from multiple projects simultaneously.
- core: The code in a client that is responsible for processing the
data associated with a project. Each project that a client supports may have multiple cores associated with it (each core is then optimized for a specific processor or processor family/group).
- iteration: An iteration is a generic term used to denote the
smallest unit of work processed by a core. For crypto projects (RC5, DES, CSC) this is a key, for OGR it is a node.
- key: This is the smallest unit of measurement that can be checked by the client for cryptographic projects (RC5,DES,CSC). Each key represents one possibility of the solution. (for DES contests, each key actually represents two possibilities since each key and its opposite [complement] are automatically checked at the same time). Individual keys can be checked relatively quickly by your computer, usually several hundred thousand per second.
- node: This is the smallest unit that is individually checked by the client for OGR. A typical desktop computer may be able to check a million nodes per second. Each node represents a single golomb ruler possibility.
- stub: Stubs represent groups of OGR nodes that need to be checked. The number of nodes within a stub cannot be precisely determined in advance, ergo the amount of time needed to complete a given stub cannot be determined either. In general, stubs whose marks sum to a smaller total will take longer to check.
- stats-unit: a quantum of fixed size, used for stats and nowhere else.
- For crypto-projects (RC5, DES, CSC) a stats-unit is
228 or 268,435,456 keys.
- For OGR a stats-unit is 1 billion nodes
(one Gnode).
- packet: a discrete unit of work which will be processed. Clients send, recieve and crunch in terms of packets. A packet may be composed of any number of stats-units, including fractional portions thereof.
- RC5, DES, and CSC packets have anything from
1*228 to 32*228 keys.
(ie, 1 to 32 stats-units)
- An OGR packet has exactly one stub, and
that stub may have any number of nodes.
(ie, 0.01 to N.nn stats-units)
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:
- Disable all of the non-desirable contests (by going into the "Load-work precedence" and setting the other contests to "=0"). Note that if the contests left enabled are ever "closed" or "ended" by the server, your client will go completely idle, since it has nothing to do. You will have to remember to manually re-enable another available contest when that occurs to allow your client to resume working. For example: "rc5,ogr=0,csc=0"
- Make sure that your client never runs out of blocks for your preferred contest. This can be done by any of the following:
- Enable "update on current contest buffer exhaustion" (mode 4) under "Additional Buffer-level Checking" so that your client will perform an update when the last block of the current contest is loaded, instead of when the last block for all contests is loaded. This option was added in v2.8008-459 and is the preferred method of all of the following items listed below, since it does not cause your client to connect excessively to the server.
- Enable the "update frequently" option (mode 1) under "Additional Buffer-Level checking" so that your client will always keep its buffers "topped off". This will cause a network connection after every block that is completed/loaded.
- Manually trigger network updates before you run out of preferred contest blocks. This of course requires your to manually perform this action.
- If you have a dialup connection enable one of the "Dialup-link detection" modes (formerly called "lurk" and "lurk only") and go online more frequently than the time required to exhaust all of your preferred contest blocks. This will cause a network connection after every block that is completed/loaded while your modem is connected. These modes are available under the "Dialup-Link detection" menu.
- Как заставить клиента работать 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 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
|
подробно о проекте
Анализ криптографических сетевых...
