つい先程から P2P の開発欲みたいなのが、久しぶりに湧いてきたので、とりあえず、P2P を実装する上で面倒、というかめんどくさいコトの一覧をまとめてみる
1. ピア (ノード) 情報の管理 + ルーティング
これは主に Distributed Hash Table (= DHT ) を使って云々とかその辺りの話。
正確には P2P におけるピア (ノード) 管理のアルゴリズムについては DHT と ネットワークが絡むルーティングを組み合わせて実装する場合がほどんとだと思うんだけど、別に DHT 自体はネットワークとか絡んでなくでも実装は出来る。めんどいけど。
それで、 P2P を実装する際に、サーバサイド P2P なら、ナイーブな DHT + Routing でもなんとかはなると思うんだけど、コンシューマーサイド、特に利用者が任意で P2P アプリケーションを起動したり終了したりする場合、ネットワーク的には参加離脱が頻繁に発生するので、その辺りを加味したアルゴリズムを使わないとネットワーク的には破綻する。
そしてさらにめんどくさい事に、 Pure P2P だとノード情報の bootstrap どうするか問題とかも有って、その辺りもさらにめんどくさい。なので、この辺りの実装はよっぽどこの手のアルゴリズムとか実装に慣れているとかでは無い限り、既存の実装使った方が良い、と個人的には思う。
で、次。
2. 情報の同期 + 情報同期のためのノードの優位付け
これは今の自分がほぼ何をどうしたら出来るのかが把握できてないことなんだけど、 情報の同期 と、それに伴う同期のためのノード間の優先順位の付け方、っていうのが、恐らく P2P を実装する上で一番めんどくさい部分だと思う。
というのも、情報の同期を実装するのは、即ちノード間の情報交換の アルゴリズム を考える事だし、また、ノード間の優位付け、という問題も、51% 問題とか ビザンチン故障 とか色々考えなきゃならんことが有って、これはまた僕の技量ではどうにもこうにも手が付けられていない。
まあこれについては、情報の同期とか考えずに ブロードキャスト だけならまだ ゴシッププロトコル とか使えばなんとかなるかもだけど、下手なブロードキャストを実装するとネットワークがゴシッププロトコルの送信で溢れて情報量が爆発する、という事もあるので、その辺りもめんどうっちゃあめんどうではある。というか、その辺りに真面目に実装しないと、DDoS もどきになりかねない。
なので、これもまた他の人が実装出来るのであれば、そっちを利用したい所なんだけど、現実的には、この手の分散アプリとか実装出来るヤツというと Ethereum ぐらいしかないっぽいので、まあ、 Ethereum 相当の実装を自前で作る根気がなければ、 Ethereum の DApps を学んだ方が速そう。
で、最後。
3. ネットワークへの攻撃 + 法的な問題
これはその昔、興味半分で Lair (今は Outopos だったっけ) のネットワークに参加してた時に有ったことなんだけど、Lair ネットワークに対して、2ch で言うところのスクリプト爆撃みたいな事が為されていた時が有って、それの対策が大変そうだったなーという記憶がなんとなしには有る。
で、あと他には、 AWS が Abuse されて Share (P2P ファイル共有の方) の参加ノードに対して、 DDoS をぶちかまされていた時期も有ったはずなので、そういった、ネットワークを崩壊させる為の攻撃やらに対処するのは、まあ面倒だよねっていう感じ。
また先の話に戻って、 Lair そのものにはそんなには法的な問題なかったけれども、 Amoeba と呼ばれるファイル共有 P2P みたいな実装の方面では、色々と法的な問題、まあ要するに違法なファイル共有とかその辺りの問題も有ったはずなので、コンシューマーサイド の P2P を実装する、というのは、そういった著作権とか違法な情報のアレがアレして、という側面が常についてまわるので、そういった事も考えるのは面倒だなぁと思う次第です。はい。
まとめ
なんかちょっと書くつもりが長くなってしまったけれども、話をまとめると、 P2P を実装する上で解決しなければならない課題は、
- ノードのルーティングと管理をどのように行うか
- 情報の交換と、それに伴う優位ノードの優先付けをどのように行うか
- また、ネットワークへの攻撃と、法的な問題の解決をどのように行うか
の三つ辺り。
と、ここまで書いてみて気がついたけど、やっぱりこの手の問題を自分だけで解決する、なんてのは、ぶっちゃけ面倒すぎるので、まー Ethereum の DApps を学んだ方が良さそうですね。はい。
という事でふとメモっておきたかったというか、書きたくなったことは以上です。はい。
