P2Pでサーバに依存しない掲示板を作るの巻
■ このスレッドは過去ログ倉庫に格納されています
00011
01/08/27 21:33ID:Uofeyeso依存しない掲示板を作るの巻。
クライアントサーバ型BBS、ハイブリッドP2P型BBSでは、サーバを必要とするために
運営に費用がかかります。掲示板では利益を生み出すことができない以上、これら
のサービスは持続可能なものではありません。
２ちゃんねるライクな掲示板を持続可能なものにするためには、コストがかからず、
誰にも依存しない、純粋なP2P型ネットワークを開発する必要があるように思われます。
004341
01/08/29 20:14ID:mHkvtMJw誤：
参加したばかりで、ろくにスレ一覧の出来ていない
他のクライアントから分けてもらいましょう。
正：
参加したばかりで、ろくにスレ一覧の出来ていない
クライアントは、
他のクライアントから分けてもらいましょう。
0044
01/08/29 20:26ID:fbqKB6RI（スレッドのローカルへの保存）
（パケットのルーティングのルール）
（ノード間通信のスレッド共有のプロトコル） の３つに分けて考えたほうが
整理できると思います。
もう一つ、メジャーな板はよいけれど、参加者の少ないマイナーな板は、
特に参加者が少ない時間帯では、共有に失敗する可能性が考えられま
す。 >>3で書いたように、そこで、ランダムな板のスレッドをいくつか、強
制的に、参加者に共有することを義務づける。あるいはスレッドを立てる
こととバーターで、を考えています。
匿名性については、自分が接続しているノードのIPアドレスは分かって
しまいますね。中のカキコの作者はわかりませんが。
あとGnutellaのプロトコルでは、検索クエリーへの答えのパケットに
IPアドレスが含まれているので、そのパケットが通過したノードでは、
「xは、A板のスレッドを持っている、ｙはB板のスレッドCを持っている」
という情報が漏れてしまいますね。
0045デフォルトの名無しさん
01/08/29 21:21ID:7L0go79Aファイルシェアだけの仕組みの提供だけではまずいような気がするな。
それが鉄則だと思うけど。
0046デフォルトの名無しさん
01/08/30 00:33ID:9VE7JjWs"shared nothing"
1つのrequestが複数ノードに負荷をかけないようにする - これは鉄則だと思う。
0047デフォルトの名無しさん
01/08/30 00:36ID:9VE7JjWs最新スレあげ程度だったら、
「最新書きこみ時間」を、スレデータを保持するノードにて発信することができて、
それを複数のノードが共有するだけでもいいんじゃないだろうか？
イメージ的には、Windowsのネットワーク共有フォルダを参照したときに、
ファイル名と更新日付がでてくるよね？
あれと同じことを確認できるだけでいいと思うんだけど。
0048
01/08/30 01:37ID:uLXMKjs2どうかをテストする方法として
しりとりが使えないか？
yyyy/mm/dd hh:ss りんご ごりら
yyyy/mm/dd hh:ss ごりら らっぱ
yyyy/mm/dd hh:ss らっぱ ぱり
…
一般参加者にガンガンしりとりを行ってもらい、そのログを集計する。
書き込むタイミング、配布のタイミングで順序が多少前後したとしても、
書き込み時間で修正できるし、前の単語を書いてもらえば、Treeとして
分析することが可能。 配布漏れが発生するかどうか、もし発生すると
したら、どれくらいの頻度で。
何か矛盾や間違っているところがありますか、もっと良い方法はありますか？
0049デフォルトの名無しさん
01/08/30 01:39ID:9VE7JjWs抜けがあったらすぐわかる（しりとりが破綻するから）
ただ、P2Pって、全部のPeerに均等に同じものを配布せずにすませる仕組みだと思うんだけど・・違う？
それだとNNTPでいーじゃん、ということにはなりゃせぬか？
0050
01/08/30 01:48ID:uLXMKjs2プログラムが、実際の使用に耐えうるものかどうかは、ある程度のユー
ザーにテスターとして協力してもらわねばならず。しりとりなら誰でも
参加可能。
>全部のPeerに均等に同じものを配布せずにすませる仕組みだと思うんだけど・・違う？
P2Pの定義によるかもだけど、あなたの意見には同意。
しかし、板単位、スレ単位でネットワークを組むわけではないから。
もう一つは、配布漏れが発生した際に、どのようにユーザーはそれを
知り、リカバーするのか。 「氏ね>>111」 しかし、俺のログには、
>>111のカキコないぞ。では、>>111を検索しよう」 うーむ。
005141
01/08/30 02:00ID:UdwDTLPc>>44
>（スレッドのローカルへの保存）
>（パケットのルーティングのルール）
>（ノード間通信のスレッド共有のプロトコル） の３つに分けて考えたほうが
> 整理できると思います。
そうっスね。ひとまず、クライアント間での通信メッセージは
どういう書式で記述するのがいいんだろう･･･？ＸＭＬ？
だと、無駄にでかいか。Gnutellaはバイナリなんだっけ･･･？
> もう一つ、メジャーな板はよいけれど、参加者の少ないマイナーな板は、
> 特に参加者が少ない時間帯では、共有に失敗する可能性が考えられま
> す。 >>3で書いたように、そこで、ランダムな板のスレッドをいくつか、強
> 制的に、参加者に共有することを義務づける。あるいはスレッドを立てる
> こととバーターで、を考えています。
新しめのカキコ（レスじゃ紛らわしかったですね、すみません）については、
41の案では、マイナーな板でも公平に、書き込みと同時にわさわさと広がって
大量のコピーが作られる予定なので、大丈夫そうな感じです。
古めのカキコは知らん。
> 匿名性については、自分が接続しているノードのIPアドレスは分かって
> しまいますね。中のカキコの作者はわかりませんが。
> あとGnutellaのプロトコルでは、検索クエリーへの答えのパケットに
> IPアドレスが含まれているので、そのパケットが通過したノードでは、
> 「xは、A板のスレッドを持っている、ｙはB板のスレッドCを持っている」
> という情報が漏れてしまいますね。
えーと、これはその応答に使う経路で直接、
カキコを返すような感じでやれば匿名性は守れると思います。
接続ノードにIPがばれちゃうのは･･･まぁ、しょうがないかと。
>>47
勘違いだったらゴメン。それだと、その板を同時に読んでいる
いくつかのクライアントのIPを取得できちまわないか？
一体、匿名性は、
・2ch.p2pに接続しているがバレる
・板に接続しているのがバレる
・スレッドに接続しているのがバレる
のうち、どのレベルまで確保すればいいのだろうか？
「スレッドに接続しているのがバレる」まで許されるのなら、
割とパフォーマンス良いシステムが出来そうだ。
とりあえず、41の案では、匿名性最優先で考えたつもり。
005249
01/08/30 02:19ID:9VE7JjWsの111は、ブラウザ上でURLとして埋めこまれる
→それを受けるサーバが処理する
となれば方策は2つ
1. そのサーバがスレッドデータの保有者となるような構造にしておく
→必ず返答可能
2. そのサーバは、スレッドデータの表示者となるような構造にしておく
→検索は、表示者が行う
行うとすれば、、、
手順1 スレッドはどこか探り当てる
手順2 スレッドを保持しているサーバに対してrequestを送り、
返答内容に差がなければ表示する（返答可能者全員一致採用法則）
0053
01/08/30 02:23ID:uLXMKjs2前も書いたけど、似たようなことをSOAPでやってる人、XML-RPCが
いるらしいよ。
005449
01/08/30 02:24ID:9VE7JjWs歴史のあるNNTPや、Proxyサーバを使った方が工数も下がるし
プロトコルの不得手としているところもわかるのでいいと思う。
ただ、一般社会のパンピーが、UD-Agentを利用するように
Peerを保持するようなノリに仕向けるためには、
そんな重いものを持たせるのも無理があるかと思う。
仕様決定は、現状可能な技術があるからこれで、
というアプローチが経済的であるけれど、
まずは人間本然の論理として、
大丈夫そうかどうかを論じることも亦重要なのではないでしょうか。
把握しやすい論理は実装矛盾を生みにくいのも亦事実であります。
0055
01/08/30 03:18ID:uLXMKjs2サーバが必要では？概念だけ利用するの？ごめん。頭が動かな
いのでもう寝る。
005649
01/08/30 04:08ID:9VE7JjWsサーバプロセスをPeerに実装する
というのがNNTPやProxyサーバを使った場合の答
でもP2Pは、カエサルのものはカエサルに、が正道だと思うなぁ・・・
0057デフォルトの名無しさん
01/08/30 13:40ID:uLXMKjs2005830
01/08/30 14:41ID:YEMO5.RYhttp://piza2.2ch.net/test/read.cgi?bbs=tech&key=990334284&st=195&to=195&nofirst=true
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=990334284&st=213&to=213&nofirst=true
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=990334284&st=225&to=229&nofirst=true
要は、最新の発言があったサーバンドが、
スレッドのオリジナルを保持しているっていう当たり前の話。
書きこみをする時というか、その依頼があった時は、そこに書き込みをしにいく。
但し、先着１名様限りで、あぶれた場合は、新しくオリジナルになった所を教えてもらって、
もう一度再チャレンジ。成功したら自分がオリジナルの所有者になるというわけ。
そして新しい書き込みが送られてきたら、自分の前の番号のサーバンドにリレーする。
そうすれば、発言のあったサーバンドがミラーとして利用出来る。
行方不明だったり、拒否だった場合はバイパスしてその前に送る。
もちろん、余裕があればその他からのチェーン要求を受け付けてもいい。
まあ、何度も書き込みをしてるとその数だけ何回も送られて来る事になるから
古い方は許否してチェーンを外れておくか、照合用に参照情報だけ送ってもらう。
でこれだと結局オリジナルのサーバに依存だから、
オリジナルが行方不明になったり、トラブった時にも
対応出来る仕組みを考えてたのが上の参照リンクの奴。
基本的には、チェーンの参加者は、再起動時には必ず
最新状況を確認せよって話かな？
0059
01/08/30 14:46ID:XO07jRAQしますね。 僕はしばらくコモってまとめることにします。
（でも時々age）
0060デフォルトの名無しさん
01/08/30 15:29ID:ZbIqADkAでもさ、それだと、カキコをしたやつのIPバレバレじゃない？
同時に最新のカキコをした奴（＝オリジナル保持者）から見れば、
それスレにアクセスしてくるやつのIPもバレバレな気がするんだが。
これを回避できれば、リアルタイム性、同期性もあって、
素晴らしいと思うんだけど･･･。
0061デフォルトの名無しさん
01/08/31 00:44ID:t1XPYVCwみんなもっと素元的に落としこんで考えろ Learn more,study hard!!
0062
01/08/31 03:30ID:cWzLd3g2巨人インテルマンセー。
http://www.watch.impress.co.jp/internet/www/article/2001/0829/intel.htm
http://www.intel.com/pressroom/archive/releases/20010828tech.htm
006358
01/08/31 03:52ID:xAV9dT/Mもし、この書き込みがそうだと仮定すると、
たしかに、62の書き込みがあったサーバンドのipが分からないと
書き込めない事になるし、分かれば書き込んだ方のipも分かってしまう
どうすればいいかというと、２ｃｈの管理人を増産するのが一番簡単。
要はIP取らなければいいわけで、そういう信頼出来る？
サーバンドにしかアクセスしなければいい。
で、書き込みしにいく時は、それらの代理サーバンドに全権依頼する。
番号の管理は代理サーバンドが行なう事になる。
つまり、書き込む人と、サーバンドの独立性を確保すればいい。
まあ、要するに普通にユーザーモードで書き込めればいいって話だね。
>>61
レス順序が一定でないと、例えばこの書き込みの方が、61より
速く出回るって事が起こりえる。
ipなんてない昔からそういう転送掲示板はたくさんある訳。
それならnntp（ihave/sendme等）で十分。というかもっと単純化するべきか？
要は設定を自動化して、皆がだれでもサーバー立てられればいいって話。
既存のnntpサーバが、一般の接続を弾くのは、そのように設定してるからってだけだと思う。
つまり車輪の再発明は、ゴムタイヤだから意味があるので、
そうでなければ、滑りを良くして、レールを発明するって方法もある。
p2pなんて、結局ip/dns/サーチエンジンの再発明みたいな話だし。
0064デフォルトの名無しさん
01/08/31 04:05ID:g5Kjhjlwでもこれを実際にp2pでやるのは無理というかその性質に合致しないことのよう
に思える。2chのようなものは中央サーバがどうしてもいるんじゃないだろうか。
だからそういったサーバ単位で不可分散を考えた方がいいと思う。プリミティブ
な意見で申し訳ないが。。
0065
01/08/31 04:28ID:cWzLd3g2書き込みの順序については既に前のスレッドでも議論したね。もうお腹いっぱい。
配布の遅延や漏れについては、当然生じるわけですが、これをどのように最小限に
押さえるのかというところが面白いところだと思うYO。
前のスレッドで、SOAP使うと言う人がいましたが、ここはもう見てないですかー？
こういうのはどうかな？
(1) Gnutella Net 上でニュースグループ名(たとえば2ch.techとか)を
含むファイルを持っているか検索をする。
(2) 見つかったら、そのファイルをGETする。この時点でGETされた側は、
GETした側からNNTPで記事を配送できるようにする。
(3) ファイルの中身を見て特定の単語(たとえば「このファイルは2ch掲示板で
使います。」みたいな単語)が含まれていたら、そのピアとNNTPでやりとり
を開始する。
こういう感じで自動的に「レス」の配送を行うことってできないかなあ？
んで、このままだと今の2chと互換性がないから、取ってきたレスをまとめて
スレにして、ベアシェアみたいに限定されたウェブサーバ機能（この場合は
MP3ファイルリストの表示じゃなくて、掲示板CGI機能）も持たせてやれば
どうかな？
レスが途中で抜けても、後からそのレスを検索によって取得できれば問題ないんじゃないかな？
たぶん、今みたいに >>999 とか番号で指定することはできなくなるから、レスIDを
使うことになると思うけど、そのユニークなIDを検索にかけて取得するようにすれば。。
って>>66-67は思いっきりNNTPを使ってさらにレスごとに管理するという前提で話してますが。。
はいいすぎだけど、なくても気づかない、ってことなんで、だれかが参照した時点で
取得すればいいんじゃないかなと思ったんです。
007063
01/08/31 05:48ID:xAV9dT/Mそんなこともないと思う。
p2pってのは、一番必要な人達が持っていれば
他の人はそこからもらってくればいいから
皆が保存しておく必要がないって所にメリットが有るように思う。
ipが無い時代には、在り処が分かってても、隣までこなければ無理だったけど、
今は場所さえ分かれば、そこへアクセスして取ってくる事ができる。
>>66
で、>>30でも言ったけど、問題は、規模がでかくなると、
索引でさえ膨大になって、その場所を見つけるのが難しくなる。
まあ、ageで書き込むだけである程度それができるのが2chのシステムである訳で。
ただ、書き込みが多すぎて流れてしまうと、スレの中でも見つけにくくなるのと同じ。
要は処理が追いつかなければ全体を見る事が出来なくなって
見つけられない訳だよね。
でも、例えばp2pの掲示板の話題がこのプログラム板にある
っていうことを知ってればここには辿り着けるって話。
結局、何処かでツリー構造に頼るしかないかもしれない。
でも、それでは頂点がパンクするので、依存するのは避けたいわけだよね
それには山の頂上を平らにするっていうのが普通のサーバー分散の発想。
ただ、山を転がせがばいいという考え方もあるんだよね。
要は、ここを知らなかった場合は、誰かがなんらかの形で
教えてくれたから皆ここを見てる訳だと思うし？
007170
01/08/31 05:50ID:xAV9dT/M逆にいうと皆が参照してくれれば問題ないんだよね。
結局、システム的には、
その場で即座に作れて自動リングする。
勝手に消えない匿名ホームページ群と、
そのリングの負荷分散型ランキングシステム
があればいいだけかもしれないなあ？
まさにこれが問題なんだけど。
007266-68
01/08/31 11:06ID:DGb/yr.6ニュース読んでると、みんなが興味のある記事には
たくさんの返信がされるじゃない。
ということは、もともとの記事が配信されなくても
それに返信した記事のうちのどれかひとつが届けば
もともとの記事が存在したことがわかるし、
興味なければ返信もないから見つけられない人が
少し増えることになるだけと思う。
その記事に返信された数がそのままランキングに
なってないかなぁ？そういう話じゃない？＞ランキングシステム
0073
01/08/31 13:00ID:cWzLd3g2多少の遅延が生じるかもしれませんが、ネットワークに参加しているノードが
カキコを持っていれば、いつかは（w、同期が取れると考えています。
問題はその遅延時間を出来るだけ短くすることと、遅延に気づいたユーザーがその
カキコをできるだけ自然に、かつネットワークに負荷がかからないようにして取り
寄せることができるような仕組みかなと思うのです。
007471
01/08/31 13:40ID:xAV9dT/Mレスがつくのは、興味があるかというより、確かにそれは前提条件ではあるけど、
まずはレスの付けやすい記事かどうか、というのが大きいんじゃないかな？
レスを付けなければ見られにくくなるとすると、
届いてない記事に誰がレスを付けるのかって話だよね。
見れる人が少なければ少ない程、レスがつかない可能性が高いのでは？
さらに、タイムラグがあればある程、レスはしにくくなりますしね。
それに、誰もレスのネタがないからってだれも興味のない記事とは限らないでしょう。
ホームページなんかでも、カウンタだけはやたらまわってるのに、
付属の掲示板はまっさらなんてところはザラにあるわけで、
まあ、２ｃｈ内に確実に存在したとしても、量が多すぎて見つけられない人も
多いのかもしれないから、それと一緒の事かもしれないけどね。
とりあえず、>>58みたいなのを誰か作る気ないかな？
と、実際のプログラムが書けない私は、sageで書いて人に依存してみる。（ｗ
0075
01/08/31 19:05ID:cWzLd3g2おれのサーバント、どうやら書き込みの受信が遅れてるみたいだぞ（遅延発生を
認識）
->同じスレッド仲間とのコネクションの端っこにいることが推測される。
接続数増加ボタン連打。
->仲間とのコネクションを沢山張ることにで遅延を回避しようとする。
0076
01/08/31 22:37ID:2wgXA52Uhttp://www.geocities.co.jp/SiliconValley-Sunnyvale/1358/
007741
01/09/01 01:05ID:V0kaltcwう…漏れも作っちまった。
>>41 で出した案の改良板。まずは概略。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1539/
…つーわけで、ご意見ご感想お待ちしております。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1358/ より
> 板によって異なるポリシー（IPアドレスの表示/匿名、投稿制限等）を設定可能。
むむ、興味あるぞ。
0078
01/09/01 01:14ID:t2cxml/2なんとか一緒にやれませんかね。
>Gnutellaと違うのはファイル（スレッド、書き込み）の
>やりとりを直接行わないで、他のクライアントを通す。
>IPを晒す必要がないので、匿名性を確保出来る。
カキコの中身は全部パケットに入れて流すんですか？
それは少し非現実的では？ パケットでブロードキャスト
するのは検索クエリとそれに対する応答にして、後は
ソケット通信がいいんじゃないかと。
0079aki
01/09/01 01:22ID:Zhfmqejshttp://www.maido3click.com/2ch/viewstat.html?_all
というわけでTikiからリンクはっと来ました...
0081aki
01/09/01 01:39ID:Zhfmqejsスレ違いぽいのは余談の方が長いせいですね。
逝ってきます。。
0082デフォルトの名無しさん
01/09/01 01:39ID:ancbgN2Uhttp://www.geocities.co.jp/SiliconValley/9825/p2p/index.html
図説の現行2chサーバはあくまでも例です。
単に、どこかに固定的に置かれているプレゼンテーションを行う層として考えてるだけ。
（URL固定でないとフツーの人が見れないから）
0083あぼーん
NGNG0085あぼーん
NGNG0086
01/09/01 05:23ID:t2cxml/2>書き込み並びにスレの取得などは、他のクライアントからの伝聞を
>装うのでばれない。
「装う」という仕様では、装っていることがバレバレなのだから、結局IP
アドレスがばれてしまうと思います。
そこで、ランダムなノードをプロクシとして使うことを考えてみました。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1358/proxyposting.html
ランダムなノードは、本当に投稿してくれるのか？
本当に俺のIPを忘れてくれるのか？ログとってねーよなｺﾞﾙｧ!
そのリスクを最小限に押さえるため、行きずりの、全然無関係な板の人に頼む。
だめか。
結局、P2Pは互いを信頼することで成り立っているから、これはどうしようも
ない問題だと思うな。何か良い方法があればいいけど。
0087デフォルトの名無しさん
01/09/01 13:30ID:yanE/TlIつまり、カキコの中身をバケツリレー的に伝聞するという事ですよね？
で、自分がコネクションを張っているクライアントに対してソケットで交信よんよん。
だから、ブロードキャストをする必要は無いと思う。
ブロードキャストは最初にコネクションを張る時だけで。
0088デフォルトの名無しさん
01/09/01 13:35ID:yanE/TlIいや、バケツリレー的にメッセージを送るプロトコルなら。
「どっかのだれかから、あんたにメッセージだよ」
「どっかのだれかが、スレ取得したいから送れ」
を、本人を含めて伝聞で行うという意味じゃないかな？
つまり、ネットワーク総プロクシ化。
的外れだったら、スマソ
0089デフォルトの名無しさん
01/09/01 13:44ID:oknLaLHw(といいつつ、あまり動けないけど)
練ってけど、TCP/IPでいく限りはIPアドレスが漏れるのは避けられないから、
トークンバスの仮想ネットワーク作っちまったらどうかな。
レスはこの仮想ネットワーク上にブロードキャストしちまえば誰が書いたかわからない。
A ==> B ==> C ==> D ==> E
^=======================+
のような輪を作る。Aが発言しBに渡す、BはC以降の誰かが発言したという事しかわからない。
以下、思いついてるネタを散文的に書きなぐり
・データの持ち方は現行の2chにとらわれる必要なし。httpdとして動き、それらしく見せるローカルなデーモン作ればいい。
・スレはレス(いわゆるメッセージ)を指すディレクトリでありレス本体は含まない。スレを閲覧するときに持ってないレスをgnuttelaのように掻き集める。
0090デフォルトの名無しさん
01/09/01 14:10ID:yanE/TlIここで
>書き込み並びにスレの取得などは、他のクライアントからの伝聞を
>装うのでばれない。
というのは、
Aが「どっかのだれかからのメッセージ」と偽れば、Aが発言したとはBも分からない。
と解釈すればいいのでしょうかね？
グヌテラのようにかき集めるのは匿名性の問題があるから、これもバケツ
リレー的に行えばいいと思うです。
0091
01/09/01 14:21ID:9DvFkqOE簡単に破綻すると思います。
0092デフォルトの名無しさん
01/09/01 14:33ID:1.Ou8YGYバケツリレーするには、少なくても隣の人が誰かを知らなければならない
という問題はあるけど
ネットワークが大きくなってもバケツの数も増えるので同じでは？
0093
01/09/01 14:36ID:9DvFkqOE保てますが、ネットワークが簡単に破綻してしまうので、止めたほうが
良いと思います。
http://www.jnutella.org/docs/gnutella/scalinggnutellanet.html
絶対に実装してはならない機能はチャットである。狂気の惨状にしては
ならない:チャットのパケットを送ってはならない。
0094
01/09/01 14:38ID:9DvFkqOEそれは、（ごめん）非常に浅はかな考えだと思います。
009592
01/09/01 14:47ID:KAOoJuUo一周回って送ったメッセージが帰ってきたら完了
A ==> B ==> C ==> D ==> E
↑ ｜
＋−−−−−−−−−−＋
サーバーがある場合に比べて通信負荷が倍になるだけでは？
確かに、このリングを作るのにコストはかかりそうだけど・・・
0096デフォルトの名無しさん
01/09/01 14:51ID:AfE3XVcwIPV6の世界って家電だろうが何だろうがグローバルにIPを振るというものだから、
そのへん考慮されていそうだが。
あまりに厨房なこといってたらスマソ。
0097デフォルトの名無しさん
01/09/01 14:53ID:yanE/TlIじゃぁ、読んだ書き込みはコピーって言うのはどうかな？
コピーかどうかが分からない以上、だれが書いたか不明ですから。
コピーを複数所有していれば確実ですね。
リクエストのほうの匿名性は・・・ 仕方ないかな・・・
0098デフォルトの名無しさん
01/09/01 16:13ID:oknLaLHw>バケツリレーは無理かぁ・・・
そのスレの参加者(閲覧者)の間でメッセージをリレーするとすれば、ネットワークを流れる総データ量は
クライアント数×メッセージ量なので、局所化させない応答性を確保する、が肝じゃないのかな。
>>93
それバイアスかかってないか?
グヌテラのプロトコルはチャットを考えて設計されてないから、実装してはいけない
というならば理解できるが。
009941
01/09/01 19:14ID:V0kaltcw>> 88
そうそう、そういう事っす。ありがとう。
ここいら辺は Freenet のパクリ。以下のページを参考にした。
http://www.sfc.wide.ad.jp/~egichan/mlecture/netsec2000f/kadai3.html
>> 96
どうなんだろう？？でもこんな記事が。
http://www.zdnet.co.jp/news/0012/14/e_nymip.html
IPレベルで匿名性を確保できるとすげー楽っすねぇ。
…んで、
新規投稿（書き込みだとスレの内容の意味のカキコと紛らわしいね、
これもごめん）をバケツリレーしたら、ネットワーク壊れるんじゃねーの？
というご意見多数ですが、
何で壊れる？というのが俺の意見。
遅延発生すんだろ！というのなら分かるけど…。
俺の案だと、「板ネットワーク」なるものを作っている。
これによって必要な所に必要なだけの新規投稿を送れるようになる（はず）。
しかし、ただの経路になったクライアントもネットワークに
組み込まれるわけだけど、もし、流通量が多くて
もうやってられませんわ！という事になれば、
その板ネットワークから抜け出せるようになっている。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1539/#3.2
無駄な新規投稿を経由さすのが嫌なら、抜け出しまくれば、減る。
抜けたら抜けたでネットワークは効率化するわけだし。
…でも、皆が皆、そういうことしちゃうと、
板参加者が推定しやすくなっちゃうから困っちゃうんだけど…。
もしかして、そういうことじゃない？
>> 86
> ∧,,∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
> ミ,,ﾟДﾟ彡 ＜ アンタに、そう伝えてくれって、知らない奴に頼まれた…
> ,;ﾞ ﾐ ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
> ﾐ. ミ
>／゛゛゛゛
ｶｯｺｲｲ
良かったら考えている基本的な土台を見てみたいッス。
俺の案だと板は全部同じ扱いしかできないし。
0101デフォルトの名無しさん
01/09/01 19:47ID:ig30BD5cうP2Pの性質が意味をなさないのでは？
同時多発的にあるスレに対する書き込みが発生してそれぞれ異なった版のスレが
あちこちに作られ、同期を取れない間にまたそれらのスレに書き込みが繰り返さ
れ、さらに版が拡散するんじゃないか？このことはどうやって回避するのだろう？
0102デフォルトの名無しさん
01/09/01 20:13ID:LzBeC2l.==2==C==H======================================================
２ちゃんねるのお勧めな話題と
ネットでの面白い出来事を配送したいと思ってます。。。
===============================読者数：62465人 発行日：2001/09/01
どもども、こんにちは、ひろゆきです。
先日のネタが予想以上に大騒ぎになってしまいまして、、、関係者の方々にはご迷惑をおかけしました。。申し訳ございませんです。http://dailynews.yahoo.co.jp/fc/computer/2channel/
8/31に2ch閉鎖という噂が流れていたので、それを逆手になにか面白いことをしようと思い、forSaleの画像をつくってもらって2chをオークションにかけたわけです。yahooオークションかビッダーズのどちらにしようかと迷ったんですが、
ビッダーズだと無料で出品できるので、ビッダーズでいいやぁとビッダーズを選んだわけです。http://www.bidders.co.jp/
実は、オークションに出品するのが初めてだったもんで、よく知らなかったんですが、ネタの出品は禁止されてるんですね。。。
ビッダーズさんには突然の負荷とネタ出品というご迷惑をかけてしまったようで、、、申し訳なかったです。ちなみに、http://www.writing-space.com/の企画ネタだろう？という話もあったようですが、単においらが思いつきでやっただけです。。。
さてさて、、、2ch縮小のお話ですが、、
サーバ屋さん（http://welcome.maido3.jp/）が好意でサーバを提供してくれて、削除人さん、復帰屋さん、保管屋さんやユーザーさんの善意のおかげで無秩序に増加をし続けた2chでしたが、
規模が大きくなりすぎたため、好意だけで続けるにはコストが高すぎる状況になってしまいました。
そこで、ぽこぽこと掲示板を閉鎖したり、UNIX板の人たちの協力でスクリプトを更新したりと、2chを維持するコストを縮小しよう計画をしてました。
ある程度まで維持コストは下がりましたが、それでも、「誰かがお金を払う」ことで2chが成り立っていたという事実は変わりません。
そうすると、3種類の対策があります。
・広告スポンサーをつける ＜広告モデルが崩壊してるので厳しい。
・ユーザーが使用量を払う ＜面白くなくなる。
・法人化して金稼ぐ ＜めんどくさい。未知数。
もちろん、2chを潰してしまって、日々の生活に戻るという選択肢もありますが、、、
ということで、今後、2chを残すためにどうすればいいいのかという話し合いをしてました。
現実的な路線としては、法人化してサーバ代を払えるような組織をつくるというところになりそうです。そうすると、今までの2chの行動原則の1つである「面白いことをしよう！」というのは崩れちゃうことになるでしょう。
「面白いかどうか？」という基準ではなく、「儲かるかどうか？」という基準で考えなければ、法人としてやっていけません。
だから、法人化するとしたら、儲かりもしないネタをやって、バカ騒ぎすることは出来なくなってしまうかもしれません。
たった2年間ではありましたが、自由で無責任でアホでどうしようもないけど、無駄に面白い場所というのはもう無くなってしまうかもしれません。そして、現在閉鎖した掲示板が復帰する予定についてもまだわかりません。
閉鎖した掲示板の住人だった人や、自由で馬鹿だった掲示板が好きだった人は、2chを去ってしまい、ほかのところでまた楽しくやっていくことだろうとは思います。
そして、今回のオークションネタは、ネタのわかる人たちへの最後の花向けと、ネタのわからない人たちを笑う最後の悪趣味な冗談だったわけです。
今後、2chがどうなっていくかはわかりませんが、世間を騒がせても笑ったものが勝ちという、生真面目な人をうけつけないアホな掲示板があったことは覚えててもらえるとうれしいです。
んじゃ！
─────────────────────── 2ch-net─
Ｐ２Ｐでサーバに依存しない掲示板を作るみなさん、あなた方がポスト２ｃｈの本命の様です。 陰ながら応援します。頑張ってください。
0103デフォルトの名無しさん
01/09/01 21:49ID:baJQonXA0104デフォルトの名無しさん
01/09/01 21:49ID:ytvqUsmk0105
01/09/01 21:54ID:9DvFkqOEとおもって作ってるわけじゃない。作りたいから作るだけ。
0106デフォルトの名無しさん
01/09/01 22:09ID:oknLaLHw>書き込みのバケツリレーなんてしたら1対1で直接ファイルをやりとりできるとい
>うP2Pの性質が意味をなさないのでは？
掲示版という性質上、全ての参加者が同一の情報を(少なくとも注目しているスレについては)
共有する必要があるので、新規カキコはリレーでおっけじゃないか?
閲覧のたびにスレのカキコデータを全部もらってくるのは、他の参加者の負荷が上がるので、
読んだものは自分で保持。
0107デフォルトの名無しさん
01/09/01 22:27ID:LzBeC2l.ごもっともです。
「エンジョイしてるかい？」に訂正。
0108デフォルトの名無しさん
01/09/01 22:31ID:RO5r5Hloお前ら最高にかっこE Yo!
++LOVE
0109デフォルトの名無しさん
01/09/01 22:35ID:V3BM1p2g＞読んだものは自分で保持
ログの保存は。
1．自分で読んだもの
2．経由したもの
を、ユーザーの設定によって保存するってのはどうでしょうか？
また、容量制限も必要かもしれませんね。
0110
01/09/02 01:39ID:K265WADAhttp://www.geocities.co.jp/SiliconValley-Sunnyvale/1358/ideal_packetrouting.html
っつーか、まだ出来てないんだけどね。明日は遊びに行くので、もう寝ます。
0111デフォルトの名無しさん
01/09/02 03:09ID:DPzwl.jkやっぱ人間社会と同じく、こんな感じになるの？
【a.ハナからアヤしいヤツを蹴る場合】
新規Peer
「ねーねー、キミってたしかｘｘサークルだったよね 入りたいんだけど」
新規Peerの知り合いの既存Peer
「んー（お前の入るカラーじゃないんだけど・・・）ちょっと今無理かも」
新規Peer
「そーなんだ。。。」
新規Peerの設定項目として、
「新規Peerの知り合いの既存Peer：知っているPeerの情報
（設定項目名 MyDearFriends=URL:ProtocolVersion）」を設定しといて、
起動されたらその情報にしたがって初期ネゴシエーションを取る。
↓
証明書みたいなのをやりとり(ベリサイン？)
↓
MyDearFriendsが断ったらセッション終了
0112111
01/09/02 03:31ID:DPzwl.jk新規Peer
「ねーねー、キミってたしかｘｘサークルだったよね 入りたいんだけど」
新規Peerの知り合いの既存Peer
「んー（まぁいいかな・・・）じゃあ、口キキしてやんよ。
皆に言うときにいちいちめんどくさいから学生証のコピーくんない？」
新規Peer
「あー、いいよ」
<<次の日>>
新規Peer
「ねーねー、どうだった？」
新規Peerの知り合いの既存Peer ※過半数割れしたらここからが拒否になる
「ああ、オマエ結構ウケよかったから、紹介してやんよ。
この紙がサークルのみんなのプロフィールと連絡先な じゃこれで成立だ。」
新規Peer
「？部室とか連れてってくれるんじゃないの？」
新規Peerの知り合いの既存Peer
「ウチそういうのないの。
その紙のプロフィールで面白そうだなと思ったヤツと連絡とりな。
細かいことはそいつと決めてくれ 活動オンデマンドってヤツだな」
新規Peer
「ふーん、なんかフリーメーソンみたいだね？」
新規Peerの設定項目として、
「新規Peerの知り合いの既存Peer：知っているPeerの情報
（設定項目名 MyDearFriends=URL:ProtocolVersion）」を設定しといて、
起動されたらその情報にしたがって初期ネゴシエーションを取る。
↓
証明書みたいなのをやりとり(ベリサイン？)
↓
MyDearFriendsは動的変更可能な
「このPeerは信用ならんから拒否するリスト(DenyList)」を持っていて、
そのリスト上、そのPeerを信頼できると判断した場合、
今MyDearFriendsが認識しているPeer全てに証明書とPeer情報（URL）を送る。
↓
今MyDearFriendsが認識しているPeer全てから、その新規Peerの受け入れ是非の回答がくる
（各々、MyDearFriendsがしたような判断を行う）
↓
過半数が「いいよ」という場合、
MyDearFriendsは全Peerの情報
（PeerのURL(ミラー化を意識して、複数URL書けるようにする）＋板名＋スレ題＋
最新更新日付＋PeerのURLの新規スレッド保持可能数）
の入ったパケットを
ルーティングするように動作する。
↓
新規Peerはそのルーティング情報に、自分の情報を乗せて、ルーティングを行う。
（この場合、新規Peerが枝末端なので、MyDearFriendsにルーティングすることになる）
（乗せる情報は、自URL＋板名はNULL＋スレ題もNULL＋最新更新日付もNULL+新規スレッド保持可能数）
0113デフォルトの名無しさん
01/09/02 04:26ID:CXtdfW8.なんか腹立つ
0114デフォルト
01/09/02 04:32ID:/l8QEjzUhttp://www.exocortex.org/p2p/index.html
見れば?
0115デフォルトの名無しさん
01/09/02 04:33ID:hNvXVfJgどこに問い合わせても同じ結果を期待するような場合、P2Pは不向き。
P2Pでは情報が完全に失われてしまうケースも考えられる。
（↑こりゃCSだって有り得なくないけども）
0116デフォルトの名無しさん
01/09/02 04:45ID:hNvXVfJgいいんじゃないかな。
DNSの例もあるけど、DNSよりは情報が大きいし。
現存のwww.2ch.netではアクセスの窓口機能だけのために、
アクセスしてきたIPを記録する。->IPTABLEとする
後からアクセスしてきた者はLAST_MODIFYを参考に、前にアクセスしてきた
IPにキャッシュの問い合わせを行う・・・
とか何とか。
そのようなキャッシュサービスを閲覧者に提供させるなら
プロクシの利用を推奨した方がマシかも知れない気がするけど。
0117デフォルトの名無しさん
01/09/02 05:06ID:DPzwl.jkそういえば生物はそういうのどうやってるんだろうか？
細胞ってすんごい数あるじゃないですか。
0119デフォルトの名無しさん
01/09/02 17:18ID:52H90urYブロードキャストで聞けばいいんじゃないのかな。
新規Peer ブロードキャストで聞く。
既存Peer パケット聞いたら自分の既存コネクション数と勘案して返信をする。
新規Peer 返信が早かったやつから、いくつかにコネクションを張る。
でネットワークへの参加じゃだめかな？
0121デフォルトの名無しさん
01/09/02 18:07ID:52H90urY自分のサブネットじゃだめかな？
0122デフォルトの名無しさん
01/09/02 18:08ID:52H90urY>>121
まて・・・ それじゃ、サブネットから出れないじゃないか・・・
グヌテラとかどうやってんの？
PONGパケットを聞いてればいいよ
0124
01/09/02 19:27ID:AfXiH6sIおおぜいいますね。
0125デフォルト
01/09/02 21:22ID:/l8QEjzUhost catcherの話か?
んなもん、初期状態ではどこかのボラ君がWebサイトに
置いておいたリスト取ってきて食わせて、そのリストの
サイト群にコネクトトライして、接続に成功したらがし
がし現在接続しているノードの情報が入ってくるから、
それを覚えておいて、次回からはそのリストを使うとか
いうのが素状態だが、最近、もっと洗練した方法でスタ
ートするサーバントが出たな。
0126デフォルトの名無しさん
01/09/02 23:32ID:5zxU1VI2ものが出てきてますね。ためしてまないけど。
0127名無し
01/09/02 23:58ID:5ndlHDskhttp://www.jnutella.org/
0128
01/09/03 00:12ID:hbfMC5V.マルチポストうざい。
0129
01/09/03 06:40ID:hbfMC5V.理論はよくわからないのですが、Gnutellaの標準設定である(?)TTL=7,
接続数4というのは、非常にうまく動きます。これ以下にすると、パケット
はどんどん届かなくなるようです。
この設定でノードを5000個用意し、P2Pネットワークを作ります。
あるノードからpingを打ってみると、平均すると1.5人に届きません。何度
実験してみても、これ以下のノード数ならば、ほぼ100%の確率で届きま
す。 面白いね〜。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1358/ideal_packetrouting.html
0130_
01/09/03 11:04ID:Cbh2f2Vw個人的に試行錯誤しながら作っている p2p チャットがあるんだけど、もし良かったら参
考にしてちょ。
このシステムは Gnutella のプロトコルと IRC のチャンネルの概念を応用している。
ネットワークレイヤー的には Gnutella ネットワークの上に、チャンネルネットワークが
ある感じ。Gnutella プロトコルの役割は自分が参加したいチャンネルを探すのに使う。
例えば「会話中に"マンガ"が含まれるチャンネル」とか「チャンネルの説明に"pc"が含ま
れるチャンネル」などのようにして検索を行う。
参加したいチャンネル（例えば A チャンネル）が見つかったら、Gnutella ネットワーク
を維持したまま、それとは独立した A チャンネルネットワークに接続する。Gnutella ネ
ットワークに比べて A チャンネルネットワークは参加ノード数が遙かに小さいので（見
渡し可能な範囲を期待）、そこでは会話をリレーしてもそれほど問題はない。で、実際に
は参加時に A チャンネルの参加ノードの情報を引き出して、ネットワークが分断された
ときにはそれを用いてきちんと直す仕組みなっている。
2ch p2p の匿名性の参考にはならないかもしれないけど、多層構造という観点から、なん
らかの参考になれば、これ幸い。
0131
01/09/03 16:06ID:qqnGSLcEhttp://www.clip2.com/jxta_chat.html
Clip２ってウリに出てるのね。２ちゃんねるみたい…
013241
01/09/03 18:31ID:D/ojRdQIhttp://www.geocities.co.jp/SiliconValley-Sunnyvale/1358/proxyposting.html
の
>次の匿名性は守られない。
>カキコの作者のIPアドレスは、プロクシノードに伝わるが、すぐに忘れる。
は、いくつかノードを挟めば解決するね。つまり、
隣りの奴に頼むんじゃなくて、隣りの隣りぐらいに頼む。
これも伝聞形式で行えば、誰が犯人かはわからんね。
個人用完全匿名プロクシの誕生なり。
んで、応用。
あるノードと通信したいなぁ…と思ったら、まずこの仕組みで
プロクシを作って、プロクシ経由で接続出来るのはもちろん、
誰かに通信して貰いたいなぁ…と思ったら、やっぱりプロクシを作って、
プロクシノードのIPと経路ID(頼みのメッセージを送った経路)を
晒してもらえばＯＫ！
晒されたIPはほとんどの場合、無罪（ただのパシリなんです…）。
つまり、この仕組みで、今IPで直接繋いでいるようなところに
匿名性を追加できる（いくつかのノードを通す無駄はあるけど）。
これに >>130 みたいな仕組みを組み合わせてやれば、
結構良さそうな感じなんだけど、どうよ？
013341
01/09/03 18:32ID:D/ojRdQI経路の情報が必要だから。基本ネットワーク上に、もいっこネットワークって感じ。
0134
01/09/03 20:09ID:qqnGSLcE多段にするには、その段数をTTLとしたカキコ発行依頼のパケットを
渡すことになるだろう。 もし、段数を２としたら、TTL=2のパケットが渡
された時点で、渡した奴が作者であると判明してしまう。じゃぁ発行時
のＴＴＬを1-4のランダムにしてみよう。でもTTL=4のパケットが来たら、
それを持ってきた奴が犯人(w。だめだな。
じゃぁ、「渡されてきたカキコ発行依頼は、確率50%の確率で隣の
ノードにリレー依頼。確率50%で、自らネットワークにカキコ」。おっ、
これはうまくいきそうじゃないか？
匿名性を重視するあまりあまりリレーしたら、書き込みが正しく実行さ
れない可能性も増えるし、 ノードに伝わるまでにも時間がかかる。それ
にネットワークがパケットだらけになり、実用性ゼロになるのが恐い。
カキコの依頼にしても、ノード間通信にしても、 プロクシを利用するか
どうか、それを多段にするかどうかは効率とのトレードオフなので、掲示
板毎のポリシーで設定可能にするべきだな。
013574
01/09/03 20:21ID:ewvSMjxY結局、自動的にミラーを利用出来たり、オリジナルサーバに事故があっても、
自動的に適当な場所へ避難して、ログを補完しながら話を続けられる仕組みを
提供できればいいだけかもしれない。
ログの補完についてはこれまで考えてきたようにP2Pの十八番だよね。
ということで、スレッド本体はどうにでもというか、書き込みは制御するなり、
フリーポストのニュースなり、いろんな方式で実装出来るようにしたい。
既存の資源を流用できるようにするのもいいと思う。WWWがgopher利用したように。
例えば、（２ｃｈを含む）既存の掲示板がそのまま使えるようにするとか、
CMTフォーマット辺りに対応するのが楽かも。
問題は、板（カテゴリ）をどうやって実現するかだろうなあ。
というか誰が分類決めるんだって感じ。
とりあえず、スレッド（掲示板）ブックマークの階層を板とみなして、
それを共有できる仕組みが欲しいかも？
めんどくさい人はどっかのボーダルの階層を
そのままミラーしてきて使うということで。
つまり、スレ立てをブックマークで代用するって感じ。
0136
01/09/03 20:27ID:qqnGSLcE誰でも勝手に板を作れる。僕は実際に運営する気はないから、板の名
前を2ch_newsとか、2ch_techとかどんどん増やしていけばいいんじゃ
ないの？ 人は、人が沢山いるところに居たがるから、自然に集合する。
0137デフォルトの名無しさん
01/09/03 20:37ID:ewvSMjxYいや、勝手に板を作るのはかまわないんだけど、
それをどうやって知るのかって話。
誰も知らなければ誰も来ないだろうし。
スレッドが乱立してるのは板を見ればすぐ分かるけど
板が乱立してるのは何処で知る訳？
0138
01/09/04 14:00ID:elQM4lgY0139
01/09/04 15:18ID:elQM4lgYの実験５のところ見てください。多分、既に研究されていることだと思うのですが、僕は
わからないし、調べても見つからなかったので、自分で試してみました。
TTL=7にして、書き込みをブロードキャスト(Gnutellaのpingみたいに）する
と、ノードが増えるとパケットの量が爆発してネットワークが破綻することが
推測されます。ですから、書き込みはTTL=2か3(あるいは>>134)のように
50%の確率でリレー）させて、そこから先は、>>78で書いたように検索による
同期が現実的ではないかと考えました。
0140名無し
01/09/04 23:43ID:kGOfYCnQGnutellaのネットワークって、閉路があるんですか？
0141
01/09/05 00:41ID:4dci715khttp://grampus.jaist.ac.jp:8080/alumnus-theme/abstract/2000/shigeki-jp.html
もっと詳しく知りたいね。おやすみなさい。
0142135
01/09/05 02:13ID:xYlzWZ2A要は、4の7乗が幾つかって話じゃないかな？不幸の手紙の法則だなあ。（ｗ
タイムラグを考えると、接続数（配信先）を増やすべきかも。
でも、帯域制限したら却って掛かるのかも？
ttl=3、接続=20でやるとどうなるかな？
つうか、ランダムだと一緒かな？
基本的には>>130のように、検索用のネットと配信用のネットは
別にというか、多重化したほうがいい様な気がするなあ
で、問題なのはやっぱり>>137の話。
スレッドの存在がわからないと仕方がない。
が、たとえば２ｃｈの現行のすべてのスレッドをキャッシュしようとすると
１だけでも、かなりの容量になるんだよなあ。
せいぜい共通で持つのは、板リストが限度かな？
板の存在が分かれば、その板のスレ情報ネットに参加してるサーバンドを
検索用ネットから探してスレッドリストを取り寄せるとかね。
ぶら下がりたいスレが見つかったら、情報ネットでリクエストすると
受け入れ可能なところが応答するって感じで。
えっと、>>135で分からないのはどの辺でしょうか？
0143
01/09/05 02:37ID:4dci715k>>132さんのサジェスチョンによって書いた>>134 ですが、ウェブに載せ
ました。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1358/proxyposting.html
その後だらだら文献を読んでいたら、
Crowds http://www.research.att.com/projects/crowds/
が同じ事をウェブのブラウジングの匿名性確保でやっているみたいでした。
>多重化したほうがいい様な気がするなあ
根拠は？ 結局、「気がするなぁ」では、議論は進まないと思うよ。
えーと、私の考えでは、板毎、スレッド毎に参加者を部分的に把握します
ので、ご指摘の問題は発生しないように思います。
>>135は、正直、読めるけど、意味を理解できない。
■ このスレッドは過去ログ倉庫に格納されています