---

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

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

475 ：375 ：2001/08/26(日) 02:41

>>473

どの時点のハッシュをとりに行くかが問題では？

キャッシュからレス取得
↓
ハッシュ計算　　(その間に新たな書き込み）
↓
ハッシュを2ch.netにとりにいく
↓
ハッシュ食い違う
↓
ﾏｽﾞｰ

ってことがありえるような

476 ：266 ：2001/08/26(日) 02:44

ポイントを改めて書いてみます。

●index2.html にアクセスする時
ttp://www.2ch.net/board/p2p.cgi?do=floterlist にアクセス。
スレ番号の一覧が帰ってくる。
その一覧を元に各スレにアクセスする。

●特定スレにアクセスする時
ttp://www.2ch.net/board/p2p.cgi?do=reslist&thread=XXXXXX&from=XX&to=XX にアクセス。
レスのハッシュとサイズのペアの一覧が帰ってくる。
一覧を元に検索クエリーを投げ、レスのデータを集める。
その時にはもちろんサイズとハッシュを照合する。

これなら単純で安全性も高いと思いますがどうでしょう？

477 ：266 ：2001/08/26(日) 02:45

>>475
鯖へのアクセスが全てに先行します。
鯖にアクセスしてから、鯖から取得したリストにあるレスを集める、という格好です。
最初からキャッシュにアクセスするというのは無しにするわけです。
もちろん転送量は若干食いますけどスレを直接読むよりもずっと軽いはずです。

478 ：225 ：2001/08/26(日) 02:45

>>473
基本的には一分間に10もレスが付くような状況にも対応するにはどうしたらいいかって事だよね。

479 ：266 ：2001/08/26(日) 02:47

>>478
すいません。話が見えません。
改竄防止のために鯖上にある信頼できる要約データに従ったものしか
キャッシュからは集めないという話です。

480 ：266 ：2001/08/26(日) 02:48

補足です。
この要約データは鯖側のCGIで生成してもらう必要があります。
つまり、書き込みをした時についでで生成してもらうわけです。

481 ：375 ：2001/08/26(日) 02:52

>>477

たしかにサイズが違えばリトライすればいいわけですね。
唯一あぼーんされてなおかつサイズが同じ時にハッシュが食い違って
エラーになる可能性があるのかな？

具体的には

クライアントがあるスレのA〜Bのハッシュとサイズをゲット
↓
(この間にあぼーん。サイズは変わらず）
↓
クライアントがA〜Bをcacheに要求
↓
cacheからゲットしたデータのサイズ→OK
↓
cacheからゲットしたデータのハッシュ→NG
↓
ﾏｽﾞｰ

482 ：266 ：2001/08/26(日) 02:56

>>481
ハッシュが一致しなかった場合には
鯖まで取りに行くということではどうでしょう？
これでもまだ転送量軽減には十分な効果があるはずです。
実際にハッシュがどうしても一致しないものってそんなには出ないはずです。
出るとしたら大掛かりな妨害が行われてるわけですから。
あと追加で、あぼーんリストだけ別個に作ってもらって
たまにチェックするようにしてもいいかもしれませんね。

483 ：266 ：2001/08/26(日) 02:59

みんなもう寝ちゃいました？(藁

484 ：375 ：2001/08/26(日) 03:00

あと　&ls=100　っていうリクエストについてはどうしましょう。
強制的に &st=XX&to=XX に置き換えさせないと示すレスの範囲が
変わってしまいますよね.

485 ：266 ：2001/08/26(日) 03:02

>>484
それは p2p.cgi に ls オプションの処理をつければいいと思います。
p2p.cgi は今の read.cgi とほぼ同様の機能を持っているけれど
出力されるデータはスレ番号やレス要約の一覧ばかりである、
というような格好が適当じゃないでしょうか？

486 ：225 ：2001/08/26(日) 03:02

＞480
要はETagのリストだよね。

487 ：うーん ：2001/08/26(日) 03:02

ちょっと、待って・・・
ハッシュのチェックをするのはどこ？
キャッシュサーバーで改竄されたとすると、
そのキャッシュサーバーからハッシュデータ受け取っても意味なしなんだけど。

488 ：266 ：2001/08/26(日) 03:04

>>486
そうなりますね。
ところでETagをレスごとに生成できるんでしょうか？

489 ：266 ：2001/08/26(日) 03:07

>>487
まず、2ch.net 上にハッシュのリストがあります。
これは書き込み時に生成されるもので、絶対に正しいとして信頼します。

2ch にアクセスする際にはこのハッシュのリストを 2ch.net から取得し
リスト中にある情報を元に検索クエリーを生成してばらまきます。

クエリーの結果として発言のハッシュなどがサーバントから帰ってきます。
正しい結果を返してきたサーバントから改めてレスのデータを受信します。

受信したデータから自前でもハッシュを生成し
鯖から取得したものと比較します。
これで一致しなければ鯖から直接にレスを取得します。

こういう流れです

490 ：266 ：2001/08/26(日) 03:09

>>489
あ、鯖っていうのは 2ch.net のことです。

491 ：225 ：2001/08/26(日) 03:12

>>488
>Last-Modified: Sat, 25 Aug 2001 18:04:23 GMT
>ETag: "10e859-28027-3b87e8a7"

>Last-Modified: Sat, 25 Aug 2001 18:07:20 GMT
>ETag: "10e859-2830e-3b87e958"

レスがつくと変わるみたいだ。

492 ：266 ：2001/08/26(日) 03:14

>>491
おおっ、これは使えるかも。
ETagってperlから取得できますか？
取得できるならETagを保存すれば
スレのレス要約リストについては問題なしですね。

493 ：うーん ：2001/08/26(日) 03:16

>>489
いや、手順じゃなくって、どこがなんだけど、
ブラウザでそれをやるってことですよね？

494 ：375 ：2001/08/26(日) 03:19

>>493

ブラウザ（IEとか)ではなくて、各自のPCにたてるhttpd(のようなもの)
がです。これを改竄しても意味ないですし。

495 ：266 ：2001/08/26(日) 03:21

ちょっと難民板のぞいてきました。
いやかなりヤバいみたいですね。
存続する意向自体はあるみたいだけど金銭的に見てでかすぎる、と。

496 ：＿ ：2001/08/26(日) 03:23

『レースレーサー板』の総合スレッド表示が1つしかできないようになっています。
皆さんのおチカラでなんとかなりませんか？

497 ：266 ：2001/08/26(日) 03:23

>>493
>>432 のあたりをご覧ください。
>>494 での 375 さんのおっしゃる通り
クライアント上で動作する似非プロキシや HTTPd のようなものを考えてます。

498 ：225 ：2001/08/26(日) 03:26

まあ、一言でいえばグヌテラな烏賊串かな？
上位串は固定じゃなくて、適当に選ぶって感じか？

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

330KB

---

新着レスの表示

---

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

0ch BBS 2004-10-30