5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:01/09/02 20:53 ID:71SdL9Z6
part2です。

前スレは
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=990334284&ls=50

その他プロジェクトへのリンクとか、2ちゃんねる開発統合スレッドは
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=998908559&ls=50

103 :266:01/09/16 22:09
>>102
スマソ。リーク箇所こちらで調べてみました。

1)CriticalSection のデストラクタで解放忘れしてました。
 delete (CRITICAL_SECTION*)m_section ; してやってください。

2)ReceivingQueue のデストラクタで
 キュー内の残存 Envelope の後始末も忘れてますね(汗)
 queue の要素を全部 delete してやってください。

3)Class_Backend.cpp の BackendDriver で
 BackendUnit の onArrival をコールした後に
 result.message を delete してやってください。

4)Class_Frontend.cpp の HttpSessionDriver で
 params.socket を処理の最後に delete してやってください。

タコなミス連発して申し訳ないっすm(_ _)m

104 :ファイルアップ隊:01/09/17 00:14
週間作業報告です(藁

>てんてんさん
backendのclass_controlunit.cppのGUIDの部分ですが、

const GUID ControlUnit_ClassID = {
0x689abf243,
~~~~~~~~~~~
9桁なので、0x89abf243,の8桁にしていただけないでしょうか。
unsigned longでも入り切らないとgccに怒られるので...

>all
ようやく普通っぽくなりつつあるのでgcc版をアップしました。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/p2pcache-gcc-linux-20010916-proto2.tgz

バイナリは、物件のp2p-bin配下にありますので、カレントをそこに移動して、
./p2pcacheと実行する動きます。

止め方はkillall p2pcacheとするか、普通にkillして下さい。
SIGTERMをトラップしています。
また、刺さった時には、kill -9したあと、
1) rm *.lck
2) ipcsでsemphoreが残りっぱなしになっていないか確認。
3) 残っていたら、ipcrm sem [semid]にて削除。
です。2と3が良くわからなければリブートでもOKのはず。

Backend Onlyのテストの場合には、./run_backend.shを実行後、
./run_frontend.shを実行し、http://localhost:5080/からみてみて
下さい。あらかじめキャッシュデータ(cache.dat)は添付してあります。
※./p2pcache -CにてキャッシュONして収集してそれを使ってもOKです。

105 :ファイルアップ隊:01/09/17 00:22
---------------------------------------------------------------------------

p2pcache for gcc build : Sep 16 2001 22:08:58

---------------------------------------------------------------------------

Usage:

p2pcache -B(backend_port) -F(frontend_port) -O(optpeerlist{s|l|b})
-C(cache file) -S(start mode{b|else}) -h -v -V

Options:

-B,--backend_port : require port number (default 4444)
-F,--frontend_port : require port number (default 5080)
-O,--optpeerlist : require [s]erver, [l]ocal, [b]oth (default server)
-C,--cache : optional filename (default cache.dat)
-S,--startmode : b = backend only, else both (default both)
-h,-?,--help : no argument (help)
-v,--verbose : no argument (詳細なログ。ログはp2pcache.log)
-V,--version : no argument (version。更新しわすれました。)

普通はあまり使わないと思われるオプション

-M,--maxwait : require number (default -Mf10000 -Mb100 msec単位です)
# -Mfはfrontendの値。-Mbはbackendの値。

-m,--ctrl_max_dup : require number (default 10)
-e,--ctrl_req_dup : require number (default 5)
-o,--ctrl_routing_dup : require number (default 5)

106 :ファイルアップ隊:01/09/17 00:39
ちなみに、-zオプションでコンソールにログが吐かれます(debug用)。
ただし、-z指定時には-vを指定しないでください。変な動きになるかも。
-zなしの通常時は、デーモンのように動きますが、SIGHUPでも
再起動はしません(機能をつけてないです)。

proto1からの変更点は以下です。

・criticalsecionのエミュレーションをflockからsemphoreを用いた排他に変更。
・キャッシュ(ex. -C or -Cmycache.dat)とバックエンドのみ(-Sb)をサポート
・停止方法を多くのデーモンと同じくsignalに決定。
・デーモン化した。
・一部のsignal対応。
・Windows版のソースとのまぜこぜはやめた。
・移植しやすいようにautoconfに対応。automake対応は未(フォルダ構成の関係上)

既知バグは以下です。

・既にポートが使われていて異常でも終了もリトライもしない。
※実行前に、netstat -an | grep tcpをして、4444や5080が未使用なことを
確認するのが吉。
・タイミングによっては、リソース(semphoreや*.lck)が残ってしまう。
・一部のリソースがリークしている。
・ログが一部化けている。

107 :ファイルアップ隊:01/09/17 00:55
>>102,103
なるほど。
そういえばこれってキャッシュ内容を全部メモリに読んでるから、
2chみたいに一つの板で100越えるスレ数なんかでは凄いことにならない?
板orスレ単位などでキャッシュファイル作ったりとかは必要なんでは。

個人的には、以下の所がすごく気になる(藁
//★この処理はやばいかな??

// 板情報の展開
//★処理に強烈に無駄が多いのでどうにかすること。
// 行単位での分割にいちいち文字列コピーさせるのはバカもいいところ。

//★例外発生時のクリティカルセクション解除が必要。

108 :ファイルアップ隊:01/09/17 01:07
>>105,106
あ、それと説明書は入ってないす。266さんのWin版のしか。
燃えつきてしまって... すんまそん。

ちなみにこのスレって、もはや2chの負荷問題というよりも
単にP2Pの世界のような気もする。勉強になるから別にいいんだが...
まぁ、ここまでくれば後は必要なときに誰かが何かしてくれるでしょう.

109 :266:01/09/17 01:48
>>107
ご苦労さんです。
以下ちょっと補足。

1)やばそうな処理
スレッドのポーリングループの継続判断の話ですね。
スレッドプロシージャ内で while( Active) というループがあります。
このループは Active が false になった時に停止するわけですが
変数 Active の書き換えをスレッドプロシージャ内部ではなく外部でやってます(藁
変数 Active はスレッドプロシージャのスタックフレーム上にありますが
こいつへのポインタをプロシージャの外部に渡して
外部から Active の値を書き換えられるようにしてあるわけです。
自動変数のポインタを関数の外部に渡すのは
お世辞にも行儀のいいやり方じゃないんでちょっと留意が必要かな、と。
実際のところは、スレッドプロシージャが制御インスタンスよりも先に
勝手に死なない限りは大丈夫だと思います。

→続く

110 :266:01/09/17 01:49
→続き

2)処理の無駄
これは string を使ってるところ全般、中でも特に
鯖から取得したリストを解析する処理について言えることです。
string を使った代入や結合をやりまくっているので
文字列データのコピーが大量に発生しています。
単一の文字列バッファを標準関数で切り貼りするようにすれば
メモリ消費やCPU消費の無駄をかなり減らせるはずです。


3)例外発生時のクリティカルセクションの解除
これは次のような状況への対処が必要だという話です。

  someSection.enter() ;
  someObject.method() ; // ここで例外が発生する。
  someSection.leave() ; // するとこいつが呼ばれないのでロックされっぱなし。

例外処理を真面目にやってないんで
クリティカルセクションがロックされっぱなしになる場合がありえます。
俺の書いた範囲内では例外は一切投げないようになってるんで
STL のクラスから例外が出てきた時が問題ですね。


負荷対策は時間さえあれば真面目に取り組みたいんですが(泣)
今手元が修羅場です(泣藁

111 :266:01/09/17 01:53
>>107
書き忘れてました。
キャッシュのデータの処理はおっしゃる通りかなり無駄です。
っていうか std::map まんまだし(藁
改良するには ResponseStore の内部実装を書き換えてください。
どういう実装が適切かはなんともいえないところですね。

112 :ファイルアップ隊:01/09/17 02:14
>>109,110
1)はあまりないだろうけどtry...catchした方が良さそうね。
2)は了解。3)はなやみどこだが、1)と同じく例外捕捉して必ずleave
するしかないかも。
>>111
まずは安定版の作成からですかね. プロキシ対応(p2pcache -> proxy -> 2ch)
とかもやりたいけど、思ってるだけですし(藁。

113 :266:01/09/17 02:33
>>112
>>112
CriticalSection の方の解決策を思いつきました。

class SectionController{
  CriticalSection& m_section ;

  SectionController( CriticalSection& section) : m_section( section) {} ;
  ~SectionController( void){ if( m_section.locked()) leave() ; } ;

  void enter( void){ m_section.enter() ; } ;
  void leave( void){ m_section.leave() ; } ;
} ;

こういうクラスを作っておけば、

  SectionController localSection( someSection) ;

  localSection.enter() ;
  someAction() ;     // ここで例外が発生すると、
  localSection.leave() ; // こいつは呼ばれないが、

  // 関数スコープの最後で自動変数である localSection が必ず解放される。

こんな具合に書くことで例外処理を省けます。
どうでしょ?

114 :デフォルトの名無しさん:01/09/17 02:40
>113
普通のCSラッパーに加えてブロック専用クラスをもう一個追加すればいいのでは
class BlockSectionController{
SectionController *sc;
BlockSectionController(SectionController *asc): sc(asc) { sc->enter(); }
~BlockSectionController(){ sc->leave(); }
}

115 :無関係な長文スマソ:01/09/17 18:01
>>108
今は、喉下過ぎて熱さを忘れている状況ではないかと。

また、同じことが起きて、ここに泣きついてくることは十分有り得ることでは
ないでしょうか。

私は使うだけのヘタレなんですが、2chP2P開発の方々のボランティア精神
には、ただただ頭が下がるばかりです。

現在報われない努力をしているようで、開発意欲が下がっておられるのかも
しれませんが、頑張って下さい。
(としかいえません。済みません。これじゃ偽善者ですね)

116 :初心者:01/09/17 23:42
テスト版いれて
よくわかんなかったんで
すぐにデリました。
もっとも期待するデバイスです。
気長にがんばって下さい。

117 :ファイルアップ隊:01/09/19 00:05
>>116
すまそ。現状で使いやすいか? 使う側のメリットは?
というとほとんどそういうことは考えられてないす。
そこまで手が出せてなぃ。(´д`)

>>113,114
ちょっと今頭ぼーとしてるので後で試してみようと思います。

>>115
あいしー

118 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/23 21:44
なんかNIMDAの影響か、うちのサーバーがDoS食らっているのに等しい状態みたい。
ちょいと明日対策します。

119 :ファイルアップ隊:01/09/24 16:55
>>113

教えて下さい。

>2)ReceivingQueue のデストラクタで
>キュー内の残存 Envelope の後始末も忘れてますね(汗)
>queue の要素を全部 delete してやってください。

これは具体的には、m_queue->messenterと m_queue自身の項目を
deleteしてあげれば良いのでしょうか??

>3)Class_Backend.cpp の BackendDriver で
>BackendUnit の onArrival をコールした後に
>result.message を delete してやってください。

resultのmessengerをdeleteでしょうか?
it_envelop = result.beginのpushEnvelopの次の行で削除したら、
BackendOnlyでのpeer間通信で不具合が(汗。

120 :ファイルアップ隊:01/09/24 17:11
週間作業報告です。

GCC版 proto3をリリースしました。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/p2pcache-gcc-linux-20010924-proto3.tar.gz

readme.txtとupdate.txtを付けました。
更新点は以下です。主にGCC版個有の問題対処になります。

・criticalsecionのエミュレーションの刺さりに対処。
・autoheader使用するように変更。
・getopt()に対応。
・-pthread(FreeBSD等)に対応。
・-lsocketに対応。
・Segmentation faltの対策その1として、m_pActiveFlagをm_ActiveFlagにし、
setActive(), getActive()を追加。(これが原因なのかどうかは不明)
・Segmentation faltの対策その2として、LogFileクラスのデストラクト後は
Mutexを使用しないように修正。(これは確実に原因でした)
・刺さり対策として、二度目のsignalが来た場合に、クリーンナップのみ
を行いすぐ終了するように変更。
・listenポートが既に使用中の場合、使用可になるまで
リトライするように修正。

既知バグは以下です。

・一部のリソースがリークしている。
・signalを送るタイミングによっては刺さる場合がある。
・ログが一部化けている。

121 :266:01/09/24 17:12
>>119
毎度です。

ReceivingQueue の方は m_queue に入っている
messenger のポインタを全部 delete してやってください。
言うまでもありませんが m_queue から要素を取り除く必要はありません。

スマソ、BackendDriver の方は書き間違えてましたm(_ _)m
result ではなく envelope の message を delete してください。

122 :266:01/09/24 17:13
>>121
また間違えた。message じゃなくて messenger でした。

123 :ファイルアップ隊:01/09/24 17:34
認識している範囲の残課題は以下です。

1) 既知バグ対処
2) criticalsectionの113,114の反映
3) 103の既知リークの対処
4) その他リーク対処
5) 大量キャッシング方式の見直し
6) Proxyリクエスト対応
7) dat直読みブラウザ対処
8) 使い勝手の向上
9) 速度性能の向上

とりあえず、1〜5がクリアできれば、
GCC版はどっかで連続運転可能なのかなと思っています。
# 一定時間でリブートってのもありだと思うし。

UserフレンドリーなのはWin版がメインだと思いますし。
GCC版ではUser権限で実行できる普通の
daemon(一度起動して後は放置)を目指しています。

124 :ファイルアップ隊:01/09/24 21:42
>>121,122
了解。受信キューの方は、stop()の最後の方で
while( !m_queue.empty() ) {
delete m_queue.front().messenger;
m_queue.pop()
}
で消しました。
# 一応テストは通りました。
でも、<queue>を使うのは初めてなので
勘違いしてたら教えて下さい。_(_ _)_

125 :ファイルアップ隊:01/09/24 21:44
>>124
あ、ちなみにその前後では、
m_section.enter()
m_section.leave()
はしています。

126 :ファイルアップ隊:01/09/24 21:45
なお、修正版(proto4予定)は来週か再来週にリリースしまっす。

127 :デフォルトの名無しさん:01/09/29 04:35
age

128 :なんつーか:01/09/30 04:42
内輪で盛り上がってるみたいだけど、
ブラウザで見れないんじゃ意味なくない?
専用ソフト使ってまで2chなんかみんなやりたくないんじゃねーの?

129 :デフォルトの名無しさん:01/09/30 04:43
>>128
現物はプロキシみたいなものらしい。
実際の閲覧手段は普通のブラウザだよ。

130 :ファイルアップ隊:01/09/30 21:35
週間作業報告です。

proto4をリリースしました。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/p2pcache-gcc-linux-20010930-proto4.tar.gz

更新点は以下です。
- 例外発生時のcriticalsecionの扱いを簡単に扱えるようControlクラスのコードを追加。
ただし、修正箇所が多いのでエラーの扱いを見直す時に反映を決意。(多分)
- 既知のリソースリークに対処。
- 使いやすいよう p2pctl を追加。
- daemonとして使えるよう p2pd を追加。1時間でリブートします。

既知バグは変更ありません。

131 :ファイルアップ隊:01/09/30 21:39
追加ツールの説明です。readme.txtにも同じものがあります。

●p2pdオプション

./p2pd { {start|stop} {カレントディレクトリ} {リブート秒} }

オプション省略時は、./p2pd start . 3600 となります。
また、開始の時には、コマンドの最後に "&"を付けて下さい。
たんなるshellなので付けないとバックグラウンド実行してくれません。
また、第1引数の省略時には、第2、第3引数は指定できません。
同様に、第2引数の省略時には、第3引数は指定できません。

ex)
開始 : ~/p2pcache/p2p-bin/p2pd start ~/p2pcache/p2p-bin/ &
停止 : ~/p2pcache/p2p-bin/p2pd stop ~/p2pcache/p2p-bin/


●p2pctlオプション
------------------------------------------------------
p2pcache controler
------------------------------------------------------
Usage: ./p2pctl action

action:
start frontend start 開始
fstart frontend start frontend開始
bstart backend start backend開始
stop all p2pcache stop 全部停止
abort all p2pcache abort 全部絶対に停止
check all p2pcache resource check リソース漏れチェック
clean all p2pcache resource clean リソース強制クリア
peer-test for peer test peer-test用

132 :ファイルアップ隊:01/09/30 21:52
えーと、さすがに飽きてきたのと、それなりにものとして区切りがついた
ので、このあたりでGCC版の更新をやめます。_(_ _)_
引き継ぎしてもいいよ、と言う方は私にメイルorここに名乗りをお願いします。
特に引き継ぎ者が現れるまでは、ソース、ドキュメントともに
patch等を頂ければあてるつもりでいます。
気が向けばまた更新するかもしれませんが.....

133 :375 ◆MsUYMX0E :01/09/30 21:55
>>132 お疲れ様です。

266さんとかもまだ見てるのかな・・
ここんとこ何もお手伝いできないでごめんなさい。

134 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/30 22:11
→Class_CriticalSection.cpp/~CriticalSection( void)
delete (CRITICAL_SECTION*)m_section ;
の追加。

→Class_ReceivingQueue.cpp/~ReceivingQueue( void)
m_section.enter();
while( !m_queue.empty() ) {
delete m_queue.front().messenger;
m_queue.pop();
}
m_section.leave();
の追加。

>>113の3)の処理はうまくいかないので保留。もちっと調査します。

→Class_Frontend.cpp/HttpSessionDriver(
delete params.socket;
の追加。

→Class_Controlunit.cpp/const GUID ControlUnit_ClassID
0x689abf243,から0x89abf243,へ変更

というバージョンをアップしようとしたのですが、リリースコンパイルでエラー。
ちと調査します。

135 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/30 22:21
うう、リリースコンパイルは無理だぁ(泣)。
とりあえず明日どっかにアップします。

136 :ファイルアップ隊:01/09/30 23:22
>>133
いえいえ。仕様の時、がむばってくれたじゃないですか。
それだけでも十分でしょう。

137 :ファイルアップ隊:01/09/30 23:26
ちなみに、メモリリークを追いたい方は、
gcc版に添付してあるresmon.shを使ってもらうと
状態がみやすいかも。 p2p-bin/resmon.sh
引数は一個で省略可能。第1引数でpsの結果をgrepしてます。

138 :てんてんdwp@ yankee.tokyo-nazo.net:01/10/01 22:02
てんてんdwpです。
http://www.tokyo-nazo.net/~tester/p2p/p2p_q_1001.LZH
の名前で上げてありますが、重大な注意点があります。
・少なくとも私の環境(win98se)ではコンパイルしたexeをそのまま実行してもハングアップする
原因は不明です。
デバッガで追いかけると発生しない現象です。また
・リリースビルドしきれなかった
ちょっとVCの制限で名前がオーバーする現象があり、これが潰せませんでした。
そういうわけで、VC++6.0を持っている人しか使えなくなってしまいました・・・。

139 :デフォルトの名無しさん:01/10/12 04:09
とまっちゃった・・・・・

140 :デフォルトの名無しさん:01/10/12 04:15
転送量問題ってもう解決済み?

141 :デフォルトの名無しさん:01/10/12 04:17
>>140
問題の本質がわかってない。
利用者が増加傾向にある限り転送量問題は終わらない。

142 :デフォルトの名無しさん:01/10/12 04:20
>>141
そりゃそうだけどさ。
今月中旬ぐらい(ってもうすぐか)までに
なんらかのアナウンスがあるとかどこかのスレで見たよ。
商業化するとかしないとかそういう話っぽい。

143 :デフォルトの名無しさん:01/10/12 04:28
>>142
商業化したからって転送量問題が解決するわけじゃなかろう。
利用者は増える、でも転送量は少なくしたい、と言う要求が変わることは
無いと思われ。

144 :375 ◆MsUYMX0E :01/10/12 14:52
お久しぶりです。
ところでいま
C++ builder版
Visual C 版
gcc版
がでてるんですけど、相互に互換性ってあるんでしたっけ?

145 :375 ◆MsUYMX0E :01/10/12 14:53

お久しぶりです。
ところでいま
C++ builder版
Visual C 版
gcc版
がでてるんですけど、相互に互換性ってあるんでしたっけ?

146 :375 ◆MsUYMX0E :01/10/12 14:54
2重書きこすまそ。鬱氏

147 :ファイルアップ隊:01/10/13 02:31
>>145
peer(gcc版) <-> peer(VC版/C++ Builder版)
という意味の互換性では、GUIDが一致していないので、
互換性は(おそらく)ありません。これは、

- WinのGUID生成用のロジックがわからなかったので
gcc版ではMD5を使って代用している。
- GUIDの最初の値が9byteになっていたので、
これをgcc版ではDWORD範囲に収まるように頭1byteを削っている。

によるものです。これを一致させれば互換性はOKなはずです。

148 :ファイルアップ隊:01/10/13 02:44
>>145
ソースレベルの話でいえば、以下のようになります。

■互換性のないもの

- GUI部分(Builder版:Form, gcc版:Console)
- イベント通知(VC/Builder版はWindow Message, gcc版はsignal)
- CriticalSectionの扱い
- GUIDの扱い
- Socket関数の一部(WSA系関数は、gcc版ではない。)

■互換性のあるもの

- その他のほとんど

149 :ファイルアップ隊:01/10/13 02:52
続きです。

なので、ソースをひとまとめにすることは、
#if HAVE_xxxxx_xxx のようにすれば可能なはずですし、
片方で行われた修整作業は他方でも有効なははずです。
互換性を保つのはさほど難しくないと思われます。

150 :てんてんdwp@ yankee.tokyo-nazo.net:01/10/13 13:55
現状のVC版では要望に応えてGUIDを8桁にしてあります。
ですからGUIDの互換は取れていると思われます。
で、頑張ってリソースコンパイル→リリースとしたいのですが・・・
コードをコンパイルしていただければわかりますが、かなり困難なエラー
(VC++上の制限)に引っかかってしまい、辛いところです・・・。

151 :デフォルトの名無しさん:01/10/19 02:43
とまった・・:・

152 :デフォルトの名無しさん:01/10/19 02:45
JXTAってなんの進展もないような気がするけどどうなってるの?

58 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)