一つのプログラムで三種類の転送

BitComet は BitTorrent、HTTP、FTP を同じ待ち行列で扱う無料のダウンロード管理ソフトです。ここで扱うバージョンは 2.22 です。三つを一つに置くのは小さな便利に見えて、実はこのプログラムが存在する理由そのものです。同じファイルが二つの経路で同時に届くことはあり、片方しか知らない管理ソフトは、どちらが速かったかを知る前に選択を迫ります。

日常の場面はもっと退屈で、もっとよく起きます。あるプロジェクトの更新情報は HTTP で届き、大きなアーカイブは BitTorrent で届き、社内ネットワークのミラーは FTP でしか入れない。一つの一覧、一組の制限、進み具合が見える一つの場所。

群れ（swarm）の仕組み

BitTorrent の側は、独自の仕組みを作らずにプロトコルに従います。転送は torrent ファイルかマグネットリンクから始まり、データはサーバーから取るのではなく他の参加者と交換します。群れの中の全員が同時に受信し送信します。だから人気のある転送は単一のサーバーが出せる量より速くなりえ、人気のない転送は停止に近づきます。

これは仕組みの説明であって、何を転送すべきかについての主張ではありません。プロトコルは中身に無関心で、クライアントも同じです。群れがどれだけ速いかは、その時点で何人がそれを持っているかで決まります。

九十九パーセントの問題

この設計の弱点は転送の終わりにあります。欠けている部分を持っていた参加者が去ってしまうと、ダウンロードは九十九パーセントで止まったままになります。ファイルは使えず、場所は占有されたまま、画面のどこにも理由が書かれていません。

長期シードはそこに効きます。一度でも見た部分は、たまたまそれを持っていた相手より長く利用できる状態に保たれるので、本来なら止まるはずの転送にも終わる先があります。同じ仕組みは、たいていもっと早い段階で速度として現れます。長期の供給元を背後に持つ転送は、都合のよい時間に十分な相手が現れるのを待たなくて済みます。

キャッシュを通して書く

ディスクキャッシュは最も見えにくい機能で、最も長く影響が残る機能です。ダウンロードとは、まだ組み立て中のファイルに散らばる数千の小さな書き込みであり、そのまま書くとディスクはシークで忙しくなり、負担もかかります。部分をメモリに集め、より大きく順序立ったまとまりで書き出すと、読み書きの回数が減ります。プログラムが主張しているのはまさにそれで、速さではなく消耗の少なさです。

これは利用者が気づく挙動の説明にもなります。タスクが完了と表示される直前の数秒が、受信ではなく書き込みに使われることがあります。

届きながら再生する

「落としながら再生」と呼ばれる機能は、一つの判断に依存します。メディアファイルの先頭と末尾を先に取ることです。先頭は再生開始に必要で、末尾には多くのコンテナがそこに置く索引が入っています。両方が手元にあれば、中央がまだ転送中でも再生を始められます。末尾がなければ、索引を要求するプレーヤーは、中央がどれだけ届いていても開始を拒みます。

どこに位置するか

BitComet はオープンソースのプロジェクトではなく、そう名乗ってもいません。無料で、月に一つファイルを取る人ではなく、待ち行列を回し続ける人のために作られています。正直なまとめはこうです。三つのプロトコル、長期シード、そして受信中の再生。この三つが合うかどうかを決めます。仕事が複数の経路の混在で、九十九パーセントで死んでは困る大きな転送を含むなら、それはこのプログラムの用途です。