---

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

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

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屋なので
アプローチがとりづらい部分があるので自前で必要な分を作ってる幹事巣。
簡単に改造で済むクラスタのソフトがあれば手がつくかもなのですが。

599 ：デフォルトの名無しさん ：01/08/27 01:15 ID:C1BnNgDo

>>593
スレッドをサーバー側から割り当てるより、
スレッドを取得したクライアント（複数）を記録しておいて、
それをキャッシュとするというのはどうでしょうか？

これなら負荷の大きい人気のあるスレッドに対して、
より多くのキャッシュを割けると思います。

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

/*============================================================================*
　P2Pの概要
*============================================================================*/

　　　　-------------------------------------------------------
　　　　｜　　　　　　　www.2ch.net　(P2P Master)　　　　　　｜
　　　　-------------------------------------------------------
　　　　　　↑　　　｜　　　　　　　　　　　　　　↑※３マスタ要求取得
　　HTTP 　 ｜　　　｜HTTP(一覧(board, thread,　　｜※４キャッシュサーバ登録
(GET/POST)　｜　　　↓ 　cache_ip_port)を入手)　　↓
　　　　-------------------------------------------------------
　　　　｜　　　　　　　　　　P2Pcache 　　　　　　　　　　　｜
　　　　-------------------------------------------------------
　　※１　　↑　　　｜　　　　　　　　　　　　　　↑
　　HTTP 　 ｜　　　｜HTTP　　　　　　　　　　　　｜※２独自の
(GET/POST)　｜　　　↓　　　　　　　　　　　　　　↓キャッシュやり取り
　　　　　----------------　　　　　　　　　----------------
　　　　　｜　ブラウザ　｜　　　　　　　　　｜　P2Pcache　｜
　　　　　----------------　　　　　　　　　----------------

※１：通常のHTTP要求時はHTTP Proxyもしくは
　　　2ch専用のHTTP Daemonとして、P2Pcacheは動作する。
　　　2chの場合にはCGIなどからHTTPにて一覧を入手し、
　　　キャッシュ内容をブラウザに伝える。
　　　キャッシュ単位はスレ単位、レス単位である。
　　　また、この時に新規スレの追加などの情報も取得する(If-Modified-since？)。
　　　鯖側はピアグループを決定し、一覧を送る。
　　　2chへの書きこみはデータの統一/即時反映のため、
　　　P2Pcacheは単に素通りさせ鯖に直接行う。
※２：P2Pcacheは、自分がキャッシュを持たない部分については、
　　　2chから送られてきた一覧を用い、他のキャッシュに検索にいく。
※３：一定時間内に発見できなかった場合には、マスタ(2ch)を入手し、
　　　自分のところにキャッシュし、ブラウザに伝える。
　　　但し、2ch内で常時P2P Masterを立ち上げるのは良くない？ので
　　　HTTPでやりとり？
※４：P2Pcacheは初めて自分が使用された際にマスタに登録する。
　　　有効時間を過ぎると、マスタは自動的に登録を抹消する。

http://www.gedoh.org/aki/2ch/wiki/yukiwiki.cgi?mycmd=read&mypage=%5B%5Bread%2Ecgi%82%CC%8Ed%97l2%5D%5D

601 ：375 ◆MsUYMX0E ：01/08/27 01:17 ID:k3MsBTsc

>>599

うーん。要はピアグループとかそういう大きい単位でなくて
スレッド単位で割り振るってことですよね..

僕としてはピアグループ、最低でも板単位のほうがいいと思うのですが
（1板１ピアグループとかにして）

トップ１０スレとか表示するのはできるだけ1つのP2Pcacheにやらせたいです。

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

>>601
きっとそれはできてからテストしないと決められないかも(^^;
経路が離れ過ぎると重くなるかも(ピアＧの方が近いIPを選択できる)、
というのと、キャッシュヒット率はスレ単位の方がいいかもという
選択肢だと思いますし。

603 ：デフォルトの名無しさん ：01/08/27 01:22 ID:wHbpdJPw

完全P2P化でもある程度の2ch.net依存型でも、削除人が居ないってのは怖いよ
上で出てる｢ID＋証明書付きの削除依頼｣ってのが出た場合は一発削除、って仕組みはなんとか実装出来ませんかね？
｢こりゃ個人情報だわ｣って言って善意で証明書出せる人は居ても、
｢このレスむかつく｣ってだけで証明書晒す荒らしはそんなに居ないんじゃないのかな

604 ：266 ：01/08/27 01:24 ID:TRv86eRI

ただいま実装真っ最中です(藁

>>591
若干行き違いがあるような気がします。
こちらで考えているのはサーバント間でのログパッシングがメインです。
えーと、結果論から言えば、ログはサーバント間の通信で増殖していきます。
2ch.net へのアクセスは

1)ピアアドレスの一覧取得
2)レスのやスレの要約一覧取得
3)キャッシュになかったレスの取得

の３パターンにおいてのみ発生します。

では再び実装作業で沈みます・・・。

605 ：375 ◆MsUYMX0E ：01/08/27 01:25 ID:k3MsBTsc

>>603

現行の方式でも削除があるとハッシュが食い違うので、(正当な）クライアントは
2ch.net にレスを再取得しにいきます。

>489 前後を参照してください

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

>>604
細かいところはまだ気にしなくていいじゃん。(^^;;
とりあえずがんばってくれ。それっぽいのがあれば
みんな手伝えるし直すっしょ。

607 ：デフォルトの名無しさん ：01/08/27 01:35 ID:YfpO6h5c

2chキャッシュサーバならこういうのもあるよ
http://www.geocities.co.jp/SiliconValley-Cupertino/5226/j2ch-cache/index.html

キャッシュサーバ間で連携が取れれば >>600 に近いイメージかもね

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

>>607
これはいいんじゃん。
現状でもみんなこれ使えばそれなりに効果あるんでない？
特に常駐者。発想的にはかなりビンゴのはず。

609 ： ：01/08/27 01:50 ID:.A.boK1.

>>608

なんかこれを普及させることが出来れば相当部分解決だね。

610 ：266 ：01/08/27 01:52 ID:TRv86eRI

ひょっとして俺が作るのって無駄？(藁

611 ：593 ：01/08/27 01:55 ID:gI46IMVY

>>596
ここのスレッドの題名みて「これかな？」と思って書いてから、
一通りここを斜めよみして書きなおしてみたのがアレです　すんまそん。
みてて思った疑問点は、以下の通りです。
完全分散DBとして構築すればいいのかな、というのが所感でした。

・NNTPだと全部のスレのtemporary-logをコピーしまくるので
　1マシンあたりの負荷と役割が重いし、デッドコピーが出る
　→グヌテラ型がいいかも

・完全にグヌテラ型にした場合、インデックスをどう取り扱うかが問題
　→ディレクトリの概念を2chサーバに持たせたらどうだろう？

・NNTPでよくある「スレッドおち」「発言おち」はどう対抗すればいいのだろう？
　→分散DBと考えて、スレッド＝テーブルとみなす。

・1スレッド1Peerだと、その人のマシンを動作させている時間によって
　見られる時間が決まってくる
　→複数マシンで持ち合いすればいいかな？
　　レプリケーションの考えかたを導入して、
　　複数のディレクトリエントリが1つのスレッドを受け持てばラクかな？

・シームレスな運用をめざそうとすると、情報の生存時間の管理が必要
　→基本的にはレプリケーションの組みの中で相互監視して、
　　ヤバくなったらディレクトリを書き換えちまえば（＝使用不可に書き換え）いいか？

612 ：593 ：01/08/27 02:01 ID:gI46IMVY

>>603
「オレだ！！」というのを証明書で表わす、ということですよね？
削除TPSはそんなに高くないから、証明書の問い合わせをPeerが行ったとしても
性能は大丈夫だと思いました。

あと、「オレがやっちゃいましたぁ」という表明は不要？
つまり、、、
・Peerには「オレだ！削除ヤラせろ！！」
・Peerは証明書の真偽を問い合わせてから「あん？・・・ああ、どうぞ」
　→これはその人がその人である問い合わせ　削除人の削除動機については不問
なので、「削除人の削除動機の表明」という手順はいらないのかな、と

・・・あ、でも今でもそういう手順はない？？（＾＾；

613 ：375 ◆MsUYMX0E ：01/08/27 02:07 ID:k3MsBTsc

>>610

いや、あれは >364 あたりで分離した(まだスレたってないけど）
cacheサーバを有志で準備　っていうアイディアだと思いますよ

　

614 ：593 ：01/08/27 02:12 ID:gI46IMVY

連続してすいません。
あと思ったことは、
「スレッドデータの管理」をアプリケーション層
「スレッドデータの位置情報の管理」をプレゼンテーション層
と、完全に分離して考えてしまうのはいけませんか？

何言ってるの？というと、
スレッドデータの位置情報をグヌテラぽいものが各々管理するなんて
めんどくさいじゃないですか。
要は、
「表示は表示管理インスタンスの仕事」
「データの管理はデータインスタンスの仕事」
「表示インスタンスは、データインスタンスに問い合わせて表示」
でもよいのかなと。
位置情報程度のデータの通信はそれほど苦でもないでしょう。

具体的に書くと、分散DBなんかでも問題になる、ディクショナリのようなものを一切もたず、
表示インスタンスに「オレを表示してくれ！！こういうスレだ！！」ってpushさせて、
表示インスタンスはそのとき得た情報を一過性のディレクトリエントリと思って表示する。
表示そのものはデータインスタンスにまかせて、表示インスタンスは指示のみ。

あとは、表示インスタンスを固定の場所におくか、
Windowsのマスタブラウザみたいに乱数で決めるかだけを考えれば、
それでいいのかなと。

ここで必要なのは、位置情報を、
確実な相手から確実に取得できる手順が必要なのではないでしょうか。
（ニセスレッド発生防止策のこと　データインスタンスに証明書でももってこさせる？）
データ処理そのものはPeerまかせ（データは暗号化必要かな）でもいいかと。

で、プレゼンテーション層の位置はある程度固定化しておかないと
パンピーからアクセスできないことでしょう。

615 ：603 ：01/08/27 02:21 ID:wHbpdJPw

>>605
489前後を読みましたが、、その仕様だと参加者は全員削除権を持っていて、
一旦削除すれば各ピアが鯖に同期を取りに言ったときキャッシュが更新されてあぼーんかと思っちゃったんですが。。
全員が削除権を持つ2chってありですかね？ ハズしてたらスマソ。

616 ：375 ◆MsUYMX0E ：01/08/27 02:25 ID:k3MsBTsc

>615

えっと、2ch.net 側については基本的にはCGIの追加以外なにも
しないです。削除についても今までどおり、削除人にお任せです。
参加者にももちろん削除権はありません。

　あの仕様が意図してるのは、2ch.net ではすでにアボーンされてるのに
cache上には残っているがためにクライアントでは表示されてしまうことを
防ぐことです。

617 ：603 ：01/08/27 02:44 ID:wHbpdJPw

>>616
なるほど。削除人ありのフェーズ1ということですね。

>>612
動機は不問でも良いと思います。証明書まで晒して削除するほどならばそれなりの理由をもって削除したとみなす。
ただ、｢このスレッドはこいつが削除しました｣的なリストはどこかに表示すべきでしょう。

でも個人証明書って全然普及してないですよね。俺も持ってない。
verisignでは3千円チョイで取れるみたいですけど。

618 ：デフォルトの名無しさん ：01/08/27 02:51 ID:w6pQSl86

ふと思ったんだけど自分がどのドメインをキャッシュするか
積極的に宣言するプロキシサーバーという奴ではダメなんかな

サーバは自分が積極的にキャッシュするドメインを宣言して
クライアントは自分がキャッシュを使いたいドメインを指定してそのリスト
をP2Pで取得、そして積極的にキャッシュしているサーバのどれかにとりにゆく

これなら普通のプロキシが使えると思うし
2ch以外にも応用が利くと思うのだけど。

619 ：375 ◆MsUYMX0E ：01/08/27 02:58 ID:k3MsBTsc

>618
たぶんそれが
>364 とかでいってる
1)キャッシュサーバ＋index2.cgi
だとおもうのだ。で、それも重要な選択肢だと思うので
ぜひ別スレを立ててくれると助かるのだ。

あと >593 さんのアイデアもゆっくり議論したいので
十分スレ立てるのに値すると思うのだ。
(たぶんここでやるといまやってるP2Pcacheの話と混乱を
きたす気がするのだ）


で、僕は寝るのだ。

620 ：デフォルトの名無しさん ：01/08/27 03:29 ID:2ORdPnOg

>>610
ええや。無駄じゃないってば。
あれだけだと機能たんないから。
ただ、ベースにしたら良かったかもというのはあるが、
PG板なんだから自前でつくるのも融通がきいていいでしょう。:-)
それに、textブラウザでは使えんし。

621 ：デフォルトの名無しさん ：01/08/27 03:43 ID:2ORdPnOg

>>618
■NNTPの利用
・掲示版の良い点のリアルタイム制を保てない
・削除コントロールが簡単に偽装できてしまう
・多少スペックが必要

■キャッシュサーバ
・個人のスペックではきつい
・細かいキャッシングで上手く威力を発揮するか不透明

という議論があったんだが、Proxyってだいじょうび?
スレ単位のキャッシングだとヒット率少なそうで、
レス単位のキャッシングが必要だと思っているんだが。

622 ：デフォルトの名無しさん ：01/08/27 03:49 ID:2ORdPnOg

>>612
削除人以外の削除権を皆がもつ方がいい?
俺的には削除のDoSが成立しそうで怖いんだが。
IPなんぞWinGateのTelnet ProxyとかHTTP Proxyとか
使って経由すれば簡単に隠蔽できちゃうし、
ネットカフェでも隠しにはなるからあまり信じていない。

623 ：225 ：01/08/27 04:03 ID:EG4ish0Q

取りあえず、昨日からの話はハイブリッド型P2Pを前提にして、できるだけ小さなコアでも問題ない
（つまり、2chの転送量を個人でまかなえるレべルまでく減らして、たとえ２ｃｈが無くなっても、だれかが代わりを設置できる）
ようなものにするためのものだと考えてます。

というわけで、かちゅーしゃとかでも、サーバやproxyとして設定すればP2Pの恩恵にあずかれるようなものがいいです。
ついでにlogもキャッシュとして流用出来ればいいと思うんですけどね。

>>611
で、それも取っ払って、完全P2Pってことなら、私は上で言ってますけど、トップ（始めた人）が見守ってラスト（今の人）が責任を負うという
方式がいいんじゃないかなって思ってます。

インデックス（板ノード）については、基本的には人のをもらってくるって感じでしょうか？。
まあ、順位を取得しなくても、フロート処理なんて板内にリンクされたスレをsageを除いて新着順にすれば済む話です。

ただ個人的には別に２ｃｈの欠点（板の硬直性）までコピーすることはないと思うので
オリジナルとは別に、共有している個々が使いやすいようにその責任で再編成するのもアリだと思ってます。
まあそれは２ｃｈではないのかもしれませんが（ス連的？）
基本的には、キーワードプールって感じで捉えています。
要は、自分の板に必要でないスレはごみ箱送り、容量が余ってるうちは置いとくから勝手に持ってってって話ですけど。

>>195みたいなのは駄目ですかね？
>とりあえすスレ立てる時、何かカテゴリかなんかのキーワードを指定すると言うのはどうだろうか？
>逆に言うと各ノードは、取り扱う内容によって詳細なキーワード（板の名前を含む）を持っていて、
>そこに立てると自動的にその属性が付く
>で他のノードのスレで、受け入れ可能なスレがあったら、自動的にノードにリンクさせる

具体的に考えたのは、まずスレを立てる時にジャンルなりキーワードをいくつか指定する。（なければ板のデフォ値とタイトル等）
板ノードは自動的に自分の持ちスレに付いてるキーワードを適当に使って他のスレを検索する。
勿論、キーワードや足切り値などは管理者が指定。
つまり自分の板にふさわしそうなスレを見つけて、自動的に加えられる機能をつけられないかと。

問題はスパム対策ですけど。

624 ： ：01/08/27 04:32 ID:.A.boK1.

>ただ個人的には別に２ｃｈの欠点（板の硬直性）までコピーすることはないと思うので
>オリジナルとは別に、共有している個々が使いやすいようにその責任で再編成するのもアリだと思ってます。
>まあそれは２ｃｈではないのかもしれませんが（ス連的？）

同感。２ｃｈだって常に変わっている。別に現在の2chにこだわる必要は
まったくなし。

625 ：266 ：01/08/27 04:41 ID:TRv86eRI

さすがにきついんで今日はここで作業終了。
テストコード真面目に書いてたら手間が掛かるなぁ。
とりあえず今日はこれで寝ます。おやすみなさい。

626 ：デフォルトの名無しさん ：01/08/27 05:11 ID:L3faF4dI

2chでは一日に数個のレスしかつかないレスが多数ある（というかほとんどでしょう）。
P2Pでそういうのスレッドを常時共有するなら、結局サーバがいる。
現状では、要するにチャットシステムにしかならない。

627 ：1 ：01/08/27 05:25 ID:UQn5rfWU

ちょっと思ったんだけど、超短期的にrsyncで同期取れないか？

628 ： ：01/08/27 05:33 ID:.A.boK1.

>>626
>P2Pでそういうのスレッドを常時共有するなら、結局サーバがいる。
>現状では、要するにチャットシステムにしかならない。

じゃぁチャットで。チャットのログが各サーバントのHDDに残ってる。

629 ：デフォルトの名無しさん ：01/08/27 06:26 ID:MBKxONM2

>>628
そのようなシステムだと、２ｃｈでいうレス数が一日に数個のスレでは、
自分がオンライン時に、スレを注目している他の人は、オンラインしていない場合が普通。
スレを注目している他の人がオンラインしていなければ、自分が前回回線を切ってから、
今回オンラインする間に付いたレスは見れない。

結局２ｃｈの変わりには全然ならない。タダのチャットシステムにしかならない。

630 ：aki ：01/08/27 06:27 ID:Z/nLX8Y2

通信技術板でこの手の話しがでてました。参考まで。

転送量増加で2ch閉鎖の危機だってよ。
http://mentai.2ch.net/test/read.cgi?bbs=network&key=998697428

631 ：デフォルトの名無しさん ：01/08/27 06:48 ID:CSUZ8fsE

>>629
cache をかけたい場合は集約しないとシクシクになるので、
P2P では向かないというのは事実でしょうね。結局 netnews
のように、ある程度集約された server に access しに行く
形状が効率的とかってなっちゃうのかなぁ…。

632 ：デフォルトの名無しさん ：01/08/27 08:31 ID:DS3JKGwc

なるほど

633 ：225 ：01/08/27 08:56 ID:EG4ish0Q

>>629
結局、誰もが無責任だからそういうことになるのですよね。
誰も注目してないスレは沈んでゆく。
もともとスレッドフロートの目的っていうのは主にそういう所にあると思いますけどね。

まあ、スレッドが読めなくなるのを防ぐのは、誰かが責任もって、どこかにログを避難することだと思います。
大体、責任者がいなければ、レスの番号が決まらないんじゃないでしょうか？

とりあえず、常時２か３つ以上のサーバンドがログを持つようにすることを義務にすれば、全滅しない限り
ネットのどこかに最新のログが存在すると思います。

自分だけしかログを持ってないことに気づいたら、誰かに預けられる仕組みが必要ですね。
まあ、悪用されないように気をつけなければいけませんけど。

634 ：デフォルトの名無しさん ：01/08/27 11:19 ID:WKweRLHc

このスレ立った直後からちょくちょく来てたけどたった3日で物凄いレス・・・
早期実現化きぼーん

330KB

---

新着レスの表示

---

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

0ch BBS 2004-10-30