サークルでの動画や写真の配布にBitTorrentを使ってみた結果発生した出来事や感想。
はじめに
僕は軽音楽サークルに所属している。コンピュータ関連が得意というのも手伝って、サークル内での動画撮影・配信・録音などのサポートをしている。先日もライブを開催したので大量の写真や動画が発生した。サークルの部員にそういった写真の類を配布したいので毎回配布しているけれど、そこから発生した様々な出来事。
サークルでは大量の写真や動画が撮影される
サークルにはカメラに通じた部員が数多く在籍しているので、ライブの度にかなり多くの写真が撮影される。また、サークルの活動としてビデオの撮影も行われている。これらのファイルはせっかくなので配布したいと皆が考えており、ときおり個人的に配布されていた。そして、大規模に撮影したものは皆に配布するという慣行が成立したのである。
これまで
これまでのファイル配布では、USBメモリを各自で持ってきてもらってファイルをコピーしていた。ここにはいくつかの問題があった。
面倒
まず第一に、ファイルはUSBメモリを持っていなければ受け取れないということになる。今時であればUSBメモリくらい持っていてもおかしくはないが、移動には紛失のリスクが発生する。他の重要なファイルがUSBメモリに入っていた場合、問題は深刻になるだろう。
そして第二に、ファイルを受け渡しできるかどうかは、USBメモリの容量に依存する。容量が不足すれば、当然ファイルを受け取ることができない。動画などの特に大きなデータの受け渡しでは支障が出るおそれがあった。
拡散が遅い
さて、ファイルの第一次配布は、週に一度のミーティングでしか行えない。それ以降は各人がファイルをコピーして拡散する。ミーティング自体は時間を持たせることができるが、場所が野外になることがままあり、冬場は寒くて困るので、コピーに時間のかかる手法は良くないと感じていた。ファイルが欲しい人の全員に一度に配布できるのが一番良いと思った。
また、それ以降の段階のファイルの拡散は個人の予定に依存してしまう。予定が合わなければ、ファイルを入手することができない。インターネットに接続できるのにファイルは受け取れないというのはあまりに理不尽ではないか。何のためのインターネットだと感じていた。
いくつかの要素が介在して、ファイルを拡散するのに必要な時間が伸びてしまっていたのだ。
実験的にBitTorrentを動画像の配布に利用してみた
そういえば、BitTorrentというのがISOイメージの配布とかで使われていたな、と思い出した。大きなファイルを不特定多数に配布するという設計思想は、この状況にマッチするだろうと考えた。
試しに今回の動画や写真をBitTorrentで配布してみようと思った。
状況
配布は次のような状況で行った。
動画はそのまま、画像はZIPに固めて配布
動画はZIPにしても仕方がないのでそのまま流した。画像はTARとかでいいと思ったが、部員の殆んどがWindowsユーザであることを考慮すると、ファイルをまとめる手段としてはZIPを用いるほかないように思われた。
.torrentファイルを作成し、個人のサイトにパスワード付きでアップロード
μTorrentを利用して作成した.torrentファイルを自宅のサーバのWordpressにアップロードした。この作業のために、WPに.torrentファイルのアップロードを許可させる作業が追加で必要となった。WPは標準では.torrentファイルのアップロードを許可していない。
WPにはサークルに向けたページを作成し、パスワードで保護した。ページの内容は、BitTorrentの概念と理念、主要なBTクライアントのインストーラへのリンク、.torrentファイルへのリンクである。
サークルのMLにパスワードとともにページへのリンクを送信することにした。
部員はほぼ全員BTを使ったことがない
部員のコンピュータスキルは一般的レベルで、Word/Excel/PowerPointは一通り使えるといった程度の者が多かったようだ。当然、BitTorrentは初耳だという者がほとんどだったと思う。
結果
トラッカーを立て忘れた
僕自身がBTに不慣れだったため、トラッカーを立て忘れた。.torrentファイルはプライベートトレントとして設定し生成しているため、DHT検索などの機能は動作を禁止され、トラッカーからのみピア/シーダー情報を得られるようになる。トラッカーを.torrentファイルに記述しなかったことで、誰もリーチャーになりえなかった。
すぐにフリーソフトを漁って、自宅サーバを流用してトラッカーを整備し、また.torrentファイルも再生成&アップロードし、その旨をMLに告知したが、一度広まった情報は完全に訂正されなかった。数度の問合せは、ユーザがobsoletedな、つまり古い.torrentファイルを利用したことが原因だった。正確には最初に送信したリンクは.torrentファイルではなくマグネットリンクであったので、ファイル削除や差し替えを行うことができなかったのである。
NATが面倒
NATの動作状態が良く理解できなかった。シーダーになる場合はNATが必要になる。UPnPによりNATが動作していても、クライアントにはその旨が表示されなかった。クライアントは、実際に通信を確認してからNATが正しく動作している旨を通知するようだ。つまり、クライアントは特に通信をしていない状態ではNATの状態を表示してくれないのだ。この事は知らなかったのでポートが空いていないのではないかと勘違いをしてしまった。
携帯からPCへの動線が困難
ほとんどの部員はMLをスマホで確認している。BTクライアントはPCで動作するので、そこに辿り着くまでの動線を引くことが困難だった。やむなく、MLに流すメールには.torrentファイルが置いてあるWPサイトへのリンクを張り、PCへはサイトへのURLを入力してもらった。
うまくクライアントを使えない事案が発生
クライアントといえどもソフトウェアなので、うまく使えない人がいたようだった。そのようなときは僕がGoogle Chromeに入っているChrome Remoteで対応した。
シーダーが増えない
ダウンロードしてしまうと満足してクライアントを閉じてしまうユーザがほとんどだった。結局、シーダーは僕だけという状況になった。BTの運用思想の観点からすれば、最悪な結果となった。
まとめ
BitTorrentの目的である所の、一時的に必要となる大容量のファイル配布は達成された。しかし結果的に負荷の分散を引き起すことはできなかった。また、BTなどのP2P通信を遮断するプロバイダが存在することも潜在的な問題といえる。
今回の計画は概ねうまくいったと体感しているが、BitTorrentの仕組みやファイルを分け合うといった運用思想についての説明が不足していたのではないかと反省した。人に何かをやってもらうのは大変な努力を要するのだと分かったことも収穫だった。
とりあえず報告まで。
