---

■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50

2chのような掲示板システムってP2Pで

499 ：266 ：2001/08/26(日) 03:27

もうそろそろ寝ようかと思いますが、
できれば明日中にプロトタイプをたたき上げるつもりです。
実は納期までまり余裕のない仕事を抱えてたりもするもんで(苦笑)
実装に際しては独断で仕様を決めてしまおうと思いますが
ソースは公開しますしご意見は是非とも参考にさせてください。
どうぞよろしくお願いします。
では今日はこれにておやすみなさい。

500 ：375 ◆MsUYMX0E ：2001/08/26(日) 03:28

>>266
おやすみなさい。僕もねます

501 ：266 ：2001/08/26(日) 03:29

>>498
そういうことです。
自分から見てキャッシュ鯖となるサーバントは
２ch上のピア一覧を見て適宜決定します。

502 ：うーん ：2001/08/26(日) 03:28

>>494

ごめん構成を勘違いしてたみたいだ。

(1）2ch.net ---- （2）キャシュサーバー　---- PC[(3)内部プロクシ---- (4)ブラウザ]

と言う構成でハッシュのチェックは(3)でやるということですね？

503 ：266 ：2001/08/26(日) 03:30

>>502
はい、そういうことです。
ただし(2)の部分はサーバントになります。

今度こそ寝ます(笑)

504 ：なんとなく ：2001/08/26(日) 03:45

キャッシュサーバを設けるなら、書き込みがあった時点で
そのまま転送しちゃっても良いのでは？

書き込みは常に親サーバが受け取り、そのまま子サーバへ転送。
親サーバには直属の子サーバへのリンクしか置かないで、
スレッドは子サーバ以下からしか読み込めない。

親の負荷が増えたら、板ごとに親サーバを分割できるし、
キャッシュサーバも孫やひ孫が作れる。
認証も親サーバのアドレスが固定であり、サーバ間通信は暗号化も可能。
秒単位の遅延と、書き込みが即時反映はされない点、子・孫サーバが
落ちてた場合の再送のタイミングに少し問題が残るけれど。

505 ：225 ：2001/08/26 06:38

>>504
ツリー構造のIRCみたいなものかな？
プッシュ型は効率的には良いだろうけど、問題は誰に送るかってことかな？
スレッド毎に定員を決めたりする場合、満員なら自分の子のサーバンドを紹介するって事になるんだろうけど
子が全部ファイヤーウォール内だったりすると困るかも？まあそれは無いにしても（というかコネクションはりつづけてる必要があるし）、
途中がとらぶった場合は面倒かも？ちゃんと配信してくれればいいんだけど。
まあ、それならそれで、別の親を探すか、自分が２ｃｈ直下の親になればいいだけかな？

LOGを平均して10人で共有出来れば、２ｃｈの負荷は1/10になるって事だよね。
処理に３秒余裕をみるとすると、珠々つなぎでも30秒程度、２分木だと12秒　10分木だと３秒
と書き込まれてから、親が検知するまでの時間（２ｃｈ自身が親として流すのなら最短で済む）
がタイムラグになる

とりあえず重要なのは
piza2.2ch.net/test/read.cgi?bbs=tech&key=990334284&st=502&to=502&nofirst=true
piza2.2ch.net/tech/dat/990334284.dat

なんていうアクセスを横取りして、さも実際にアクセスしたように表示できればいいわけで。
それにはdatのキャッシュデータが必要なわけで、

誰かが持ってるなら、何もオリジナルを読みにいく必要はないけど
じゃあ代替手段は何かってことで、

結局、オリジナルを読みに行った人と、そのデータを共有するための仕組みがproxyなんだけと、
アクセスが特定のサーバに集中したんじゃ、とても耐えられないし
かといって皆が一次proxyになるのではかちゅ〜しゃ使うのと大差ないって感じかな？
まあそれでもcgi使わないだけで、負荷的にはかなり違うと思うけど。

で、それにはキャッシュを持っているアクセス可能なサーバンド（つまりミラーサーバ）を知るのが先決な訳で
p2pっていうのは、それの出来次第で評価が左右されるんだよね。

まあそこはスレで告知するとか、ある程度は運用でカバー出来るから問題ないかもしれない？。

506 ：266 ：01/08/26 11:57

今起きた(藁
プロトコルの仕様を考えてたらちょっと思いついたことがあったり。
これ、IPを隠して書き込みしたり
同じスレを見ているユーザー同士でIM的な使い方するのに使える(藁
WinMX+ICQ+2ch的なことがかなり簡単にできてしまう。
そういう方向へ誰かがツールを拡張してしまうと
かえってユーザー数を増やしちゃってトラフィックが増えるような気がするのは俺だけ？

507 ：デフォルトの名無しさん ：01/08/26 12:01

このスレで作ろうとしているシステムの名称だか開発コードネームって何か決まってます？

508 ：デフォルトの名無しさん ：01/08/26 12:03

>>507
ラプソディー

509 ：デフォルトの名無しさん ：01/08/26 12:07

P2P2C(H?)

510 ：266 ：01/08/26 12:09

俺が作ろうと思ってる分についてはまだ名前は考えてないよ。
それよりIP匿名化とかファイル共有とかIMとか
ほんとに作っていいのかどうか不安になってきたんだけど・・・。

511 ：375 ◆MsUYMX0E ：01/08/26 12:10

>>506

おはようございます(^^;;;


ところで >>461 で
---
ピア一覧への登録と解除については
>俺はプロトコルは要らないんじゃないかと思ってます。
>ある板にアクセスしたら、
>時限付きでリストに加えるようなCGIを鯖側に用意するんです。
>これならプロトコルもクライアント側での特定の処理も要りません。

なるほど。ちなみに確認になるんですが
「ある板にアクセスしたら」
っていうのは「キャッシュが」ってことですよね？

確かにこの方がエレガントですね。


---
とかいったんですが、よく考えたらこれだと
キャッシュとして振舞う気が無いのにただアクセスして
2ch.net の鯖にあるリストを腐らせるとか言う攻撃が
可能になりませんか？

やはりcacheの特定のポートに2ch.netからpingするとか、cacheの
動作を確認する何らかのプロトコルがいる気がするのですが...

512 ：266 ：01/08/26 12:14

>>511
なるほど。
でもそれって普通に 2ch.net を攻撃する奴がいるかどうか
って話と変わらない気がします(藁
別個にポートを用意する場合でも
そのポートやプロトコルを隠したり何らかの形でセキュアにしないと
同じような問題が考えられますよね。
そこまで暇な奴がいるとは思えないんですが甘いかな？

513 ：375 ◆MsUYMX0E ：01/08/26 12:18

>>512

まぁたしかにそうなんですけど
IEとかで
ttp://www.2ch.net/board/p2p.cgi?do=getmes&thread=XXXXXX&from=XX&to=XX
とかにつなぐだけでリストに登録されちゃうのはまずいかな？　と。
あ、でもUSER_AGENTで区別するという方法はありますね。

IMとかファイル共有とかは確かに面白そうですね。
でもとりあえずはプロトタイプの作成が先かな？

514 ：266 ：01/08/26 12:18

うーん。結構悩ましいかも。
仮にP2Pcacheを作って誰かがそれを改造して
匿名書き込み機能を追加したとすると
P2Pcacheを使ってないユーザーがfusianasanしても
それが信頼できないっていう話に繋がりますよね。
つまり２ch全体でfusianasanが無意味になってしまう。
これは安易にソース公開で出しちゃうとまずいかも。

515 ：デフォルトの名無しさん ：01/08/26 12:19

なぁ、漏れは、w3m or lynx使いでJavaは動かないんだが、
ブラウザはJavaが動く香具師でないと駄目か?

516 ：375 ◆MsUYMX0E ：01/08/26 12:20

>仮にP2Pcacheを作って誰かがそれを改造して
>匿名書き込み機能を追加したとすると
>P2Pcacheを使ってないユーザーがfusianasanしても
>それが信頼できないっていう話に繋がりますよね。
>つまり２ch全体でfusianasanが無意味になってしまう。
>これは安易にソース公開で出しちゃうとまずいかも。

あれ、書き込みは従来どおり2ch.net に直接だと思ってたんですが..

517 ：266 ：01/08/26 12:21

>>513
はい。ピア管理は read.cgi にある程度組み込んで
USER_AGENT で区別するという方向で考えてます。
これならPC初心者の厨房は十分排除できるはず。

518 ：266 ：01/08/26 12:22

>>515
そういう細工はしないんで大丈夫です。

519 ：266 ：01/08/26 12:23

>>516
あ、違います。
俺が作ってソース公開したら
誰かがすぐにそういう改造ツールを出しちゃうんじゃないか、という話です。
P2Pでもgnutellaとかだと確かあれはIP自体を輸送しちゃいますよね？
IP匿名ってのが売りである 2ch ではそれはまずいだろうと思って
IPをばらまかない方法を考えてたんですよ。
そしたらこれは悪用も可能なんじゃないかってジレンマに陥っちゃって。

520 ：266 ：01/08/26 12:35

ソースが公開されてプロトコルも決まってる。
しかもそのプロトコルはIPの匿名性が高い。
少しコードを書き加えれば
IP匿名化書き込み、同じスレを見ているユーザー同士でのチャット、
ファイル交換などが簡単に実現できてしまう。
こんなもの厨房なアマグラマが見つけたらそれこそやばいような気が・・・。
どう思いますか？＞諸氏

521 ：375 ◆MsUYMX0E ：01/08/26 12:41

>>520

IP匿名化書き込みっていうのがやっぱりよく分からないんですが
もうすこし具体的に説明していただけますか？

522 ：266 ：01/08/26 12:45

>>521
まずgnutellaではファイル交換をHTTPでやる時のために
確かメッセージ交信の両端のサーバントのIPをやりとりしますよね？
でもこれはファイルのストリームを
二者間で直接やりとりしなくちゃいけないからで
データ転送も含めて中継サーバントが面倒を見てくれるなら
直近のサーバントのIPが分かってれば十分で
あとは相手先の識別用GUIDか何かを目当てにバケツリレーすればいいわけです。
こうすればIPをパケットの中に含める必要がなくなる。
で、こういう仕組みを作った上で、
どこかのサーバントに代理投稿を依頼するわけです。
すると 2ch.net 上には代理サーバントのIPだけが残る。
間に不特定の複数の中継サーバントを入れれば追跡もほぼ不可能なはず。
こういう話です。

523 ：266 ：01/08/26 12:48

スマソ。急な呼び出しがあったんで小一時間離席します・・・。

524 ：デフォルトの名無しさん ：01/08/26 12:59

>>520
現状として出来ることは
約3割のgzipやlastmod非対応ユーザーを
2ch.netに直接アクセスさせないことだと思います。
とりあえずキャッシュサーバーとしての動作を優先すべきでは？
専用ソフトを使う人は全体からすれば少ないはずです。

525 ：デフォルトの名無しさん ：01/08/26 13:18

>>522
代理サーバからの書き込みを拒否するのはだめ?
writeはclientから2ch.netに直接で
2ch.netの方は代理サーバ一覧もってるんしょ?

526 ：375 ◆MsUYMX0E ：01/08/26 13:39

>>525

たぶん悪意を持った人が、2ch.netにも登録せず単なる汎用の
「メッセージをたらい回しして発信元を消すツール」
に改造しちゃうことを心配してるのだと思う。

でも結局いずれ誰かがそれをスクラッチで作っちゃうだろうし
個人的にはあまり問題ないとは思うんだけどね。

527 ：266 ：01/08/26 13:49

帰ってきました。仕事追加されたよ(泣)

>>524
俺自身はキャッシュしか作るつもりはありませんが
ソースは公開するつもりなんで誰かが妙な改造をするのを心配してます。

>>525
代理サーバと言っても実体は代理サーバントなんで
それをIPなんかでブロックしたら正規の書き込みができなくなります。
改造する奴はきっちりとIEか何かを偽装するようなコードを仕込むでしょうから
USER_AGENTを使った判別も無意味です。

>>526
ごもっとも。その背中を押すようなマネを自分ではしたくないなという話です(藁

528 ：デフォルトの名無しさん ：01/08/26 14:02

>>524
確かP2Pプロジェクトとキャッシュサーバプロジェクトは別個で
開発していくんじゃなかったの？
で、P2Pがここのスレッドでキャッシュサーバは別にスレッドを
立ち上げることで話が決まったはず。
で、キャッシュサーバスレが未だに立ってないだけ(消滅？）

529 ：225 ：01/08/26 14:32

＞527
改造もなにも、このスレは２ｃｈの代わりになるようなものを作るのが
元々の目的だった気もするけど？
まあ、削除の問題とか、いろいろ難しいだろうけどね。

で、とりあえずそれとは離れて、今の話だけど、win以外の人の為に
キャッシュ部分をミラーサーバとして公開するならって事かな
書き込み用のフォームのリンクは2chに直接貼るしかないんじゃないの？

530 ：デフォルトの名無しさん ：01/08/26 15:34

プロトコルの実装をでっち上げれば、あとは各クライアントを使っているプログラマさんがエージェントを作ってくれるっしょ。

バケツリレー式プロトコル、パンドラの箱かもしれないですけど、面白いと思いますよ。

fusianasanはトリップみたいにパスワードやれば良いと思われ。
これは、公開鍵暗号を実装すればいいでしょう。

削除は事実上不可能だと思うけど、これは仕方ないと思う。
一度ネットに上げられてしまった情報は、コピペやキャッシュによって無くなることはまず無いんですから。

531 ：デフォルトの名無しさん ：01/08/26 15:54

マスターサーバー
現在の鯖を使用

キャッシュクライアント
ADSL以上が条件
ROMクライアントよりスレッドの取得が優先される

ROMクライアント
ISDNなど主に低速回線向け
スレッドのキャッシュをしない

スレッドのキャッシュ方法
クライアントからマスターサーバーへスレッドのリクエスト

そのスレッドのキャッシュクライアントリストとスレッドを照合

新規に書きこみがある場合、
新規書き込み分の差分とキャッシュクライアントリストをクライアントに渡す。

クライアントがキャッシュクライアントである場合、キャッシュクライアントリストに追加。


キャッシュクライアントリストの上限はスレッドに対するリクエスト数で変動。
記録するデータはクライアントIDと取得書き込み数

こんな感じじゃだめですかねぇ・・・

532 ：1 ：01/08/26 15:56

プロトコルはXML-RPCってのはどうでしょうか？
言語もC/C++、Java、PHP、Perlなどなんでもあり、プロトコルもHTTP上に載るから扱いやすいのと、仕様がきれいにまとまる気が。
かの有名なFreeNetもXML-RPCだと思う。

http://www.linux.or.jp/JF/JFdocs/XML-RPC-HOWTO/index.html (UNIXよりだけど）
http://freenet.sourceforge.net/

533 ：デフォルトの名無しさん ：01/08/26 15:59

>>530
削除はマスタwww.2ch.netの一覧で削除マークつける
とか項目自体消して、キャッシュからの更新時に
削除でクライアントに渡さないようにするとかはだめでしょうか?
NNTP式のコントロールメッセージ式は偽装が楽だった気がする。
どちらにせよ、完全じゃないけどないよりはマシのような。

534 ：266 ：01/08/26 16:01

これまでの内容のまとめです。
独断で片付けてる部分が多いんですがそこは突っ込んでください。

●何を話しているか？
２chの転送量超過についての対策が問題意識の基本。
その解決としてのクライアント側でできるP2Pベースのキャッシュについて。

●製作物の概要

・対象プラットフォーム
　　候補：Win32

・大まかな内容
　　候補：クライアントマシン上で動く HTTPd。
　　　　　ブラウザで localhost にアクセスすると 2ch が見える。
　　　　　実際には裏で HTTPd が 2ch.net やキャッシュにアクセスして
　　　　　スレのデータを収集、整形、キャッシングする。

・内部の大まかな処理フロー
　　1)ブラウザが HTTPd にアクセスすると HTTPd が動作しはじめる。
　　　以下、この HTTPd をクライアント、ピアの HTTPd をキャッシュと呼ぶ。
　　2)クライアントは2chのスレを読み込もうとしたときに次の手順をとる。
　　　　i)2ch.net からスレやレスの目録リストを取得する。
　　　　ii)リストを元に検索クエリーを生成してピアにばらまく。
　　　　iii)ピアからの返事を一定時間待つ。
　　　　iv.a)ピアからの返事があればそこからデータをもらう。
　　　　　　　データは 2ch.net から取得したリスト中のハッシュと照合を行う。
　　　　iv.b)時間内にピアからの返事がないか もしくは
　　　　　　　上記の照合で失敗したら 2ch.net からデータを直にもらう。
　　　　v)自分が獲得したデータはキャッシュする。
　　3)書き込みは 2ch.net に対して直で行う。
　　4)鯖はピア一覧のみを管理する。
　　　　i)2ch.net 上に適当な CGI を用意してピア一覧の取得を可能にする。

535 ：266 ：01/08/26 16:02

・プロトコルの仕様/分類
　　1)クライアントがキャッシュを検索するプロトコル(クライアント⇔2ch.net)
　　2)クライアントがキャッシュからデータをとるプロトコル(クライアント⇔キャッシュ)
　　3)キャッシュが2ch.net からデータを取り込むプロトコル(キャッシュ⇔2ch.net)

・その他
　　1)板ごとに動的にピアグループを生成する(グループは鯖側で管理)。
　　　検索クエリーは対象板のピアグループに対して投げる。
　　2)フローティングスレッドはスレ番号一覧を鯖側に置いて
　　　これを元にクライアント側で自主的に生成。
　　3)データ改竄の可能性は極度には意識せず普通に防止する程度で実装。
　　　　※現状では 2ch.net 上のハッシュによる照合を想定。
　　4)システムの維持が困難になるような悪意ある妨害については真面目に対処。
　　5)更新頻度や情報の粒度が尋常でないことに留意する。

・開発チーム
　　　とりあえず俺。

536 ：266 ：01/08/26 16:02

●ピア管理について
ピア管理は 2ch.net 上で行う。
read.cgi に細工をほどこし、2ch.net にアクセスしてきたユーザーで
USER_AGENT が P2Pcache のそれになっているユーザーのIPを
アクセスされた板の住人としてピア一覧に登録する。
この登録は時限設定するものとし、
例えば最後のアクセスから一時間放置されたら除外する。
ピア一覧には CGI 経由でアクセスすることができる。


●レスとスレの一覧について
read.cgi に細工をすることでスレへの書き込みと同時に
書き込み内容のハッシュのリストを生成これを 2ch.net 上に保存する。
また、フローティングスレッドやスレ一覧などのデータも保存する。
P2Pcache はまずこれらのリストを 2ch.net 上から取得し、
このリストに含まれるレスをピアや 2ch.net 上から収集する。


●データ改竄について
2ch.net 上にあるレス情報にサイズやハッシュなどを含め
ピアから収集したレスとの照合を行うことである程度防げる。
照合に失敗した場合には 2ch.net から直接レスを取得する。
仮にハッシュがたまたま誤って一致してしまった場合でも
架空のレスが他のレスに入れ替わる程度で済み実害はほとんどない。

537 ：266 ：01/08/26 16:02

●2ch.net 側の実装物について
ピア管理を行う CGI の実装が必要。
次のような動作をするものでよい？

基本的な動作は 2ch.net 上の各種のリストを読み出すこと。
動作パラメータは次の通り。

　　do：読み出し対象リストの選択。値は以下のいずれか。
　　　　threadlist = スレ番号の一覧
　　　　reslist = レス情報の一覧
　　　　abornlist = あぼーんされたレスの番号の一覧。
　　board, thread：板やスレッドの指定。
　　from, to, ls, nofirst：read.cgi に同じ。読み出し範囲の指定。
　　bycontent：do==reslist && bycontent==true ならばレスの文面を返す。

レス情報は、レスIDとレスサイズ、ハッシュのペアからなる。
レスIDは時系列にそって順序比較が可能で各レスについて固有であれば何でもよい。
reslist bycontent はキャッシュヒットしなかった場合の差分更新に用いる。
※レスIDには ETag が使える？

538 ：266 ：01/08/26 16:03

●P2Pcache 側の実装物について
P2Pプロトコルに基づいて動作するサーバント兼
その動作過程で獲得したデータを整形してブラウザに送る
HTTPd としての実装が必要。
以下ではプロトコルについて述べる。

プロトコルはメッセンジャーの非同期な交換としてモデル化する。
すなわち、ピアは他のピアへとメッセンジャーを送信するが、
どのメッセンジャーも独立しており、返信を必須条件としない。
ある目的に沿って二者間でメッセンジャーが継続的に往復する時
この往復の全体をセッションと呼ぶものとする。

メッセンジャーは次のフォーマットをとる。

struct Messenger{
　　　struct Header ;
　　　struct Message ;
} ;

struct Header{
　　　time_t　timeStamp ;
　　　GUID　inquirerID ;
　　　GUID　answererID ;
} ;

Message の中身はメッセージの種類ごとに異なる(後述)。
Header の各フィールドは次の意味を持つ。

　　timeStamp：メッセンジャーが生成された日時。
　　inquirerID：メッセンジャーの生成者を識別する一意なID。
　　answererID：メッセンジャーへの応答者を識別する一意なID。

inquirerIDとanswererIDはセッションごとに生成される。

539 ：266 ：01/08/26 16:03

以下にレスの検索から収集までのフローについての具体例を示す。

ピアＡが search メッセージを持つメッセンジャーを生成する。
この時にメッセンジャーの inquirerID を初期化する。
　　　↓
ピアＡは生成したメッセンジャーを直近のピアにばらまく。
　　　↓
メッセンジャーを受け取ったピアはそのメッセージをチェックし、
自分の抱えるキャッシュ内を検索してレスの有無を調べる。
レスが見つからなければ受信したメッセンジャーを複製して
更に自分の直近のピアにばらまく(無限拡散防止などはgnutellaとほぼ同じ)。
この時、「メッセンジャーをどのピアからどのピアへ中継したか」を記憶する。
　　　↓
あるピアでついにキャッシュにヒットしたら、
メッセンジャーのメッセージを found メッセージに置換し、
answererID を新たに生成した一意なIDで初期化する。
できたメッセンジャーは自分に search メッセージを送ってきたピアに送る。
　　　↓
found メッセージ付きのメッセンジャーを受け取ったピアは inquirerID を調べ、
自身が過去に生成したメッセンジャーのものかどうかを確かめる。
found メッセンジャーが自分の生成したものでなかったなら
過去の中継記録中にそのIDが含まれていないかどうかを調べる。
中継記録中に含まれていた場合は中継元に更に中継する。
　　　↓
あるピアでついに found メッセージ付きのメッセンジャーを受信できたなら
メッセージ部分を retrieve に書き換えて・・・以下略。

timeStamp はメッセンジャーの破棄に用いる。
すなわち、一定時間よりも前に生成されたメッセンジャーはその場で廃棄する。

540 ：266 ：01/08/26 16:03

続いて各メッセージについて。
メッセージは search, found, retrieve, response の四つとする。
この四つはこの順序で状態遷移するものでもある。

1)search メッセージ
レスの検索を行う。フィールドは次の通り。

　　　struct SearchMessage{
　　　　string　type = "search" ;
　　　　short　hopCountLeft ;
　　　　string　board ;
　　　　string　thread ;
　　　　resID_t　resFrom ;
　　　　resID_t　resTo ;
　　　} ;

board 板の thread スレの resFrom から resTo までの範囲のレスを探す
という意味になる。search メッセージに対しては found メッセージで応答する。
見つからなければ返信はせずに search メッセージを増幅してばらまく。

541 ：266 ：01/08/26 16:04

2)found メッセージ
検索結果の通知を行う。フィールドは次の通り。

　　　struct FoundMessage{
　　　　string　type = "found" ;
　　　　short　resCount ;
　　　　struct ResInfo{
　　　　　resID_t　resID ;
　　　　　short　resSize ;
　　　　　long　resHash ;
　　　　} resInfos[] ;
　　　} ;

search メッセージに該当するレスの一覧の情報を返す。
この時、必ずしも完全にヒットしていなくてもよい。
例えば、resFrom=1, resTo=100 の search に対して
1 〜 40 のレスしか持っていなくても返信してよい。
found メッセージを受信したピアは次の retrieve メッセージで応答する。
ただし、found メッセージ中のハッシュが 2ch.net から取得したものと
一致しなかった場合にはこれを無視してよい。


3)retrieve メッセージ
レス内容の提供を要請する。フィールドは次の通り。

　　　struct RetrieveMessage{
　　　　string　type = "retrieve" ;
　　　　short　resCount ;
　　　　resID_t　resIDs[] ;
　　　} ;

提供を要請する ID の列を resIDs に収める。
retrieve メッセージに対する返信として
ピアは次の response メッセージで応答する。

542 ：デフォルトの名無しさん ：01/08/26 16:07

>>531
キャッシュするやつは、スレッド単位でもつから
Disk容量はそんなになくてもよいという感じなのかしらん。
データ破棄は有効期間制という話だったと思うが。
あまりキャッシュ側にHigh Specを求めると参加者が集まらないかも。

543 ：266 ：01/08/26 16:12

4)response メッセージ
レス内容を提供する。フィールドは次の通り。

　　　struct ResponseMessage{
　　　　string　type = "response" ;
　　　　short　resCount ;
　　　　struct Response{
　　　　　resID_t　resID ;
　　　　　string　content ;
　　　　} reponses[] ;
　　　} ;

response メッセージを受信したピアは
content から改めてハッシュを計算して照合を行う。
この段階でハッシュが一致しなければ 2ch.net 上から直接レスを集める。


なお、セッションごとに状態遷移をきちんと管理すること。
ありえない状態に属するメッセージを受け取った場合には
エラーとみなしてこれを廃棄する。

---------------------------------------
以上です。切れまくり(泣)おまけに連続投稿とか言われるし(泣)

544 ：1 ：01/08/26 16:17

resIDはどのように採番するんですか？
もし、各サーバントが勝手にシーケンスに採番にするとぶつかる可能性がある。
よって、resIDはランダムなぶつからないような番号がいいかと。
で、resFromとresToの代わりに時間を基準に「どの時間からどの時間まで」の方がいいかも。

545 ：266 ：01/08/26 16:18

>>544
resID は 2ch.net 上で生成してリストに保存し、
そのリストを 2ch.net から拾ってきて使います。
重要なのは時系列に沿って整列可能であることと
レスごとに一意であることです。

546 ：1 ：01/08/26 16:20

>>545
OK!
前提としてハイブリッドですね。

547 ：266 ：01/08/26 16:21

>>546
はい、そうなります。
これなら実装はかなり楽だと思いますがどうでしょ？
穴とかあったら突っ込みよろしくお願いします。

548 ：1 ：01/08/26 16:22

>>266
これ以外に、自分がネットに追加された意思表示をするプロトコルは不要ですか？

549 ：デフォルトの名無しさん ：01/08/26 16:22

>>537
ハッシュというかIDというか、MD5ならC言語で
http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=1321&type=ftp
RFC1321でソース付きであるから、E-tagで困難なら
試してみるのもいいかも知れない。128bit長です。
一応、署名とかでも一意性の確認に使われてたから少しはましかも。
速度だけだったらCRCの方が良いかもしれんけど。

550 ：266 ：01/08/26 16:24

>>548
今はこういう形を考えてます。
ただ、375 さんにご指摘いただいたように
USER_AGENT を偽装してアタックをかけ
ピア一覧を壊すという可能性があります。

> ●ピア管理について
> ピア管理は 2ch.net 上で行う。
> read.cgi に細工をほどこし、2ch.net にアクセスしてきたユーザーで
> USER_AGENT が P2Pcache のそれになっているユーザーのIPを
> アクセスされた板の住人としてピア一覧に登録する。

551 ：266 ：01/08/26 16:26

>>549
ども。
2ch.net 上では多分 perl でハッシュを生成することになると思います。
ので、双方で扱いやすいものがいいんですが、MD5 はこれに該当するでしょうか？
ETag の方は resID に使えるんじゃないかと考えてます。

552 ：1 ：01/08/26 16:28

2ch.netで持つ情報はIPだけですか？searchはすべてのPeerに投げるんですか？Peerから自分の持っているboard、threadを告知して2ch.netにその情報をキャッシュした方が効率がいいような気が･･･。>>548はそういう意味です。
Napsterは最初に自分の持っている曲のリストをサーバに上げるんだった記憶が。

553 ：1 ：01/08/26 16:29

>>551
perlのMD5モジュールってあった気が･･･。

http://search.cpan.org/search?mode=module&query=MD5

554 ：266 ：01/08/26 16:32

>>552
なるほど。これは難しいところですね。

IPに加えて参照頻度を追加してもいいかもしれません。
あるいはIP一覧がリクエストされるごとにローテーションさせるとか。

全部のピアにデータを送るのは無謀だと思います。
これについては高々数十個程度のアドレスを集めればいいだろうと思ってますが
P2Pアプリを作ったことがあるわけでもないんで根拠レスです。

鯖側にある程度の調整をさせるかどうかはCPU負荷次第でしょうね。
余裕があるなら鯖側でやった方が何かと調整が効いていいと思います。

555 ：1 ：01/08/26 16:34

>>266
ところで、すでに作り始めてます？

556 ：266 ：01/08/26 16:37

>>555
いえ、まだ１行も書いてません(藁
俺はネット関係とか実務経験がなくて
趣味でちょこちょこやってただけなんで色々と読んでるところです。

557 ：1 ：01/08/26 16:49

>>556
なんでも、わからないことあったら聞いてください。
ネット関係は自信あります。Winには弱いんで。
266さんのをPHPとPerl/CGIで実装してみますね。

558 ：266 ：01/08/26 16:54

>>557
ありがとうございます：）
早速なんですがピア間の通信は
TCPよりもUDPの方がよいような気がするんですが
UDPだと何か問題は出てきますか？
俺の理解の範囲内だと response メッセージで
大量のメッセージを一度に送る場合以外は問題ないように思えるんですが
穴があったらご指摘ください。

559 ：1 ：01/08/26 16:57

>>558
F/Wを超えないことがある。＜ UDP

560 ：266 ：01/08/26 17:02

>>559
UDPとTCPでは前者の方がブロックされていることが多い、ということですね。
これはADSLとCATVユーザーの環境で一般的な問題にもなりますね。
プロバイダ板あたりで聞けば分かるかな？

561 ：デフォルトの名無しさん ：01/08/26 17:03

>>553
perlのMD5チェックしてみました。
大抵は入っていると思いますが、入ってなければ、
http://www.cpan.org/modules/by-module/Digest/Digest-Perl-MD5-1.5.tar.gz
解凍して、MD5.pm突っこんで、@INC設定されてなければ
指定すればOKそうです。

ex)
./Digest-Perl-MD5-1.5/lib/Digest/Perl/MD5.pmにおいた時。
---
#!/usr/bin/perl -w -I./Digest-Perl-MD5-1.5/lib
use Digest::Perl::MD5 'md5_hex';
print 'Digest is ', md5_hex 'foobarbaz', "\n";
---

562 ：1 ：01/08/26 17:09

CATVはNATを通しているケースもあるので、UDP通らないケースが多いと思います。
ADSLはグローバルが多いのかな？（うちはそう。）

563 ：aki ：01/08/26 17:15

便利そうだったら使ってみてください。
http://www.gedoh.org/aki/2ch/wiki/

564 ：1 ：01/08/26 17:19

あ、後思ったんですけど、P2Pのstructの最初の要素ってstringなんですか？(charへのポインタ?)
char[]だとしても、structの大きさがぶれるので、intなどのような大きさがはっきりしたほうがよくないですか？

565 ：1 ：01/08/26 17:21

>>563
Wikiって何？ごめんなさい、無知で。

566 ：266 ：01/08/26 17:23

>>564
すいません。その辺はまだ適当に書いてあります。
実装するなら固めなくちゃいけませんね。
ゼロ終端の可変長文字列を割り当てて
メッセージの先頭か Header の末尾に long size ; フィールドを
入れるということにしましょうか？
これから改めてきちんとした定義を書いてみます。

567 ：266 ：01/08/26 17:32

サイズ情報を追加しました。
string はゼロ終端の文字列を表します。

　　struct SearchMessage{
　　　　long　　size ;　// メッセージサイズを示すバイト数。
　　　　string　type = "search" ;
　　　　short　 hopCountLeft ;
　　　　string　board ;
　　　　string　thread ;
　　　　resID_t resFrom ;
　　　　resID_t resTo ;
　　} ;

　　struct FoundMessage{
　　　　long　　size ;
　　　　string　type = "found" ;
　　　　short　 resCount ;
　　　　struct ResInfo{
　　　　　　resID_t resID ;
　　　　　　short　 resSize ;
　　　　　　char　　resMD5[16] ;
　　　　} resInfos[ resCount] ;
　　} ;

568 ：266 ：01/08/26 17:32

　　struct RetrieveMessage{
　　　　long　　size ;
　　　　string　type = "retrieve" ;
　　　　short　 resCount ;
　　　　resID_t resIDs[ resCount] ;
　　} ;

　　struct ResponseMessage{
　　　　long　　size ;
　　　　string　type = "response" ;
　　　　short　 resCount ;
　　　　struct Response{
　　　　　　resID_t resID ;
　　　　　　string　content ;
　　　　} reponses[ resCount] ;
　　} ;

問題は string の文字コードをどうするかということと
resID_t の中身をどうするかといったところです。
後者はそもそも何を resID のソースにするかにもよりますね。
提案よろしくお願いします。＞諸氏

569 ：aki ：01/08/26 17:33

>>565
ええっと、ページの内容を誰でも自由に更新できる掲示板の亜種です。
試しに書き込みしてみると感覚つかめるかも知れません。

570 ：1 ：01/08/26 18:00

>>568
言語PHP、プロトコルXML-RPCで実装してみます。

571 ：デフォルトの名無しさん ：01/08/26 18:22

>>568
:問題は string の文字コードをどうするかということと
既存の2chのdatがSJISなのでSJIS統一が移行が楽なんでわ。

:resID_t の中身をどうするかといったところです。
search->found->retrieve->responseが一つのセッションで
行われるなら、searchにて、boardとthreadが指定され範囲が
スレ内の一意性に帰着するから、datの頭からの行数をresID_t
にして、番号ずれが起きないように、削除時には\nは消さないで
削除マークを付けるのは如何?
行数==resID_tなら採番はしなくて済む。
また、書込は2ch.net一ヶ所で受けるから矛盾はでないはず。
ただし、searchからが一連のセッションでないなら、
retrieve, responseにも、board, threadを指定しないと、
resID_tだけで一意に特定するのは困難だと思う。

ちなみに、他すれでindexつけたいね、という話がありましたから
board, threadは、stringでなく、一覧で数値管理の方が、
はやいしトラフィックも少しだけ減るかも。

572 ：1 ：01/08/26 18:35 ID:XPQqFrCs

P2Pの方なんだけど、どの時点でサーバントがほかのサーバントにアクセスして、メッセージをもらうの？
IPとポート（あるいはURL）を取得する手段がないような･･･。
>>567、>>568ってP2Pの方ですよね？

573 ：1 ：01/08/26 18:37 ID:XPQqFrCs

あれ？メッセージに急にIDがついた。

574 ：デフォルトの名無しさん ：01/08/26 18:38 ID:Lpd6qptI

test

575 ：266 ：01/08/26 18:39 ID:V6I8TU7U

>>571
素直にレス番号を使うということですね。それでやってみます。
search から response までは一つのセッションにまとめられます。
board, thread の番号も long あたりで表現できるなら楽でいいです。
ところで今のスレ番号って time か何かの値ですよね？
そうなら板名と long 値のペアで当面は表現できます。

576 ：266 ：01/08/26 18:42 ID:V6I8TU7U

>>572
まず >>567, >>568 はP2Pのメッセージフォーマットの話です。
それでサーバントのアクセスですけど、
IPとポートは 2ch.net にアクセスしてリストをもらいます。
このリストはユーザーが 2ch.net にアクセスしたときに
read.cgi か何かで生成してもらうものです。
リストを取得したらサーバントの方で適宜コネクションを張ります。
コネクションを張りっぱなしにするかどうかは思案中です。
あと、鯖上に若干 IP が残ることになるわけで少し問題があるかも。

577 ：1 ：01/08/26 18:58 ID:XPQqFrCs

SearchMessage <-> FoundMessageはサーバント、2ch.net間、RetrieveMessage <-> ResponseMessageはサーバント間ならば、

FoundMessageにIPなどの情報が必要、RetrieveMessage にboard、threadの番号が必要になると思う。

578 ：266 ：01/08/26 19:11 ID:GCamoJZ2

>>577
SearchMessage から ResponseMessage までは
全てサーバント間でやりとりされます。
FoundMessage は SearchMessage が通過してきた中継ピアを
逆向きに経由して発信元に届けられます。
中継ピアが中継履歴を残しておけばMessage中にはIPは不要です。
多分これで大丈夫なはず・・・。

現在はC++で内部設計を検討中です。

579 ：デフォルトの名無しさん ：01/08/26 19:20 ID:EzeLIkVE

>>576
ざっくりいうとこんな感じっすか?

client -[GET]-> cache(※1) ---> www.2ch.net
※1：なにもしない

cache(※2) <-[一覧(board, thread, cache_ip_port)]- www.2ch.net
※2：自分のとこと他のcacheにsearchから始まる一連の問い合わせを
して回答を回収する。記事の正当性検査は、2chからもらった一覧と
FoundMessageをつき合わせる。

client <------ cache(※3)
※3：回答をまとめて返す。

580 ：266 ：01/08/26 19:23 ID:GCamoJZ2

>>579
はい、そうなります。
細かいところですが正当性の検査には
更に自前でのMD5生成と照合があります。
これは嘘や間違ったFoundMessageの影響を押さえるためです。

581 ：デフォルトの名無しさん ：01/08/26 19:28 ID:EzeLIkVE

>>akiさん
まだ、ソース公開以前の雛型つくりだから、
Wikiをつかうのはもうすこし先かも。

582 ：375 ◆MsUYMX0E ：01/08/26 19:54 ID:2YfzLsYM

激遅レスですみません..

>・内部の大まかな処理フロー
>　　1)ブラウザが HTTPd にアクセスすると HTTPd が動作しはじめる。
>　　　以下、この HTTPd をクライアント、ピアの HTTPd をキャッシュと呼ぶ。
>　　2)クライアントは2chのスレを読み込もうとしたときに次の手順をとる。
>　　　　i)2ch.net からスレやレスの目録リストを取得する。
>　　　　ii)リストを元に検索クエリーを生成してピアにばらまく。
>　　　　iii)ピアからの返事を一定時間待つ。
>　　　　iv.a)ピアからの返事があればそこからデータをもらう。
>　　　　　　　データは 2ch.net から取得したリスト中のハッシュと照合を行う。
>　　　　iv.b)時間内にピアからの返事がないか もしくは
>　　　　　　　上記の照合で失敗したら 2ch.net からデータを直にもらう。
>　　　　v)自分が獲得したデータはキャッシュする。　(※１）
>　　3)書き込みは 2ch.net に対して直で行う。
>　　4)鯖はピア一覧のみを管理する。
>　　　　i)2ch.net 上に適当な CGI を用意してピア一覧の取得を可能にする。

※１でデータをキャッシュする必要は必ずしもないと思うのですが..
たしかにキャッシュしたほうが望ましいですけどピア　と　ローカルhttpdの2段階で
キャッシュすると結構話が面倒になりません？

あと

>>538-541 っていうのは 2ch.net の介在無しにピア間でログをやり取りするってことですか？

583 ：266 ：01/08/26 20:04 ID:GCamoJZ2

>>582
ども。
※１の部分のキャッシュするというのは
他のピアからも参照されるものとしてキャッシュするという意味です。
ローカルのキャッシュとピアのキャッシュは統合します。

>>538-541 はおっしゃるとおりです。
2ch.net はピア一覧の取得とレスリストの取得、
それからキャッシュヒットミスに際してのみ利用します。

そろそろ実装を始めようかと思ってC++Builderとにらめっこしてます(藁
色々とネット関係のコンポーネントとかあるんで
品質を度外視すれば割とサクっと作れそうではあるんですが・・・。
俺どうも今晩以外に時間とれそうにないんであんまりいい加減なものは
作りたくないところなんですよ。さてどうしたものか。

584 ：375 ◆MsUYMX0E ：01/08/26 20:11 ID:2YfzLsYM

>>583

今いままでのをまとめたへぼいプレゼン資料作ってます。
実験に参加してもらうにはいずれ必要になるかと思って..

さしあたって今日中に出来る限りで物にしてしまったほうが
いいのではないでしょうか？　もしソース公開して頂けれるのなら
我々でも多少は何とかできますし。

もちろん最終的には266さんの判断にお任せします.

585 ：375 ◆MsUYMX0E ：01/08/26 20:31 ID:2YfzLsYM

>>584

追加
ただ、あくまで個人的な意見ですがもし >538-541 のようなP2Pでの
キャッシュ交換の実装が難しいなら、初回は見送ってもいいと思います。
（キャッシュヒットミスしたらすぐ2ch.netに見に行く）

個人的な感触ではここの実装は結構手間取りそうなので。

586 ：266 ：01/08/26 20:33 ID:GCamoJZ2

>>584
ご協力感謝です。
とりあえず動くものをということで書いてみることにします。

587 ：デフォルトの名無しさん ：01/08/26 23:29 ID:JO3B7aqU

Gnutellaのプロトコルで実装するとユーザー数が極端に増加した場合、
途中経路で転送がストップするようなことになると思うのですが・・・・

588 ：デフォルトの名無しさん ：01/08/26 23:29 ID:Kg2ClUug

>>585
一応、私なりにまとめてみた。。。仕様と概要みたいなもの。
良ければ使ってくれ。このスレの発言も引用しているので
消したり直したい人は自由に編集／削除／更新してけれ。
http://www.gedoh.org/aki/2ch/wiki/yukiwiki.cgi?mycmd=read&mypage=%5B%5Bread%2Ecgi%82%CC%8Ed%97l2%5D%5D

589 ：デフォルトの名無しさん ：01/08/26 23:37 ID:Kg2ClUug

>>587
いや、発想は使っているがもはや独自プロトコルみたい。
ユーザ数が増加して、P2Pcacheが追いつかない場合には
マスタ(2ch)にとりにくるので、最悪ストップはないと思う。
けど、それだけの負荷があるならむしろ2chからは取得せずに
ビジー表示した方がいいのかもしれない。
詳細はこのスレ全部みるか、588のリンクみてけれ・・・・。

590 ：375 ◆MsUYMX0E ：01/08/26 23:38 ID:2YfzLsYM

>>588

多謝です..

591 ：1 ：01/08/27 00:45 ID:UQn5rfWU

>>578
突込みばかりで、すいません。
サーバントとサーバントが直接やり取りすることがないならば、それはP2Pではないように思います。
今の発想は要するに Webサーバ<->Proxyサーバ<->ブラウザ の関係に似ているんじゃないでしょうか？（違ってるかな？）
P2Pの良さはハイブリッドP2PでもピュアP2Pでもデータ量が多いやり取りを直接サーバント間でやることだと理解しているのですが･･･。

592 ：375 ◆MsUYMX0E ：01/08/27 00:50 ID:k3MsBTsc

#プレゼン作ったんだけど和塩には置けないようだ..

266ではないのですが
>>591

>今の発想は要するに Webサーバ<->Proxyサーバ<->ブラウザ の関係に似ている
>んじゃないでしょうか？（違ってるかな？）
>P2Pの良さはハイブリッドP2PでもピュアP2Pでもデータ量が多いやり取りを直接
>サーバント間でやることだと理解しているのですが･･･。


>538-541 にもあるように、キャッシュ間でログをやり取りすることも
２６６さんは考えていらっしゃるようです。

593 ：デフォルトの名無しさん ：01/08/27 00:52 ID:gI46IMVY

名前：
E-mail：
内容：
ADSLとかCATVでグローバルIP保持者も多くなってるこのごろだし・・・
小さいwebサーバ＋Replication（2chエージェントと呼称）を組み合わせて、
クラスターにしてしまうというのはだめ？

・2chサーバ：エージェントとスレッドのディレクトリ、repilcation指示、仮想2chエージェント
・2chエージェント：スレッドデータの管理と読みこみ・書きこみ代行
としてテキトーに以下考えてみた。
----
・常時接続可能な人達が、2chエージェントを自動起動
　起動されたら、2chサーバに起動したことを通知
　通知後、受け持ちスレッドがある場合、
　2chサーバからreplication相手が誰か教えてくれるので、
　その相手からデータをSyncronizeしてもらう。
　Syncronize完了後、2chサーバに受け持ちスレッドのSyncronize完了通知をあげる。
　2chサーバは、その2chエージェントのスレッドが利用可能であることをディレクトリに書く

・2chサーバは2chエージェントのディレクトリサービスを受け持ち、
　2chエージェントが起動されたら起動通知要求を受け取り、
　ディレクトリエントリに追加

・各2chエージェントは1スレッド〜nスレッド分のデータを保持する。
　（インストール時にUD-Agentみたいに、マシン能力チェックを行い、nを決定）
　2chエージェントの停止に備えて、複数の2chエージェントが
　同一スレッドのデータをreplicationして保持する。
　replication相手の指示は、2chサーバからときどき2chエージェントに対して行う。

・読みこみ要求はブラウザより2chサーバに行く
　一括表示は、2chサーバがframeをきり、
　保持しているディレクトリ情報にしたがって、1スレッドごとに具体的なURLを出力。
　ブラウザ側は1スレッドごとに異なる2chエージェントに対して読みこみを行うことになる。

　スレッド内の表示は、2chサーバがブラウザに対してmetaタグのrefreshで
　2chエージェントへ誘導して表示

・書きこみ要求は2chエージェントが受ける
　2chエージェントはreplication相手に対してr/w排他要求を出し、
　自分で保持しているデータの更新を行う。
　更新後は更新差分をreplication相手に送り、同時にr/w排他を取り下げる。
　その後、2chサーバに対して、受持ち分スレッドデータの更新通知をだし、
　スレ位置の変更を2chサーバに行わせる。

・新規スレッドの作成は2chサーバが行い、ディレクトリエントリを更新（スレッド情報）
　空き2chエージェントがない場合、
　2chサーバ自体がエージェントとなり、スレッドを受け持つ。
　空き2chエージェントがある場合、
　空き2chエージェントに対して、
　・新規スレッドの作成依頼
　・replication相手の指示
　を行う。

594 ：デフォルトの名無しさん ：01/08/27 00:54 ID:gI46IMVY

1スレッドあたり2chエージェントを6つ・・・持てたらいいなぁ（＾＾；
無理か。

595 ： ：01/08/27 00:55 ID:.A.boK1.

ひろゆきの2ch継続意志はそれほど強くないようなので、
2ch.netに依存するのは危険。脱ひろゆきのシステムを今から考えて
おくべきだと思います。

596 ：375 ◆MsUYMX0E ：01/08/27 00:57 ID:k3MsBTsc

>593

多分我々がやろうとしてるのとよく似たアイデアだと思うのです。

できれば一度過去ログ読んでお互いやろうとしてることを理解してからのほうが
いいと思うのですが..

もしすでにログをご覧になっての発言でしたらごめんなさい。

597 ：375 ◆MsUYMX0E ：01/08/27 00:58 ID:k3MsBTsc

>595

うーん、完全なP2P化ってことでしょうか？
このスレの上のほうでもいろいろ議論されてるのですが
結構難しいみたいですよ

#どこかバナーがつかない無料HP置き場ないですかね？

598 ：デフォルトの名無しさん ：01/08/27 01:14 ID:peqYVPM.

>>593
>クラスターにしてしまうというのはだめ？
今取り組んでいるのも似た感じす。HTTPdの機能も予約済みす。

>・2chサーバ：エージェントとスレッドのディレクトリ、repilcation指示、仮想2chエージェント
>・2chエージェント：スレッドデータの管理と読みこみ・書きこみ代行
・2chサーバ：エージェントとスレッドのディレクトリ、repilcation指示
・P2Pcache：仮想2chエージェント、スレッドデータの管理と読みこみ
な感じです。管理主導はスレも2chサーバ側ですが。
書きこみ代行は、データの一貫性とかいろいろ考えると面倒なので
そこまで追いついていない感じ。最終的には必要なのかも。
ただ、既存のクラスタのソフトは重そうというのと、我等PG屋なので
アプローチがとりづらい部分があるので自前で必要な分を作ってる幹事巣。
簡単に改造で済むクラスタのソフトがあれば手がつくかもなのですが。

330KB

---

新着レスの表示

---

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30