---

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

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

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日で物凄いレス・・・
早期実現化きぼーん

635 ： ：01/08/27 12:02 ID:Uofeyeso

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

ある程度の冗長性を持たせ、ユーザーには参加費用として、注目していないスレッドのログ
も保存する義務を負ってもらう。「ある程度」をどのように計算する？ うーむ思い浮かばない。

636 ：デフォルトの名無しさん ：01/08/27 12:29 ID:vOjMDCDU

話のメインにはなっていないけれども、ユーザーの削除について。
削除荒しみたいなのが恐いので（プログラム関係では発生しないだろうが、
創価板、ハングル板、政治思想板のように特定集団がいる可能性が
高いところで起こると考えられる）削除賛成のマイナスだけでなく、削除反対の
プラスも入れられるようにしてほしいっす。

メインの流れと外れているので下げます。

637 ：デフォルトの名無しさん ：01/08/27 12:35 ID:8q2NINpg

すべてのマスターログは2ch.net上にあるんだから、
その時のオンラインユーザの誰もそのログを持っていなくても問題ないんじゃないの？

638 ：デフォルトの名無しさん ：01/08/27 13:59 ID:qgAoJInU

かちゅーしゃと違って一般のユーザーに利点が見えないのが痛いな。
おそらく普及しない。
やっぱりかちゅーしゃの作者連れてきて対応させるしか。

639 ：　 ：01/08/27 15:05 ID:Zo3BlCCA

いろいろ回ってみた。なんか2chの存続は、結局このスレのあんたらに
かかってるような気がする。がんばってくれ。

640 ：375 ◆MsUYMX0E ：01/08/27 15:21 ID:4k5SK/AU

>>638

ずばり思ってたことを言ってくださってちょっとうれしいです (^^;;

たしかにみため直接的なメリットないんですよね〜
レスポンスは悪くなるわけだし

最悪2ch.netにIE とかネスケからつなぐのを禁止　とかしないと
（↑極論ですけど）
ほんと2ch.net の処理能力の高さが恨めしいです

641 ：266 ：01/08/27 15:31 ID:TRv86eRI

なんかおまけ付けたらよいのでわ。
WinMXとかやるとまずいけどIM的な実装を入れて
スレ見てるユーザー同士でチャットなんてのは可愛いと思われ。

642 ：デフォルトの名無しさん ：01/08/27 15:49 ID:7DytoZz2

ちょい考えました。既出ならすまそん。
P2P とまで大仰ではないですが、
もっとも現在のシステムに近く、もっとも負荷低減を図れるのではと。

・まず、2chサーバに置くCGIはHTMLを吐かない。
その代わり、XML-RPC(か SOAP)でリクエストに答える。
スレ番号、発言番号の範囲を引数に指定するとかか。

・かちゅーしゃとかの専用ブラウザはXML-RPCで直接しゃべる。

・普通のブラウザユーザのためには、HTML ゲートウェイを用意する。
もちろん2ch以外のサーバに適当に置いてもらう。

どうでそ。

643 ：375 ◆MsUYMX0E ：01/08/27 15:49 ID:k3MsBTsc

>641
あ、２６６さんお疲れ様です。

チャットですか.. いいかも。ピアレベルで実装できますしね。
ピア間のチャットメッセージの中継はどうしましょう？
>540 みたいなメッセージを新しく追加して対処できるかな？

そもそも中継まで必要ないかも？

644 ：375 ◆MsUYMX0E ：01/08/27 15:51 ID:k3MsBTsc

>642

XMLってHTMLにくらべてそんなにサイズ減るんですか？
技術的には面白いと思うんですが。

645 ：642 ：01/08/27 15:56 ID:7DytoZz2

>>644

書式情報は取り除けるので、最低でもその分減るかなと。
(文中リンクはよくわからん)

主目的じゃないですけど、専用ブラウザでの HTML のパースが不必要になって、
楽になるのでは、とも思います。

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

ログをＪＳファイルにする。
ＪＳファイルの外部読みこみ形式を利用しＨＴＭＬ内に読みこむ。
ＨＴＭＬファイル内で２ｃｈ風に処理し表示。
これで、サーバーを軽減？
駄スレスマソ。

647 ：266 ：01/08/27 16:05 ID:TRv86eRI

>>643
チャットに高いデータ整合性を要求する必要はないと思いますんで
タイムアウト設定したパケットを板ユーザー相手にばらまけば
SearchMessageの亜種として扱えると思います。
もちろんタイムラグとか不達とかが発生しますけど
チャットならまあ問題ないんじゃないかと。

648 ：375 ◆MsUYMX0E ：01/08/27 16:06 ID:k3MsBTsc

>646

JS って JavaScript ?厨房でスマソ

もしかしたらそういう話は
http://natto.2ch.net/test/read.cgi?bbs=hp&key=998774537
にいる人々のほうが詳しいかも。ちがってたらごめん

649 ：375 ◆MsUYMX0E ：01/08/27 16:08 ID:k3MsBTsc

＞２６６

ところで２６６さん、実装のほうはどんな感じですか？

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

>>648
そうです。＞JS って JavaScript・・・
JavaScriptはWeb板のほうがよさそうですね。
逝ってきます

651 ：デフォルトの名無しさん ：01/08/27 16:11 ID:GRBfg3.A

掲示板モードとチャット(実況)モードで分けられたらいいかも

652 ：266 ：01/08/27 16:18 ID:TRv86eRI

まずは外堀からってことで
メッセージデータとメッセンジャーのデータをカプセル化したクラスと
レスデータのキャッシュに使うテーブルを作ったところです。
中身はC++とSTLで書いてあります。
今はルーティングテーブル用のクラスを書いてるところです。
このあとには次のようなものを作る予定です。

1) 2ch.net にアクセスするためのユーティリティモジュール。
2)セッションを管理するクラス。
3)メッセンジャーの送信・受信を管理するクラス。
4)ブラウザに対して HTTPd もどきとして振る舞うモジュール。

1)はBCB付属のコンポーネントを流用するんでほとんど作業はありません。
2)は状態遷移を管理して3)のクラスとの間でやりとりすればいいだけなんでこれも楽。
3)はソケットに馴れてないので手間かかるかも(藁
4)は文字列処理ですけどまずはあんまり凝ったことはしないようにします。
一応全体の見通しはついてるんで書くばかりの作業です。

330KB

---

新着レスの表示

---

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

0ch BBS 2004-10-30