インタネットはネットワークの相互接続である。
インタネットプロトコルは、「あなたのコンピュータと私のコンピュータを継ぎ目なく使うことができるような仕組みである」ことを前提としている。
Winnyの技術が、何を付け加えているか、何を付け加えていないかを、書籍「Winnyの技術」を読みながら確認する。
まず、プログラマが参考になる記述を拾い出す。
https://www.amazon.co.jp/dp/4756145485/
P2P(Peer to Peer)
p.14
クライアント／サーバとは対照的
p.16
システム規模の急拡大にも耐えられる
コンピュタやネットワークの障害に強い
データの一元管理や短時間の同期は苦手
P.17
P２Pネットワーク全体の管理や監視が難しい
Napster
The Napster service (including PC and mobile clients) may incorporate one or more of the following patents: 6,366,907, 6,697,800, 6,742,023, 6,865,600, 7,089,301, 7,096,203, 7,165,071, 7,170,999, 7,310,629, 7,356,556, 7,454,480, 7,730,178, 7,966,522, 8,090,662, 8,336,090, 9,898,466.
Gnutella
Freenet
Winny
winny.info
https://winny.info
p.39
2.1 Winnyの開発コンセプト
匿名性（プライバシーの保護）を実装したファイル共有ソフトであること
ファイルの共有効率がよいこと
Windowsネイティブプログラムであること(FreenetはJavaで実装された）
p.48
Winny2ではGUIの変更を目的として、開発環境をVisual C++からC++Builderへと変えています。
p.77
オーバーレイネットワークという側面
オーバーレイネットワークが何であるかの説明がない。
https://ja.wikipedia.org/wiki/オーバーレイ・ネットワーク
Winnyのオーバーレイネットワークの特徴は、
p78
ファイルを保有するノードからファイルを必要としているノードまでの距離（ホップ数）を短くする
まとめのために
Winnyのすべての技術が理解できたら「まとめ」を書くとして、現在わかっている範囲内でのまとめをここに記載する。
著作権、所有権などがあるファイルを共有しないことを利用条件として同意した人だけが使えるようにしていたのかどうかの記述が見当たっていない。
p.154
5.5 システム妨害に対抗する
Winnyネットワークへの攻撃
ごみファイルを大量にばら撒く
著作権、所有権などのあるファイルを共有した人がいることが、システム妨害あり、結果としてシステムの更新ができなくなったのかもしれない。
ごみファイルより、著作権等に違反した利用方法を排除する機能について助言できなかったことを反省。
Winnyを振り返る
Winnyは、画期的なソフトウェアだったと思う。
自分はファイル周りは不得意で、よく理解できていなかった。
Winnyを使うなということを強要する人たちの根拠に違和感を感じていた。
Internet Protocolをはじめ、インタネット系の通信規約は、ネットを継ぎ目なく繋ぐことを目的としている。
あなたのネットワークと、私のネットワークは意識しなくても使える。
GitHub, docker hubなど、ファイルを共有する仕組みが体系的に整備されてきた今では、あたりまえのことのように感じているかもしれない。
説明歌 P2Pファイル共有ソフトにて著作権守る機能必要
https://bookmeter.com/books/564651
#参考資料
金子勇氏とWinnyとともに日本が失ったもの
https://www.newsweekjapan.jp/column/ikeda/2013/07/winny-1.php
まだ4万人もいるWinnyユーザー、危険を犯して誰が使っているのか
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00139/070200021/
日本が失った天才、金子勇の光と影
https://wired.jp/2018/11/10/winny-isamu-kaneko-1/
参考資料 on Qiita
P2Pネットワークとは
https://qiita.com/nagata03/items/d6d9ca6607ea8c3857c1
自己参考(self reference)
日本のプログラマが世界で戦える16分野
https://qiita.com/kaizen_nagoya/items/a7e634a996cdd02bc53b
マルチホーミングにおける端末間経路選択のための片方向遅延差測定方式
https://ci.nii.ac.jp/naid/110003502049
論文でRFC参照
https://qiita.com/kaizen_nagoya/items/8710bfa1d9d6eebccdcf
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20190222 昼
ver. 0.02 助言 追記 20190222 午後
ver. 0.03 オーバーレイネットワーク追記 20190223
ver. 0.04 Winnyを振り返る 追記 20190224 夕
ver. 0.05 説明歌 追記 20190224 夜
ver. 0.06 URL等追記 20190405
ver. 0.07 参考資料追記 20190406
ver. 0.08 参考資料追記 20210731
ver. 0.09 ありがとう追記 20230504
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.
