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

2 :デフォルトの名無しさん:01/09/02 20:59 ID:71SdL9Z6
レスしにくいので前スレから引用。
---------
>>958
書き込み処理はまだスケルトンしか実装してません。
今から実装して試してみますね。

簡単ながら現時点でのテスト結果報告です。
ひとまず読み込みキャッシュには成功してます。
ローカルホスト内でピアを二つ起動してキャッシュを探るのも大丈夫です。
現時点でも、既に以下の問題点を確認してます。

1)resinfo などをサーバーから取得するのに時間が掛かる。
ピアのキャッシュを調べる前にまずサーバーから
thread や resinfo を取り寄せますがここで半秒程度から待たされます。
今は CGI の呼び出し一回ごとに TCP コネクションを張っているので
これを改めれば改善されるでしょうがそれでもかなりのネックになりそうです。

2)ピア間通信に時間が掛かる。
これもメッセージ送信ごとに TCP コネクションを張っているせいです。
一組のピア間では一つのコネクションを張りっぱなしにして
その上でメッセージ交換をしなくちゃいけませんね。

後者は比較的容易にどうにかなりますが
前者は設計上ちょっと工夫が要りそうです。
これ以外に実装上の手抜きの問題もありますが
プロトタイプということでそれは後回しということで。
ここまでのご協力、ほんとに感謝してます。>All
---------

3 :895:01/09/02 21:11 ID:070S2IqE
up しときました。

ftp://210.170.170.118/incoming/p2p/p2p-0.03.cgi.2

resinfo が遅いのは md5 の処理をしているからだと >>2
最終的には値を取り出すだけになるはずです。

4 :デフォルトの名無しさん:01/09/02 21:17 ID:71SdL9Z6
>書き込み処理はまだスケルトンしか実装してません。
>今から実装して試してみますね。
書きこみはキャッシュせずに直書き(すどおし)であってますよね...

>>前スレ894
>P2Pcache の場合にはリレーの中継点にも
>キャッシュさせていくという活用方法がありえますが
>やっぱやめておいた方がいいですかね?
peer一覧から取得したIP以外には接続しにいかないようにするのが
良いかもしれません。一覧にないところに問い合わせしても
キャッシュされていない可能性が高いですから。
というのと、不要パケットを減らすという意味で。条件つけて
接続範囲を絞っていくしかないんではないかと思う。

5 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/02 21:19 ID:UbqfbXOg
新cgiアップしました。
・プログラマ>895氏
・プロジェクトリーダ>266氏
・サーバ提供>私
というのが現状で、私はcgi開発にはタッチしていません。念のため。

6 :デフォルトの名無しさん:01/09/02 21:21 ID:71SdL9Z6
>>4
補足。
:peer一覧から取得したIP以外には接続しにいかないようにするのが
これは一覧のIPからさらに先には探しに行かない、という意味です。
クエリ来たらあるなしだけ答えて終わり。

7 :デフォルトの名無しさん:01/09/02 21:35 ID:71SdL9Z6
>>7
あ、こんなんいかが?

1.クライアント→P2Pcache1←[一覧]→2ch
2.P2Pcache1は自分の持っていないのを他のP2Pcache2に問い合わせ(TCP接続する)
3.P2Pcache2がデータもっていなければないと答えるか、無視?(TCP接続はしたまま)
4.P2Pcache1が2chからデータ取得
5.P2pcache1が2にキャッシュ用データを送信してキャッシュしてもらう
6.TCP接続切断

もう既になっているんかいな。

8 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/02 21:43 ID:UbqfbXOg
>>7
再帰
と、冗談は置いておいて、明日から仕事始まるのでスクリプトの更新は
今日は午後11時まで。
明日以降は午後10時〜11時くらいになりますm(__)m

9 :266:01/09/02 21:49 ID:zR1.Ai4.
>>4
書き込みは素通しですけど内部で1クッションありますんで。
bbs.cgi に書き込みをするとリフレッシュ待ちのページが出ますよね?
あのページをブラウザに表示してしまうと 2ch の本鯖に飛ばされてしまうんで
それを抑止するために HTTP のセッションをラッピングする必要があるんです。

ピアの話は要は検索メッセージのネズミ算式増幅はやらないってことですよね。
これは 2ch ぐらいの規模のサイトなら確かに上手くいくかもしれません。
実験結果次第でしょうね。

>>7
おっしゃってるフローがちと分からないです。
今は次のようなフローです。

1)ブラウザからスレ表示要求がローカルの P2Pcache に届く。
2)該当スレ内のレスがローカルキャッシュにないかどうかを調べる。
   >レスが見つかればそれを表示して終了。
3)ローカルになかった分のスレ情報を 2ch.net から収集する(threadやresinfoのリスト)。
4)スレ情報を検索メッセージにまとめてピアにばらまく。
5)しばらく待つ。
   >この間に P2P メッセージ交換が行われる。
   >うまく行けばレス内容を保持したメッセージが他のピアから届き
    届いたレスはローカルキャッシュに登録される。
6)ローカルキャッシュを調べる。
   >レスが見つかればそれを表示して終了。
7) 2ch.net 上から見つからなかったレスの内容を直接取り寄せる。
8)ブラウザにレスポンスを返す。

10 :デフォルトの名無しさん:01/09/02 21:52 ID:71SdL9Z6
あ、そだ。
cgiとのTCP接続のオーバーヘッドですが、httpの場合Connection: Keep-Alive
とConnection: closeを使うと多少へらせます。
未サポートのサーバの場合には切られちゃいますが。
http://way.direct.ne.jp/HTTP/connections.html

Ex)telnet www.goo.ne.jp 80
GET / HTTP/1.1
Host: www.goo.ne.jp
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Sun, 02 Sep 2001 21:45:22 GMT
Content-Length: 44384
Content-Type: text/html
Set-Cookie: inkid=n92b0ADNgACIgQDyKuj7zMAAEWoi; expires=Wed, 01-Dec-2010 00:00:0
0 GMT; domain=goo.ne.jp; path=/
Cache-control: private

(内容)
GET / HTTP/1.1
Host: www.goo.ne.jp
Connection: close

HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Sun, 02 Sep 2001 21:45:51 GMT
Connection: close
Content-Length: 44392
Content-Type: text/html
Set-Cookie: inkid=n92b0ADNgACIgQDyKuz%2BzMAA0yqQ; expires=Wed, 01-Dec-2010 00:00
:00 GMT; domain=goo.ne.jp; path=/
Cache-control: private

内容

11 :7:01/09/02 21:54 ID:71SdL9Z6
>>9
領海。無視してください。

12 :266:01/09/02 22:00 ID:zR1.Ai4.
>>10
それを今考えてるところです。
情報のリストごとに ResInfoList みたいなクラスを作って
そのクラスの中に HTTP アクセスの処理をカプセル化してあるんですよ。
複数のリストに跨ってコネクションを Keep-Alive しようとすると
この辺の構成をちょっと考えないとスパゲッティになりかねないのが問題です。

13 :266:01/09/02 22:17 ID:zR1.Ai4.
あのー、bbs.cgi はまだ改造してないんですよね?(藁
すいませんが書き込み実験用のスレを thread.list に
追加しておいてもらえませんか?>てんてん氏

14 :デフォルトの名無しさん:01/09/02 22:22 ID:71SdL9Z6
>>12
了解。とりあえず順調そうでよかた。
何かいきづまったり未割り当ての仕事があったら、
ここに書いてもらえれば少しは協力できるかも。

15 :デフォルトの名無しさん:01/09/02 22:33 ID:71SdL9Z6
>>13
:あのー、bbs.cgi はまだ改造してないんですよね?(藁
bbs.cgiの改造はてんてん氏の仕事ではなかったと思うにょ。
わかっていると思うけど念の為ね。:-)
# ちと私の職場でよくある仕事の押し付け合いを連想してしまったので...
# 明日は会社だ。ゥ津田。

16 :266:01/09/02 22:34 ID:zR1.Ai4.
>>14
目下の最大の問題は仕事です(藁
ここ2、3日はこればっかでほとんど仕事してないし(藁

あとは引き継いでやる!、って方がいたら募集します。
ソースはBCB依存ですが依存部分は
_beginthread, _endthread, TNMHTTP だけです。
前者二つは VC のと同じなんで TNMHTTP をどうにかしつつ
STL で引っかからなければ VC にも移植できます。

17 :266:01/09/02 22:37 ID:zR1.Ai4.
>>15
その辺はもちろん了解です:)

で、その CGI ですがバグらしき動作に気付きました。
resdata を取得する時、スレ内の最後のレスが取得できないようです。
チェックをお願いします。>895氏

18 :デフォルトの名無しさん:01/09/02 22:42 ID:71SdL9Z6
>>16
うぃ。では266さんが妥協できる程度実装しおわって
ソースアップしてもらえれば、募集しませう。
さすがにソース見ずに引継ぐぜ!というツワモノはいないと思うので。
逆に、ある程度終われば266さんは引継ぎ者がいなくても
終了しちゃってよいのではないかと思います。

19 :895:01/09/02 22:58 ID:070S2IqE
>>17 確認しました。修正したものを up しときました。p2p-0.03.cgi.3

20 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/02 23:09 ID:UbqfbXOg
えと、thread.listとpeer.listは無ければ自動生成するんですよね?>現状
であれば、この2つを消せばいいはず。
というわけで、この2つのファイルを消すスクリプトを入れときました。
p2pのテストの前に動かすとこの2つのファイルを消します。それ以外は何もしません。
http://www.tokyo-nazo.net/~tester/p2pclean.cgi
>>19
新スクリプトに入れ替えました。

21 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/02 23:14 ID:UbqfbXOg
・・・両方消すのは馬鹿っぽいぞ・・・。
>>20取り消し。
http://www.tokyo-nazo.net/~tester/delpeer.cgi
http://www.tokyo-nazo.net/~tester/delthread.cgi
に分けました。馬鹿>自分

22 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/02 23:26 ID:UbqfbXOg
今日の更新は終わりなので、何かあったら明日の夜に差し替えますm(__)m

23 :関係ないけど:01/09/02 23:31 ID:lqLYH57Y
UD-Agent みたいに2ちゃんねらーの余剰CPUパワーを生かせんかな。

24 :デフォルトの名無しさん:01/09/02 23:34 ID:71SdL9Z6
>>21
ごめん。アクセスするとOKとか聞かれずにいきなり消えるのね。
delpeer.cgiの方アクセスしちゃった(泣。

25 :266:01/09/02 23:39 ID:zR1.Ai4.
ご苦労さんです。>てんてん氏&895氏

スピードが遅いのはやはり HTTP のセッションを
リスト取得のたびにいちいち作るからのようです。
これは丁度 TNMHTTP への依存部分でもあるので
ここをソケット直叩きでスクラッチしてBCB非依存かつ
Keep-Alive 可能なものに変更し、その段階でソース&バイナリ公開とします。
さぁ、今夜一晩で終わるか?(涙)

26 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/02 23:45 ID:UbqfbXOg
>24
うみゅうう。ピアのほうはよく考えたら追加の機能があるんだから
削除する必要無いですね・・・。
消しときやした>スクリプト自体

27 :デフォルトの名無しさん:01/09/02 23:47 ID:71SdL9Z6
>>26
すいませんです。_(_ _)_

28 :名無し:01/09/02 23:55 ID:5ndlHDsk
P2Pの事はこの辺で調べてきてね。

http://www.jnutella.org/

29 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/03 00:13 ID:VGV4A8WI
こちらがp2pテストに参加してくれるそうです。
http://61.121.247.239/~kikaku/post/entrance/index2.html
ではまた今夜。

30 :266:01/09/03 04:06 ID:i5xjtCL.
TNMHTTP 排除版を書くだけは書いてみました。
まだ動作がバグバグですがCPU負荷は激減した(藁
ところでどうも鯖側動作に不可解なところがあります。

GET /~tester/p2p.cgi?list=thread&board=entrance&page=0 HTTP/1.1
Host: www.tokyo-nazo.net
Connection: close

こういうリクエストを送ると、
何故かレスポンスの先頭に 58 CRLF という文字がくっついてきます。
これって HTTP に規定の動作なんですか?
ブラウザで見るとこの数字は出てこないんですよね。

31 :266:01/09/03 04:10 ID:i5xjtCL.
スマソ。Transfer-Encoding: chunked になってました。

32 :デフォルトの名無しさん:01/09/03 14:00 ID:F6DSnr0Y
なんか掲示板の調子がおかしいですね

33 :266:01/09/03 14:34 ID:i5xjtCL.
ん?板止まってる?

34 :266:01/09/03 14:40 ID:i5xjtCL.
ひょっとして書き込まないと最新のログ読めない?<今の板の状態

35 :375 ◆MsUYMX0E :01/09/03 14:40 ID:yn8LLgz6
お疲れ様です。
index2.htm が更新されないみたいですね..

36 :デフォルトの名無しさん:01/09/03 16:18 ID:sEQgolJo
>32-35
一時的なものかどうか不明ですが、CGIが作るHTMLファイルが
index2.html→index.htmlに変更されたもよう。

37 :デフォルトの名無しさん:01/09/03 17:24 ID:c4JN2YfA
test

38 :266:01/09/03 19:03 ID:i5xjtCL.
できました:)
ローカルキャッシュ、P2Pキャッシュ、
メッセンジャールーティング、掲示板への書き込み、全部テスト成功しました。
これからソースとバイナリを公開すべく
ちょこちょこと説明ファイルなぞ作ります。

39 :デフォルトの名無しさん:01/09/03 19:12 ID:neVjkEh.
おめでとうございます:)

40 :375 ◆MsUYMX0E :01/09/03 19:48 ID:cnsVdd12
おめでとうございます。

41 : :01/09/03 20:32 ID:qqnGSLcE
おめでとうございます。

42 :デフォルトの名無しさん:01/09/03 20:37 ID:IOyq7ATw
おとなしく見守ることしかできませんでしたが、本当におめでとうございます。

43 :266:01/09/03 20:43 ID:i5xjtCL.
皆さんありがとうございます。
でもあくまでもプロトタイプなんで期待しないでください(苦笑
エラー処理とかチューニングがないも同然なので
ここから先が肝心です。

てなところでリリース作業中・・・。

44 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/03 21:17 ID:VGV4A8WI
おお、おめでとう。
実験結果だけは先に書きこみ先で見ていたけど、実際ここで報告があると違うね。
サーバ提供した甲斐があった。リリース頑張ってください。

45 :デフォルトの名無しさん:01/09/03 21:54 ID:U9hn1Usc
テステス

46 :ファイルアップ隊:01/09/03 22:01 ID:BQsR9gow
>266さん
おめでとうございます。

>895さん
upしてあった仕様でresdataが抜けてましたね。
ご迷惑をお掛けしました。
あと、他に現実とあっていない部分がありましたら
教えて頂くか、修正版を置いて頂ければとりにいって
和geoの方にもupします。
とりあえず、わかる部分は直しました。

新:http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/P2Pcgi-spec.txt
旧:http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/P2Pcgi-spec-1.txt

新と旧との差分(diff -urN)
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/P2Pcgi-spec-diff-1.txt

cgiは、p2p-0.03.cgi.3が最新で正しいでしょうか?
また、upキボンのドキュメントがあれば教えて下さい。 upします。>all

47 :デフォルトの名無しさん:01/09/03 23:28 ID:1zSk4pr2
テステス

48 :266:01/09/03 23:45 ID:i5xjtCL.
アプしました。
動作確認などよろしくお願いしますm(_ _)m

http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/

あと、これを機に引継担当の人を募集します^^;

49 :266:01/09/04 00:07 ID:HaGsnU7w
どうも起動に失敗することがあるみたいですね・・・。
その場合は停止ボタンを押さずにいきなり閉じてください。
その後でもう一度起動するとうまくいく?
ちょっと原因を調べてみます。

50 :デフォルトの名無しさん:01/09/04 00:49 ID:taq6YMMs
test

51 :デフォルトの名無しさん:01/09/04 00:59 ID:EcqU4D62
frontend側、port 80固定でlistenしてるんかな。
うち80は埋まってるので変えられるようにキボン

52 :266:01/09/04 01:02 ID:HaGsnU7w
>>51
内部は可変ですけどダイアログとかからはいじれません。
次のバージョンアップで変えられるようにしときます。

53 :51:01/09/04 01:35 ID:EcqU4D62
よくわかってないんすが(^^;
読み書きはできてるかんじだけど
起動するとバックエンドが他からもリクエスト受けるはずなのかな?
ログ見てても静かだけど
あと
http://www.tokyo-nazo.net/~tester/p2p.cgi?list=peer&board=entrance
って見ても空っぽに見える…

54 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/04 21:19 ID:B9sbxuG2
>>53
前スレ939から
>http://www.tokyo-nazo.net/~tester/peer.cgi?board=entrance&port=XX
>この呼び出しで、呼び出し元のIPとパラメータ中の port を
>peer.list に追加する CGI を用意していただけないでしょうか?
>よろしくお願いします。
っつーことなので、peer.cgi書きます?

55 :デフォルトの名無しさん:01/09/04 23:17 ID:2GriM8eo
>>48
ばっちしだょ!!
ていうか、キャッシュされている様子がわかって面白い。
Win98で試しました。

56 :デフォルトの名無しさん:01/09/05 00:32 ID:HUg1Aj1Y
人柱になりたいのですが、どのファイルを落として実行すればいいのでしょうか?
>>48

57 :デフォルトの名無しさん:01/09/05 00:40 ID:ojARQyVw
>>56
ソースいらない人用
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/P2Pcache-2001-09-03usr.lzh
ソースいる人用
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/P2Pcache-2001-09-03dev.lzh

58 :895:01/09/05 00:49 ID:xg.9CfwQ
遅ればせながらおつかれさんす >266・てんてん氏
>>54
peer.cgi だったのか。間違えて p2p.cgi の方に追加しちゃってたよ。
なんか寝ぼけてたのかな。
ということで、今の所、間違って実装した結果、
p2p.cgi?list=peer&board=entrance&port=XX でも追加できます。

59 :デフォルトの名無しさん:01/09/05 10:00 ID:5W89DctU
(・∀・)イイ!
FW内でも問題無く使えたYO!
早く2chのスレが見れるようになるといいなあ〜

60 :266:01/09/05 15:03 ID:5HdTS13k
スマソ。今までネットにつなげる環境にいませんでした。

>>58
ども。
次のバージョンで機能を組み込んでみます。
できれば今日中にリリースしようと思います。

ところで思ったんですが
Backend の中身をまるまる DLL 化して、
かちゅ〜しゃやその他の 2ch ブラウザで使えるようにするってのどうでしょう?

61 :デフォルトの名無しさん:01/09/05 16:09 ID:5W89DctU
>>60
(・∀・)イイ!
かちゅ〜しゃ使えたらいいなと思ってたところです

62 :266:01/09/05 16:32 ID:5HdTS13k
>>61
どうやって作者さんに組み込みを要請するかが問題ですね。
monazilla の方へ持っていったらいいのかな?

63 :895:01/09/05 17:28 ID:xg.9CfwQ
ftp://210.170.170.118/incoming/p2p/p2p-0.03.cgi.4
ftp://210.170.170.118/incoming/p2p/peer.cgi

up しました。 peer 登録を peer.cgi に移したものです。

64 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/05 19:35 ID:7kIol4Ww
>>58,63
自分で組むかとソースを見たら中にあったことに気づいてびっくりしたところです。
うみ、一緒ならそのままでもOKだったかも。でもありがと。
さっそくアップしました>新cgi

65 :266:01/09/05 19:54 ID:5HdTS13k
スマソ。
間が悪くて本当に申し訳ありませんが
ピア削除機能も付け加えてもらえませんか?

peer.cgi?do=add&board=entrance&port=XXXX

これで追加で、

peer.cgi?do=del&board=entrance&port=XXXX

これで削除という形にお願いします。

これと被る話ですが、作業区分という意味ではピア一覧の扱いも
p2p.cgi ではなくて peer.cgi に持っていった方がいいかもしれませんね。
あるいはピアの追加、削除なども全部まとめて p2p.cgi の方へ持っていくとか。
どちらの方がすっきりしそうですか?>895氏

重ねてすいませんがこれから小一時間ほど席を外します。

66 :895:01/09/05 23:14 ID:xg.9CfwQ
ftp://210.170.170.118/incoming/p2p/p2p-0.03.cgi.5
ftp://210.170.170.118/incoming/p2p/peer.cgi.1

up しました。とりあえず、peer 登録・削除機能を p2p-0.03.cgi, peer.cgi
の両方につけときました。

p2p.cgi?list=peer&do=add&board=entrance&port=XX
peer.cgi?do=add&board=entrance&port=XX
add を del にすると削除します。

67 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/05 23:22 ID:7kIol4Ww
>>66
スクリプト入れ替えました。ピア一覧取得機能
http://www.tokyo-nazo.net/~tester/p2p.cgi?list=peer&board=entrance
が通らなくなった模様。

68 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/05 23:29 ID:7kIol4Ww
というわけで、p2p-0.03.cgi.4にバージョンダウン。
peer.cgi.1のほうは差し替えました。

69 :266:01/09/05 23:35 ID:5HdTS13k
ども。
対応したバージョンを作ってアプしときます。

70 :266:01/09/06 00:51 ID:1caBmc2U
アプしました。
今日はこれで寝ます。

71 :895:01/09/06 02:34 ID:Lr4gzXHg
スマン。修正した。
ftp://210.170.170.118/incoming/p2p/p2p-0.03.cgi.6

72 :デフォルトの名無しさん:01/09/06 11:12 ID:/K7dkAEM
だんだん使いやすくなってきた

ところでくだらない要望なのですが、最小化ボタンつけてもらえませんか?
会社でこれ使ってるので・・・

73 :デフォルトの名無しさん:01/09/06 11:24 ID:x54XUUQc
>>70
フロントエンドのポート番号指定が機能してませんー
81入れてスタートすると80に戻ってしまう…

74 :人柱報告:01/09/06 15:10 ID:7XfDzD9g
>57
入れてみましたが、スレ一覧の表示のところが文字化けまくりで、文字デコードを変えると前の画面に戻ってしまいます。
環境
Pen III 800EBMHz Dual
Win2K SP2
CATV グローバルID

75 :266:01/09/06 18:22 ID:1caBmc2U
>>74
各種 htpl ファイルに次の meta タグを入れてみてください。

<meta http-equiv=Content-Type content="text/html; charset=x-sjis">

htpl ファイルは P2Pcache.exe と同じディレクトリにあります。
これで解決すればいいんですけど解決しなかったら調べる必要ありですね。

話は変わりますが仕事の方がかなりヤバくなってしまいました(泣
これから先、チューニングやメンテなどをやってる余裕は作れそうもありません。
引継をやっていただける方を切に募集中です。

76 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/06 20:28 ID:sXtzlBEI
cgiを6に差し替えました。
あと、うちのほうに上がっていたんですが
>自動にリンクタグつかないのね
だそうです。

77 :名無しさん:01/09/07 01:05
222踏んだsage

78 :266:01/09/07 02:37
改訂版をアプしました。
これが俺ができる最後の改版になるかもしれません(泣)
仕事やべぇ・・・。

79 :72:01/09/07 10:03
>>78
くだらない事に対応してくれてありがとうございます
これで心置きなく仕事場でテストできます(ワラ
お疲れ様でした

80 :Uー名無しさん:01/09/08 23:55
このスレ、どうなってるんでしょうか?
結局、ここが、一番有望そうにみえるんで、期待してるんですが。
何もできなくて、申し訳ないですけど。

81 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/09 00:25
>>80
266さんがVC++に移植してくれたようですので、とりあえず私が継ぎます。
まずはバグ対応くらいしかできませんが、折りを見て改良という形になると思います。
で、現状の問題点を誰かまとめて頂けませんでしょうか。

82 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/09 00:35
うう、incomingに繋がらない・・・

83 :266:01/09/09 00:44
>>80
現時点でプロトタイプはできあがってます。
ピア間でのキャッシュ機能も正しく動作しています。
プロトタイプとソースコードは以下のサイトで配布中です。

http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/

あとはチューニングと動作品質の向上が主要課題です。

>>81
引継ぎありがとうございますm(_ _)m
俺の方で把握している問題点については ReadMe.txt の方に書いてあります。
まずは効率的なキャッシュを行えるパラメータを探ることと、
ピア間コネクションのプールから片付けるのがいいと思います。
前者は実験次第ですが、後者については、
他の部分のコードを維持することを考えれば
CastingQueue/ReceivingQueueの中で
一度張ったコネクションをプールして、一定時間内に
同一のアドレスに対するコネクションが必要になった場合には
これを使いまわす、という形にするといいと思います。
現状のソースについて分からないことなどがあればどんどんお願いします。

84 :266:01/09/09 01:17
寝る前に一つ追加。
ユーザーさんから見た場合の使い勝手は
Frontend や設定ウィンドウの方の改良に掛かってきますが、
俺としては Backend の改良に時間を割くべきだと思います。
Backend には十分な汎用性を持たせたつもりなんで、
これを DLL あたりにまとめれば任意の 2ch 系ブラウザで利用できるはず。
あと、おまけでふつーに P2P アプリを作れるようにもしてあります。
ClassID(GUID)さえ独自に定義すれば
自作アプリの独自メッセージを流すための P2P 汎用処理モジュールとして使えます。
時間さえあればなぁ・・・。

85 :デフォルトの名無しさん:01/09/09 01:31
とりあえず、2ch系ブラウザでproxy使用の設定にして、
dat読みをエミュレートするのは面倒なんでしょうか?

86 :ファイルアップ隊:01/09/09 13:12
GCC移植チャレンジ組です(根気が続けば)。
とりあえず、他にチャレンジする人もきっといると
思うから、情報共有します。(誰もいないのだろうか)
# さぁ、君もLet's try.(藁

BCB -> GCC(2.91.66)
stringstream -> strstream
USEUNIT -> #include
Button -> bool
Edit -> char []
ios_base -> ios
fstearm(char) -> fstream(char, int)
fstream::traits_type::eof() -> EOF
_beginthread -> pthread_create
GUID -> MD5と長さが同じなのでごまかして使う
CriticalSection -> fcntl() ※オブジェクト単位にLock Fileを変える。
Class_Socket -> WSA◯◯をコメントアウト

pthreadの代わりにforkを使うのはとても面倒なので諦めました。
他Processになるとデータのやり取りが繁雑。
(Classのプロパティなどをやり取りするのに他Processでとれる
ようにしないといけない。また、デストラクタも注意が必要。)
単純にforkを使うと、キャッシュなどがFront側でとれなくなた。

87 :ファイルアップ隊:01/09/09 13:25
>>85
2ch系ブラウザの仕様が、dat直読みだとすると、
urlから板とスレを特定してやればできないことも
なさそう(な気がする)。
Proxy対応はまだしてないと思うので
対応しないといけないけど(多分。

ただ、進捗的には、それ以前のような気もする。
やっと、引き継ぎの人が決まったようだし。
対応ブラウザの種類を多くするのは大切なことだけどね。

88 :266:01/09/09 14:16
>>85
方向としてはアリだと思います。
普通の HTTP 串としての実装さえできれば
そこに割り込ませるのは簡単でしょう。
ただし、ブラウザ側と P2Pcache 側で
ローカルキャッシュが二重化するといった若干の効率の悪さはあります。
Proxy 化するのであれば j2ch-cache のソースをベースにして
これに統合していくのが確実でしょう。

89 :266:01/09/09 14:16
>>86
ダメなソースにお付き合いいただいて恐縮ですm(_ _)m
モジュール間の通信路は基本的には次の3つです。

Frontend→Backend
Frontend→ResponseStore
Backend→ResponseStore

この三つのインターフェースさえとれれば
あとはモジュール内部での通信ばかりになります。
ただし、メッセージ単位でスレッドを作りまくっているので
全部をプロセスに分割するのはまずいと思います。
プロセスへの分割を行うとすれば
Frontend, Backend, ResponseStore の単位で区分し、
通信周りは非同期ソケットを使うことになるでしょう。

MainWindow.h/.cpp は無視してくださってOKです。
あれは設定ウィンドウのインターフェースを用意してるだけなんで。
あと、CastingQueue, ReceivingQueue あたりにあるコードもテスト用です。
この辺を無視すれば USEUNIT, stringstream, fstream, Button などの
話は考えなくてもよくなります。
VC に移植した分でもこの辺はすっぱり切り落としてあるので
移植の際にはこちらを参照していただいた方がよいかもしれません。

90 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/09 19:18
最終的には例えばかちゅーしゃなりモナリザなりから詠めるDLLとして、
かちゅーしゃなどのログからデータをもらえるような仕組みというのは必要
だとは思いますね。
非同期SocketクラスであるCAsyncSocketを使えばも少しソースがすっきり
・・・するといいなぁ・・・(爆)。
インターフェースに関してはちょっとブラウザ作者さんと話がしたいですね。

91 :266:01/09/09 19:33
>>90
スパゲティなソースですいません(泣)
実際の所 ResponseStore のメンバは
retrieveResponse と registerResponse ぐらいしか使わないんで
これを普通の関数に落としてしまうのが楽でしょう。
で、Backend.dll に対しては関数ポインタをコールバック用に渡す、と。
DllMain あたりで引き受けた関数ポインタをラップする
ResponseStore クラスに食べさせてしまえばソースを弄る部分もほとんどありません。

92 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/09 21:09
>>91
今一番まずいのは私の技術力の低さでして(泣)。
こういう書き方をすると誤解を招くかも知れませんが、一応私が引き継いだとは
いえ、私は全部を引き継ぐつもりはありません。
もちろん私もコード改良にタッチしますが、せっかくのオープンソースなのです
から、何かあったときはみんなで解決というスタンスを取りたいと思います。
この266さんプログラムは私一人でやるにはあまりに重すぎるのです(^^;
そういうわけでBCCに移植というのは喜ばしい話です。
>>86さん、頑張ってください。私も頑張りますから(^^;;

93 :ファイルアップ隊:01/09/09 21:43
>>89
いや、ソースは綺麗な方です。むしろ、自分の技術力の低さが。
C++は慣れてないので、ミックスランゲージぽくなりそうなのが怖いです。
# まぁ、それはそれでいいか(藁。
とりあえず、Win版に近づくことが目標です。
GUIはつけるとあれこれ問題がでやすいのでつけませんが。

94 :ファイルアップ隊:01/09/10 01:10
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
で通したproto1を置きます。完全開発者orもの好き用(debug buildだし)です。
pthreadのlibraryを必要とします。
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1506/files/p2pcache-gcc-linux-20010909-proto1.tgz

ブラウザで接続するデフォルトポートは5080です。
使い方は一応 ./p2pcache -hで出ますが説明になっていないような。
./p2pcacheをforgroundで実行して準備ができると、キー入力を受けつけるので
何かキーを押すと終了します。ほっとくとそのままつかえます。
lockファイルはカレントに作るので、あちこちつくらないように注意して下さい。
よくわからなければ、killして下さい。再実行も問題ありません。
cachingファイルの書込みなどはまだサポートしてません。

尚早にあげたのは、基本的に週末以外は進捗がない(お仕事)からと
VC版もでてブランチがあまり離れすぎることを嫌ったためです。
# ぜんぜん違う路線に行くと悲しいじゃない。

95 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/11 20:58
>>94
私も土日以外はほとんど動けないっぽいのであいこです。
今は安定性向上のために何をすべきか考えているところです。

96 :スレ違い気味スマソ:01/09/13 16:57
P2Pに興味がでてきたのでJxtaをいじろうと思ったのですが、
http://www.jxta.org/
からどうやってもdownloadページに行けませぬ。助けて。

97 :age:01/09/13 20:52
age

98 :デフォルトの名無しさん:01/09/13 21:20
行けるぞ?繋がらないのかい?

99 :96:01/09/14 02:17
>>98
今見たらつながりました。ごめん。
夕方のときはいろんなとこがリンク切れしてたのです。。。。

100 :名無しさん@プログラム:01/09/15 01:11
ここの開発状況は今どういう感じなのでしょうか?
ひろゆきさんや夜勤★さんはここの作業状況は
どの程度把握してるのでしょうか?

なにぶん素人なもので、申し訳ありませんが、
只、やきもきして見守るばかりです。
作業のじゃまでしたら、どうか無視してください。

101 :266:01/09/15 02:41
とりあえず仕事で死んでます(泣)

102 :てんてんdwp@ yankee.tokyo-nazo.net:01/09/16 21:22
メモリリークのチェックしようとして失敗(^^;;
再チャレンジします。

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.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)