distributed.net - Networking options

ネットワーク接続オプション

はじめに

　ここでは、クライアントが処理のために必要なデータを受け取り、完了報告をdistributed.net鍵サーバへ返すための様々な手法について述べます。各セクションを良くお読みになり、自分の環境に最適と思われる手続きをクライアントに設定してください。

常時接続の場合（Always Online = 常時接続モード）

　（ファイアーウォールの内側ではない）LANや、ケーブル、DSL、ISDNなどを通じてインターネットに常時接続している場合、クライアントのネットワーク設定を変更する必要はなく、すべて初期設定のままでプロキシと交信することができます。

注意：ダイアルアップでインターネットに接続している方は、設定を初期状態である「常時接続モード」のままにしておかないでください。このままにしておきますと、クライアントはdistributed.netプロキシへの接続が必要なときにいつでもダイアルアップ要求を出してしまいます。この事が問題になる場合は、後述の「モデム接続待機モード」または「モデム接続完全待機モード」を選択してください。

モデムによるダイアルアップ接続の場合

　ダイアルアップ接続を行っている方は、ネットワーク設定オプションを初期状態から変更しなくても正常に鍵サーバと更新することができますが、接続モードの項目だけは、「常時接続モード」ではなく、以下に示す2つのモードのうちどちらかに変更しなければなりません。

モデム接続待機（Modem Dialup Lurk）モード: このモードは、モデムを使用してインターネットに接続していることを示します。ただし！　このモードでは、クライアントはdistributed.netプロキシへの接続が必要なときにいつでもダイアルアップ要求を出してしまいます。オフライン状態のときクライアントが勝手に接続要求を出されては困る場合は、「モデム接続完全待機（自動ダイアル要求を出さない）モード」を選択してください。
モデム接続完全待機（Modem Dialup Lurk-Only - 自動ダイアル要求を出さない）モード: これはクライアントにいつでも接続要求を出されては困るというユーザーのための設定です。クライアントはdistributed.netプロキシへワークユニットの送受信を試みる際、オンライン状態にあるかどうかをチェックします。

ファイアーウォールの内側にあるマシンの場合

　ファイアーウォールの内側にあるマシンの場合でも、特別なクライアント設定が必ずしも必要とはならないことに注意してください。ファイアーウォール環境によってはクライアントの動作に影響を与えないものもあります。

　設置されているファイアーウォールがあきらかに2064番ポートをブロックしていると判っている場合、ファイアーウォールを越えて我々のプロキシに接続する方法はいくつかあります。状況に応じて以下のうちどれかを選んでください。

一番確実な対処法は、2064番ポート（このポートはクライアントが鍵サーバと交信するのに使われます）を用いた接続が可能となるようにファイアーウォールの設定を変更することです。データパイプの利用、もしくはWingateやInternet Gateを使用している場合はダイレクトポートマッピングを用いて実現してもかまいません。いずれの手段も、ファイアーウォールのホストにおける管理者権限がなければなりません。データパイプを利用する場合は、ポートのリダイレクトをするファイアーウォールのIPアドレスをクライアントに設定しなければなりません。
ファイアーウォールの設定を直接変更できない場合、次に確実な対処法であるSOCKSを使用してdistributed.netプロキシに接続してください（もちろん、ファイアーウォールがサポートしていればの話ですが）。SOCKSの設定は、distributed.netクライアントの設定メニューで「Buffer and Buffer Update Options（バッファと送受信に関するオプション）」から「Keyserver<->client connectivity options（鍵サーバ<->クライアント接続オプション）」を選び、その中にある「Firewall/proxy protocol（ファイアーウォール/プロキシプロトコル）」で設定します。SOCKS4プロキシを使用している場合は「SOCKS4」を、ファイアーウォールがSOCKS5をサポートしている場合は「SOCKS5」を選択します。どちらのバージョンのSOCKSを使っているか判らない場合は、とりあえずSOCKS4を選択しておいてください。すると、ファイアーウォールプロキシの名前（もしくはアドレス）とポート番号を入力できるようになりますので、実際の接続に使用するSOCKSプロキシの場所を指定してください。SOCKS利用の際にユーザーIDとパスワードが必要な場合は、それぞれ適切な項目に入力してください。
最も広範な環境に適用できるファイアーウォール越えの手法として、クライアントはHTTPプロキシの利用をサポートしています。distributed.netクライアントの設定メニューで「Buffer and Buffer Update Options（バッファと送受信に関するオプション）」から「Keyserver<->client connectivity options（鍵サーバ<->クライアント接続オプション）」を選び、その中にある「Firewall/proxy protocol（ファイアーウォール/プロキシプロトコル）」を選びます。そこへ、接続のために経由したいHTTPプロキシを指定します。「Firewall hostname（ファイアーウォールホスト名）」の欄にファイアーウォールの名前（もしくはアドレス）及びHTTPプロキシのポート番号を入力してください。もし、HTTPエンコードでは問題がある方は、「Always use UUEncoding（常にUUエンコードする）」をチェックしてみてください。
これまでに説明したファイアーウォールに関する設定が不可能、もしくはうまくいかない場合、ファイアーウォールが稼動しているマシンでのパーソナルプロキシ設置を最後の手段として検討してください。ただ、パーソナルプロキシを設置することが全ての人に必要というわけではありませんし、一般に推奨するわけでもありません。自分の熟練度に自信があり、クライアントがファイアーウォールを越えてdistributed.netプロキシに接続できる手段が他にはない場合にのみ、パーソナルプロキシを設置してください。

パーソナルプロキシはクライアントからの接続要求を受け付け、それをバッファし、そのブロックを受け渡すためにメインプロキシネットワークとの交信を行います。セットアップは簡単ながらも信頼性があり、proxiesからダウンロードし、ファイアーウォールが稼動しているマシン上でセットアップし動作させるだけです。それから、ファイアーウォールの内側にある全てのクライアントに、パーソナルプロキシとブロックをやり取りするような設定の変更を施します（設定メニューの「Buffer and Buffer Update Options（バッファと送受信に関するオプション）」から「Keyserver<->client connectivity options（鍵サーバ<->クライアント接続オプション）」を選び、「keyserver（鍵サーバ）」の欄にプロキシの名前もしくはアドレスを入力します）。もちろん、そのマシンでパーソナルプロキシを設置するための許可は管理者から得なければなりません。

　最後に、distributed.netクライアントへの対応が確認されているファイアーウォールソフトウエアの一覧表を以下に示します。

Wingate 2.x+ (Win32): HTTPプロキシ, ダイレクトポートマッピング, SOCKS 4 & 5.
Internet Gate (OS/2): ダイレクトポートマッピング
Microsoft Proxy Server (WinNT): HTTPプロキシ
Novell BorderManager (NetWare): HTTPプロキシ
Squid (Unix): HTTPプロキシ
AltaVista 97 (Unix/Win32): HTTPプロキシ
Gauntlet Firewall: HTTPプロキシ

電子メールを用いたブロックの送受信

　今までに示してきた方法ではdistributed.netプロキシと交信できないクライアントでも、電子メールを用いてのワークユニット受け渡しは可能です。

電子メールでワークユニットを受信するには：

本文に以下の2行を書いたメールを「fetch@distributed.net」宛に送ってください：

blocksize=[28〜33（ブロックサイズ）]
numblocks=[1〜500（ブロック数）]

数分後、指定した個数/サイズのブロックが、添付ファイル「buff-in.rc5」として送り返されます。

注： OGRのブロックが必要な場合は、本文に「contest=OGR」という一行を追加してください。
クライアントを停止してください。
dnetcが稼動しているディレクトリにある「buff-in.rc5」ファイルを、設定メニュー「Buffer and buffer update options」の4番「Checkpoint Filename」で指定したファイル名に変更してください。
メーラーからこの添付ファイルを取り出し、dnetcクライアントと同じディレクトリに格納してください。
クライアントを起動してください。

　これにより、新しいワークユニットを処理することができます。

電子メールで処理済ワークユニットを送信するには：

「buff-out.rc5」ファイルをMIME64エンコードされた状態でメールに添付し、「flush@distributed.net」宛に送ってください。数分後に受取書が送付されます。
二重送信になることを防ぐため、「buff-out.rc5」ファイルを削除してください。

LAN内でバッファを共有する

（訳注：現在は、ここに書かれている共有バッファの手法を用いるのは最後の手段とすべきで、その前にリモートバッファという機能の試用をお奨めします。 - jt）

　ネットワーク共有ドライブを用いて複数のコンピュータでクライアントを動作させるには、2つの方法があります。クライアントは、必ず自分と同じファイル名の .iniファイル（クライアント設定情報が保存されているファイル）を見に行きます。例えばあなたが dnetc というファイル名のクライアントを動作させている場合、このクライアントは自分の設定情報を dnetc.ini から取得します。1つ目の方法は、クライアントのコピーを必要な分だけ用意し、それぞれに違うファイル名を付け、それぞれに必要な設定を行うことです。もう1つの方法は、それぞれのコンピュータの起動時に RC5INI環境変数をセットするよう設定することです。これにより、クライアントは RC5INI で示されたファイルにある設定情報を使用するようになります。この方法ではクライアントソフトウェアのコピーは1つですみますが、 .iniファイルはやはり必要な分だけコピーし、それぞれに適切な設定を記述しておかなければなりません。

インターネットに接続できないマシン

　インターネットに接続できないマシンでも、フロッピーディスクを使ってバッファファイルをインターネットに接続可能なマシンへ移動し、そこでバッファの内容を送受信することができれば、クライアントの動作は可能です。この手法は"SneakerNetting"という名前でも知られており、以下の様に行います。

"SneakerNetting"のやりかた

　説明を簡単にするため、オフライン状態もしくはネットワークに接続されていないマシンを「ラップトップ機」と呼ぶことにします。以下の手順はMicrosoft Windowsの使用を想定して説明しますが、考え方としては全てのプラットフォームで共通です。バッファは「buff-in.rc5」「buff-out.rc5」というファイル名がつけられていると仮定しますが、他のプロジェクト、例えばOGRの場合は .rc5の部分を .ogrと読み替えてください。

クライアントをダウンロードし、ラップトップ機にインストールする。
ネットワーク機のクライアントを停止する。
ネットワーク機のクライアントで受信処理（fetch）を行い、buff-in.rc5を満たす。
buff-in.rc5をフロッピーに「移動」する。
ネットワーク機のクライアント動作を再開させる。
ラップトップ機にフロッピーをセットする。
ラップトップ機のクライアントを、"-import [バッファのファイル名]"オプション付きで起動する。
ラップトップ機のクライアントがバッファの取り込みを完了するまで待つ。
ラップトップ機のbuff-out.rc5をフロッピーディスクに「移動」する。
ラップトップ機のクライアント動作を再開させる。
ネットワーク機にフロッピーをセットする。
ネットワーク機のクライアントを停止する。
ネットワーク機のクライアントで送信処理（flush）を行う。
buff-out.rc5をフロッピーからネットワーク機に「移動」する。
ネットワーク機のクライアント動作を再開させる。
手順2.に戻る

tar pit