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

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

385 ：375 ：2001/08/26(日) 00:41: >>380
>>382

　たしかに４はIf-Modified-since を使ったほうがいいですね。

あと問題なのが、２ｃｈの売りでもあるフローティングスレッドをどうやって実現するかなんですが

１．www.2ch.net のほうで最新書き込み順に並び替えたページを見せる（リンク先はキャッシュ内）
２．キャッシュ側で独自に生成する。ちょっとずれることがあるかも

１にした場合でも各自で使ってるキャッシュが違うので、やはりキャッシュ経由でアクセスすることになり、結局
2ch.net からはスレIDだけを送ればいいので転送量はあまり増えないと思うのですが..
386 ：デフォルトの名無しさん ：2001/08/26(日) 00:42: 閑散とした板だとレスポンスもさらに悪し。
と思ったけど、>>383=266のグループってのが良いアイディアですな。
387 ：デフォルトの名無しさん ：2001/08/26(日) 00:43: >>377
> 既存のキャッシュの概念って2chみたいな異常な更新頻度のものに
> 対して設計されているのか疑問なんだが。
HTTPに限って言えば、サーバ側からクライアントに対しては「キャッシュする・しない」しかコントロールできない。
クライアントからサーバに対しては「俺はこの時間に更新されたコンテンツを持ってるんだけど、それから更新されている？」という問い合わせしか出来ない。
「更新が定期的に発生する」ことを前提にキャッシュするなら、別の方法を考えた方がいいのかもしれない。
388 ：266 ：2001/08/26(日) 00:44: キャッシュを効果的にするためには差分更新も必須だと思う。
となると、クエリー中にはレス数やファイルサイズなどの情報があった方がいいね。
389 ：375 ：2001/08/26(日) 00:46: >>385 の説明がちょっと意味不明ですね。僕が考えてるのは１の場合で
キャッシュはwww.2ch.net から

990334284　990335283　990334286　99033625

って感じで最近書き込みのあった順番でならんだスレのIDだけをうけとり、それから自分の持ってる
ログでフローティングスレッドを生成してクライアントに見せる

っていう方法なんですが..
390 ：266 ：2001/08/26(日) 00:47: >>385
俺は１の方を支持します。
ただし、必要最小限のデータを格納したファイルを鯖に置いてもらう形で。
スレ番号を並べたファイルがあればそれを取ってくるだけで大丈夫でしょう。
あとはキャッシュにアクセスして集めれば済む話ですから。
391 ：266 ：2001/08/26(日) 00:47: >>389
かぶった(藁
392 ：375 ：2001/08/26(日) 00:49: >>266

なんか同じような事考えててもらえて心強いです..
393 ：デフォルトの名無しさん ：2001/08/26(日) 00:52: ここまでの話だとwww.2ch.netという中央集権的なサーバの
存在が前提になっているけど、これをなくしたらどうだろう。
マスターサーバは存在せず、各クライアントの差分内容だけを
隣に伝えていく、みたいな。
例えば書き込みが発生したら、隣のクライアントにバケツリレー
で書き込みの内容が反映されていくようなイメージ。
394 ：266 ：2001/08/26(日) 00:53: >>393
今はキャッシュ以上のことを考えると自爆すると思います。
あくまでも背伸びせずに今必要とされているものを、ということで。
そもそもキャッシュだけでもキャッシュ対象の粒度や
更新頻度が尋常じゃないんで簡単じゃないはず。
395 ：過去ログ読め ：2001/08/26(日) 00:54: >>393

上のほうでがいしゅつ。で結構難航しそうなのでハイブリッドにしようということになった。
396 ：デフォルトの名無しさん ：2001/08/26(日) 00:55: いろいろ考えているんだが、2chみたいのはP2Pには
なじまない気が。なんというか危機回避のためでは
なく単にP2Pで実験するスレになりそうな予感がする。

少なくともオレなら不安定なgnutella型のプロトコルはお断りだ。
データは確実に同期しないとユーザがついてこないだろう。
397 ：225 ：2001/08/26(日) 00:56: 久しぶりに盛り上がってる、って鯖飛んでるのか？

とりあえず、p2p参加者の中で定期的に更新情報を収集する役を決められないかな？
まあ、２ｃｈ側で発信してくれれば問題ないんだけど。
398 ：：2001/08/26(日) 00:58: お、なんかいろいろあった一日だったんだね。

しかし、当面の間、転送量を少なく出来たとしても、２ちゃんねるが儲からない
こと、裁判のリスクをかかえていることに変わりはなくPureなP2Pに以降せざ
る負えないと思うけどな。
399 ：375 ：2001/08/26(日) 00:58: >>396

書き込みはいままでと同様集中管理なのでスレはアトミックに
更新されるとおもうのですが...

なにか同期に失敗するケースってあります？
400 ：266 ：2001/08/26(日) 00:59: >>396
いや、今は単純に２ch危機対策ってことで。
２chの機能全部をP2Pにするのは難しいから、という話とはちょっと違うかと。
まずは２chがつぶれたら困るからそれを阻止しなくちゃ(藁
それに、そっちの方向へ進む際にもとてもいい資料になると思いますよ。
401 ：393 ：2001/08/26(日) 01:00: >> 395
> 上のほうでがいしゅつ
ほんとだ。すいませんでした。
402 ：225 ：2001/08/26(日) 01:03: >>396
gnutella型のプロトコルって、検索の事を言ってるのかな？
探しても見つからないから不安定だって事？

とりあえず、GNETとしてだけ利用すればいいんだと思うけど?。
403 ：デフォルトの名無しさん ：2001/08/26(日) 01:03: とりあえずこの話は止めて，今の2ちゃんをなんとかしよう。

2ちゃんに合ったP2P方式を編み出せても，
2ちゃん自体が無くなっていてはどうしようもない。

さぁ，みんなもCodeを書こう！
404 ：デフォルトの名無しさん ：2001/08/26(日) 01:09: マスタサーバ(2ch.net)は以下の2つの情報をクライアントに返せばよいのかな？
1. 最新のスレッド一覧
2. スレッド内の各書き込み
各クライアントはそれぞれの情報をキャッシュしている。
んで、お隣さんから要求があると 1. 2.を読みにいく。(If-modified-since付きGETで）
書き込みはマスタサーバ 2ch.net に書き込む。
... 結局2ch.net全体のコンテンツをキャッシュしているだけのような気がしますが。
405 ：375 ：2001/08/26(日) 01:12: >>404

>... 結局2ch.net全体のコンテンツをキャッシュしているだけのような気がしますが。

いや、それが目的なので..

ところで266さん、あと決めることって何でしょう？
406 ：266 ：2001/08/26(日) 01:13: >>405
とりあえず今までの分をまとめてます。ちとお待ちを・・・。
407 ：266 ：2001/08/26(日) 01:15: >>406 までの内容のまとめです。

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

●製作にあたって何を固めなければならないか？
★はコメントを表します。

・対象プラットフォーム
　　　現在の候補：Win32, Mac

・基本的な外部要求仕様
　　　候補１：クライアントマシン上で動くキャッシュ専用似非串。
　　　候補２：クライアントマシン上で動く HTTPd。ページの中身は２ch。

・内部の大まかな処理フロー
　　　1)各クライアントは読み出したスレをキャッシュする。
　　　2)クライアントは2chのスレにアクセスしようとしたときに
　　　　検索用クエリーをばらまき近場のキャッシュをまず探す。
　　　3)もしキャッシュヒットすればそこからデータをもらい、
　　　　なければ鯖から直にもらう。もらったデータはもちろんキャッシュ。
　　　4)鯖はピア一覧のみを管理する。

・プロトコルの仕様/分類
　　　1)クライアントがキャッシュを検索するプロトコル(クライアント⇔2ch.net)
　　　2)クライアントがキャッシュからデータをとるプロトコル(クライアント⇔キャッシュ)
　　　3)キャッシュが2ch.net からデータを取り込むプロトコル(キャッシュ⇔2ch.net)
　　　　　★2)も3)もHTTPでよい。
　　　4)2ch,net がスレの更新を通知するプロトコル (キャッシュ⇔2ch.net)
　　　　　★キャッシュに対するリクエストがあった時にだけ
　　　　　　鯖上のデータのタイムスタンプを調べれば不要では？
　　　　　★鯖に対してはIf-Modified-sinceを送ればよい。
　　　5)キャッシュが2ch.net に自分自身を登録するプロトコル (キャッシュ⇔2ch.net)

・その他
　　　1)板ごとに動的にピアグループを生成する(グループは鯖側で管理)。
　　　　検索クエリーは対象板のピアグループに対して投げる。
　　　2)検索がヒットしたかどうかはタイムアウトで判断。
　　　3)フローティングスレッドは刷れ番号一覧を鯖側に置いて
　　　　これを元にクライアント側で自主的に生成。
　　　4)差分更新を可能にするためにレス数やファイルサイズのような情報の管理が必要。
　　　5)更新頻度や情報の粒度が尋常でないことに留意する。

・開発チーム
　　　未詳。
408 ：266 ：2001/08/26(日) 01:16: あ、切れちゃった。
まずは決めやすいところからということで
対象プラットフォームと基本的な外部要求仕様を固めましょう。
409 ：266 ：2001/08/26(日) 01:19: ちょっと補足。
なんで似非串だけじゃなくて HTTPd を加えてるかというと、
既にブラウザの串が設定されちゃってるようなユーザーを意識してのことです。
こういうユーザーの環境でも動く似非串にしようと思ったら
多段串として組んでやらなくちゃいけないわけですよね。
そのことだけでもなく、似非串として組むなら
２ch以外のページへのアクセスをちゃんと素通りさせてやらなくちゃいけない。
それだったら、ローカルで動く HTTPd (中身は２ch)にして、
ユーザーには localhost にアクセスしてもらうってのが
お手軽だと思ったわけです。
410 ：名無し ：2001/08/26(日) 01:20: トラフィックのほとんどはWin32からでしょ？
411 ：266 ：2001/08/26(日) 01:22: >>410
Win用に限定するなら作るの早いんすけどね。
俺もBCB使いだから何かと楽ができるし。
Macはとりあえず除外って方向もありだとは思います。
412 ：デフォルトの名無しさん ：2001/08/26(日) 01:22: >>407
>・プロトコルの仕様/分類
>　　　5)キャッシュが2ch.net に自分自身を登録するプロトコル (キャッシュ⇔2ch.net)
5)が必要になる理由が良くわからんです。
2chがキャッシュにPUSHで通知するということ？でも、
> 4)2ch,net がスレの更新を通知するプロトコル (キャッシュ⇔2ch.net)
>　　　　★キャッシュに対するリクエストがあった時にだけ
>　　　　　鯖上のデータのタイムスタンプを調べれば不要では？
>　　　　★鯖に対してはIf-Modified-sinceを送ればよい。
となっていてキャッシュは2ch.netにPULLしにいくので登録は不要では？
413 ：デフォルトの名無しさん ：2001/08/26(日) 01:22: キャッシュのデータって改竄されないかな？
414 ：266 ：2001/08/26(日) 01:25: >>412
プロトコルの5)は処理フローの4)に対応するものです。
ピアの一覧は鯖側で管理するので
登録できるようにするためのプロトコルが要るんじゃないか、と。
ただ、板毎グループを作る方針で行くなら
２chのCGIに仕掛けを入れれば一覧管理できちゃうんで
プロトコルをばっさり削れるのは事実ですね。
ちなみにこれ、鯖側にIPが残るという問題もはらんでたりします。
いつどの板にアクセスしたかという程度の情報ですけどね。
スレやレスとの対応は分からないから実害はないはずだけど・・・。
415 ：375 ：2001/08/26(日) 01:28: >>413

改竄はいろいろ考えたんですが

1,たとえ改竄されたところで鯖(2ch.net)のデータが
書き換えられるわけではない
2.怪しければキャッシュを変えればすむ話

なのであまり実害はないと思ったのですが..

セキュリティホールになりうることがあればどしどし教えていただけると
助かります。
416 ：デフォルトの名無しさん ：2001/08/26(日) 01:28: Javaで作ろう。
LinuxもMacも救われる。
Java,Java,Java.
JXTA初の実用アプリってことで。
417 ：266. ：2001/08/26(日) 01:29: >>413
データ改竄は防止可能です。
暗号化して保存したり、Win専用にするなら
ソフトをサービスとして登録してファイルを終始ロックしておいたり。
418 ：：2001/08/26(日) 01:30: JXTAを使うとJXTAのライセンスに縛られない？
419 ：デフォルトの名無しさん ：2001/08/26(日) 01:30: いや、改ざんできちゃうでしょう。
問い合わせに対してうその情報を返すプログラムを書けばいいわけだし。
gnutellaでもこれが問題になったよね。
420 ：266 ：2001/08/26(日) 01:31: >>416
目的は２chの転送量負荷軽減なんで
一番手軽に作れる方法を選びたいところです。
JXTAって仕様もう完全に固まってましたっけ？
それにJava実行環境ってまちまちな気がするし。
421 ：266 ：2001/08/26(日) 01:32: >>419
あ～、そっちの話ですか。
まあ確かにそれをやろうと思えばできますけどね。
でもそれはすぐに見抜けます。
何故なら２chの本鯖に直でアクセスすればいいから。
422 ：名無し ：2001/08/26(日) 01:32: >>419 ごもっとも。公開鍵かclosedにするか。
423 ：375 ：2001/08/26(日) 01:33: >>419

えっと、クライアントからの問い合わせに対して
改竄されたレスを返すってことですよね？

で、自分自身は正当なソフトのふりしてピアに登録してもらうと。

でもそれで起きる被害ってせいぜい変なメッセージを見せられる
ぐらいだし、2ch.net 側でIP完全に把握されてるのだからすぐに
ばれると思うのですが..
424 ：375 ：2001/08/26(日) 01:34: >>423

自己レス。あ、でもいきなりブラクラ見せられる可能性もあるのか...
425 ：266 ：2001/08/26(日) 01:37: 改竄や悪意ある攻撃の類はあまり気にしない方がいいかと。
作るのは結局のところただのキャッシュだから
今現在の２chで行われているものと被害に大差はないでしょう。
データ改竄は２chに直アクセスすればすぐにばれるし
ブラクラにしてもHTMLを生でやりとりせずに
レスやスレのデータだけをやりとりすれば大丈夫。
というわけであまり心配してないんですがどうでしょう？
426 ：375 ：2001/08/26(日) 01:38: >ブラクラにしてもHTMLを生でやりとりせずに
>レスやスレのデータだけをやりとりすれば大丈夫。
>というわけであまり心配してないんですがどうでしょう？

えっと、っていうことはクライアントはいまのカチューシャみたいな
専用ソフトを使うのが前提ってことですか？

ぼくはあくまでブラウザでｈｔｔｐで普通にアクセスできるのを
考えているのですが..
427 ：375 ：2001/08/26(日) 01:40: >>426

ごめんなさい。ローカルにもピアを検索したりするソフトを
おくんでしたね。勘違いしてました。
428 ：225 ：2001/08/26(日) 01:41: えっと、今回はスレッドレベルのキャッシュの話なんだよね？

で、赤虫みたいな奴に、新着部分が改ざんされる恐れがあると。
429 ：名無し ：2001/08/26(日) 01:41: >>426
トレードオフ。
緊急事態と見れば専用プロトコル@Win32でいいと思う。
その他の人は普通にアクセス。
430 ：266 ：2001/08/26(日) 01:43: ん？えーと、クライアントはブラウザで見ることを考えてます。
だけど、ブラウザに表示されるのはあくまでも
こっちのソフトを通過した結果データなんで、
やばいものの混入はちゃんとフィルタリングできるし、
そもそもスレの書き換えも２chに直アクセスですぐばれるから意味ないだろう、と。
431 ：225 ：2001/08/26(日) 01:44: >>429
というか、その他の人には、p2p参加者のキャッシュをhttpで参照出来るように出来ればいいんだけどねえ。
432 ：266 ：2001/08/26(日) 01:45: 図示すればこういうことです。
| の左がクライアントマシン上の話で 2ch.net がオンライン。

ブラウザ⇔P2Pcache⇔|⇔2ch.net

ここで P2Pcache は似非串もしくは HTTPd として動くことを想定してます。
433 ："管理"者側の現状 ：2001/08/26(日) 01:46: 373 名前：マァヴ＠削除管理委員長 ★ 投稿日：2001/08/25(土) 22:47 ID:???
もう一度、現状について・・・・
１　来週、Big-Serverとひろゆきの間で打ち合わせがもたれる。
２　その打ち合わせの結果にもよるけど、基本的には転送量の現状維持は不可能。
３　少なくとも今の形態であるかぎり、規模縮小は不可避。
４　規模縮小に伴うログの保全等については、その打ち合わせで決まるはず。
５　その後Big-Serverが、50Mbps程度でサポートし続けるかどうかは不明。
６　今後２ｃｈがどうしていくのかも不明。

今後の２ｃｈについてだけど・・・・
収入の確保、有料化、部分有料化、規模縮小して継続、構造改革（Ｐ２Ｐ化とかNG化とか）、廃止など含めて色々なオプションが一応俎上に上がってるらしいですけど
果たしてどうなるのかはまだ予断を許さないって感じです(^_^;)

がんばってください！226氏、225氏、他諸氏。
434 ：266 ：2001/08/26(日) 01:47: >>433
来週って月曜とか？突貫工事だ(藁
435 ：名無し ：2001/08/26(日) 01:48: ぜんぜん時間無いね。だめかも。
436 ：266 ：2001/08/26(日) 01:49: スレ改竄についてですが
鯖上にチェックサムを残しておいてもらう
っていうのも手かもしれませんね。
鯖のスレと照合すれば手元のスレが改竄されたかどうか
すぐバレちゃうけど誰もあんまりやらないでしょうから。
それなら鯖上にチェックサムもどきを置いといて
そのレベルでチェックをする、と。
あんまり必要だとも思えないけれど・・・。
437 ：266 ：2001/08/26(日) 01:52: えっと、今の話題はデータ改竄ということでいいですか？
それと、クライアント上で似非串として動くのか
HTTPd として動くのかについても検討をお願いします。

俺は HTTPd の方を推します。
ブラウザに対しては HTTPd として振る舞い
裏では 2ch.net に対する HTTP クライアントおよび
他のピアに対する P2P サーバントとして振舞う、
ということで結構楽ができるかと。
HTTPd とは言ってもローカル上でのデータ転送だから
リクエストの URL 部分だけ見てデータを渡せば十分だろうし。
438 ：名無し ：2001/08/26(日) 01:52: >>436
チェックサムなら合わせられるね、強引に。
もちろんCRCを使えばいい話だが。
CRCだけ見に行く？どうだろ。
439 ：225 ：2001/08/26(日) 01:53: ＞432
要は、目指しているのは、たとえばcache.2ch.net でアクセスしたら、
登録されてるp2p参加者のキャッシュ鯖にランダムで飛ぶ
みたいな事かな？
440 ：デフォルトの名無しさん ：2001/08/26(日) 01:54: >>266
407を読んで思ったのですが、読むときの流れは分かるのですが
書き込む時のデータはクライントからどのように流れるんですか？
441 ：デフォルトの名無しさん ：2001/08/26(日) 01:55: 1. クライアントにDelegateをいれてproxyサーバを立てる。
2. Delegateは2chの内容をキャッシュ。
3. IPを2chのトップに表示。
4. みんなはそのIPにアクセスする
というのじゃダメ？
3.が一番のネックになる気がするが...
442 ：266 ：2001/08/26(日) 01:55: >>439
うーん、その捉え方はずれてると思います。
1)www.2ch.net へのアクセスを検出するローカル串である。
　　※串的な機能を持ったローカルの HTTPd というのも考えてます。
2)キャッシュ鯖ではなくキャッシュサーバントにアクセスする。
3)キャッシュはスレやレス単位で行う。
という話です。
443 ：うーん ：2001/08/26(日) 01:55: 改竄対策なら署名付けるようにしたら？
分散されてそこらじゅうで違うデータが流れるのもあれでしょ。
444 ：266 ：2001/08/26(日) 01:57: >>440
書き込む時は 2ch.net の鯖へ直でアクセスします。
目的が 2ch の転送量負荷の軽減なんで
ROM が作りだしてる大量のデータの流れをキャッシュで押さえ込もう、
という話です。
445 ：名無し ：2001/08/26(日) 01:57: >>440
書き込みは普通にやるそうだ。
今問題なのは読み込みに発生するトラフィックだそうだ。
446 ：440 ：2001/08/26(日) 01:58: なるほど、まとめにそれも付け加えておいてもらえると
分かりやすいです＜2ch.netへ直接
447 ：266じゃないけど ：2001/08/26(日) 01:58: >>440
直接2ch.netに書き込まれる。
448 ：266 ：2001/08/26(日) 01:58: >>443
こういう風に考えてるんですが穴あります？

>>425
> 改竄や悪意ある攻撃の類はあまり気にしない方がいいかと。
> 作るのは結局のところただのキャッシュだから
> 今現在の２chで行われているものと被害に大差はないでしょう。
> データ改竄は２chに直アクセスすればすぐにばれるし
> ブラクラにしてもHTMLを生でやりとりせずに
> レスやスレのデータだけをやりとりすれば大丈夫。
> というわけであまり心配してないんですがどうでしょう？
449 ：266 ：2001/08/26(日) 01:59: >>446
了解です。
改竄まわりの話が一旦落ちついたところでまとめようと思います。
450 ：266 ：2001/08/26(日) 02:01: あんまりツッコミがないんで結構戸惑ってるんすが(藁
これは「実装する奴が決めれ」っていうことでいいんですかね？
俺、書きますよ(藁
451 ：うーん ：2001/08/26(日) 02:02: チェックサムするならならせめてＣＲＣか、出来ればMD５ぐらいにしようよ。
452 ：375 ：2001/08/26(日) 02:03: 僕が理解してる範囲でまとめると

１．キャッシュの動作

キャッシュ起動
↓
2ch.net にアクセスして自分の担当するグループを登録
↓
特定のportをlisten して待機

portにクライアントからアクセス
↓
返事を返す(いやなら無視してTimeOut)
↓

[A.board-IDを受け取った場合]
↓
2ch.net に接続して最新スレID一覧を取得
↓
各スレについてタイムスタンプ問い合わせ
↓
ログ一覧を生成
↓
クライアントに返信
↓
Socket close

[B.スレIDを受け取った場合]
クライアントから欲しいスレのIDをもらう
↓
IDから2ch.net 上のタイムスタンプを取得し、更新されてれば
差分を転送
↓
クライアントにスレの内容を返信(独自形式）
↓
Socket close

ここでいったんきります
453 ：名無し ：2001/08/26(日) 02:05: 2chがやばいっていうこの時にも、Unix版で
荒らしてる奴がいることを考えるとクラッカー対策はかなり重要。
このツールで一本化されたとしたら、
クラッキングは2chの死を意味すると思う。
454 ：375 ：2001/08/26(日) 02:05: ２．ローカル上のhttpdの動作

起動
↓
2ch.netにアクセス
↓
すべてのピアグループについて(*1)cacheのIPを取得
↓
port:80をlisten(localhost のみAccept)して待機

port:80 にlocalhostからアクセス
↓
リクエストされたURLを解析し、board名とスレIDを得る
↓

[A.スレ一覧(いわゆるindex2.html）をみる]
board名から適切なcacheに接続
↓
cacheにboard-IDをリクエスト
↓
cacheから最新スレ一覧（独自形式）を取得
↓
html生成
↓
localhostに返信してSocket Close

[B.特定のスレをみる]
board名から適切なcacheに接続
↓
cacheにスレIDをリクエスト
↓
cacheからレス一覧（独自形式）を取得
↓
html生成
↓
localhostに返信してSocket Close
455 ：225 ：2001/08/26(日) 02:05: ＞442
ふむ、それの方が効率はいいんだろうけど
一部の人だけがやったところで意味ないから、かちゅ～しゃ程度の普及率を目指すということかな？
というか、バンドルしてもらうのが手っとり早そうだな。
456 ：266 ：2001/08/26(日) 02:06: >>451
まあなんでもいいんすけどね。
鯖に負荷が掛からないものをと思って
とりあえずチェックサムと言ったまです。
それと、そもそもあんまり改竄が問題とは思えないんです。
理由は >>448 の通りです。
ちゃんとフィルタリングすれば
できるのは嘘のレスやスレが出回るってだけのことですよね。
しかも２chに直アクセスですぐにそれはバレてしまう。
それを防ぐためだけにあれこれ実装するのって
あんまり意味があると思えないんですがどうでしょう？
457 ：375 ：2001/08/26(日) 02:08: ３．2ch.net の動作

キャッシュから登録のリクエスト
↓
希望するピアグループの一覧にIPを追加
↓
Socket Close

キャッシュからタイムスタンプのリクエスト
↓
タイムスタンプ返す
↓
Socket Close

キャッシュから登録解除のリクエスト
↓
解除
↓
Socket Close

キャッシュから最新スレ一覧のリクエスト
↓
返す（IDだけ）
↓
終了
458 ：375 ：2001/08/26(日) 02:09: って言う風に理解してるんですけどどうでしょう？
459 ：266 ：2001/08/26(日) 02:09: まとレススマソ。

>>455
かちゅ～しゃほどになるかどうかはともかくも
数をばらまかなくちゃいけないのは確かですね。
鯖側も多少いじらなくちゃいけないんで
2ch 管理側との連携も必要です。

>>452 >>454
そういう感じです。
460 ：266 ：2001/08/26(日) 02:11: >>457
ピア一覧への登録と解除については
俺はプロトコルは要らないんじゃないかと思ってます。
ある板にアクセスしたら、
時限付きでリストに加えるようなCGIを鯖側に用意するんです。
これならプロトコルもクライアント側での特定の処理も要りません。
それ以外はご推察の通りです。
461 ：375 ：2001/08/26(日) 02:15: >>460

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

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

確かにこの方がエレガントですね。
462 ：266 ：2001/08/26(日) 02:16: >>461

> 「ある板にアクセスしたら」
> っていうのは「キャッシュが」ってことですよね？

はい、そういうことです。
463 ：デフォルトの名無しさん ：2001/08/26(日) 02:16: >>456
改竄されてるかどうかを確かめるぐらいなら
最初から直アクセスするYO!ってならないかな？
464 ：225 ：2001/08/26(日) 02:18: ＞456
とりあえず、信用出来ない鯖の検出が出来れば問題ないんだよね。
オリジナルへのアクセスはできるだけ避けたいから、どうすべきかと。

２ｃｈ側で登録してもらって、たまに見回りをしてもらうってのもありかな？
465 ：266 ：2001/08/26(日) 02:21: >>463
それもあると思います。
ただ、全体としては、悪意を持つ奴やその影響は
正常な動作に比べてごく小さい範囲に収まるんじゃないかな、と。
少なくとも架空レスや架空スレ以外の問題はないはずです。
で、架空のものにしても直アクセスで確かめるのと
鯖上のチェックサムと照合してみるのとの組み合わせで
その割合はいくらでも小さくできて、
いずれは２chの鯖をクラッキングされる確率と変わらなくなるんじゃないでしょうか？
そうなると杞憂でしかありませんよね。
466 ：266 ：2001/08/26(日) 02:23: >>464
うーん。
まず、問題は架空レスや架空スレということでいいですよね？
で、その架空の発言でどんな被害が出るかというと、
せいぜい誰かがだまされるかだまされないかぐらいの話で
それは現状の２chとなんら変わるものではない。
荒らしにしたって現状の２chに既にそれはある。
ヤバい情報が流れるとしてもそれは
全部キャッシュ上の話で２chに管理責任はないだろうし
それに２ch上にコピペされたなら従来どおりに対処すればいい。
そんなこんなで被害と呼べるほどの被害が思い当たらないんです。
どっか抜けてますか？
467 ：名無し ：2001/08/26(日) 02:26: >>465 嘘レスをもらったピアがキャッシュとして動作したは？
468 ：デフォルトの名無しさん ：2001/08/26(日) 02:29: >>465
改竄を見抜けないままレスがつくとスレが破綻する
可能性もあるんじゃないでしょうか。
まぁこの問題は開発の本筋とはあまり関係ないから
後回しでもいいかもしれませんが…
469 ：266 ：2001/08/26(日) 02:30: >>467
もちろん増幅されます。
だけど、それで生じる被害は >>466 の範囲に収まると思います。
キャッシュにはタイムアウトを設定してもいいでしょう。
そうなると、悪意のある誰かが嘘レスを大量にばらまくような
サーバントを作った場合が問題になるかと思います。
これには対処しなくちゃいけませんね。
470 ：225 ：2001/08/26(日) 02:31: ＞466
いや、問題ないと思う、
要は、話がかみ合わなくて笑い物にされる恐れがあるってだけだからね。
471 ：デフォルトの名無しさん ：2001/08/26(日) 02:31: レスをつけるときは直にやるんだからちょっととんちんかんな会話になるだけっしょ。
セキュリティはとりあえず動くものつくってからでいいと思うなぁ。
472 ：うーん ：2001/08/26(日) 02:34: 出力されたデータが改竄されていることがリアルタイムに判明する仕組みは必要だと思うよ。
データに関しての責任を誰も負えなくなってしまう。それこそ無法地帯になりかねないよ。
あと削除があった場合の同期方法を考える必要があると思う。

それから、直アクセスは通常出来ない、もしくはかなり制限されるようにしないと
結局殆どの人が直アクセスになってしまうと思うな。
473 ：266 ：2001/08/26(日) 02:36: 一個解決案を考えてみました。
鯖上にスレの要約ファイルを作るんです。
で、この要約中にはスレを構成するレスのサイズとハッシュか何かが並んでいる。
スレを読む時には必ずこの要約ファイルを鯖まで取りに行ってから
キャッシュにアクセスします。
これなら架空スレは作れませんし架空レスについても
せいぜい発言が差し替えられるだけで数が増えたり減ったりはしません。
鯖へのアクセスやCGIの負荷は増えますが
前者はスレの直接読み出しとは比較にならないでしょうし
後者もCPUの消費ですから問題ないでしょう。
どうですか？
474 ：ＵＮＩＸ板の状態 ：2001/08/26(日) 02:39: 2ch閉鎖の危機なんだと（Part2.1）

http://cocoa.2ch.net/test/read.cgi?bbs=unix&key=998754174

素人には何のことだかわかりませんが、
メッセンジャーくらいなら出来ます。
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 に置き換えさせないと示すレスの範囲が
変わってしまいますよね.

330KB

新着レスの表示

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

0ch BBS 2004-10-30