datファイルを共有するP2Pソフト o2on 15dat

ZIPで圧縮済みのファイルを、一つの巨大な集まりにして管理するならいい。
個別管理よりINDEXを自己管理する分、読み出し速度は上がるだろう。

ZIP有圧縮をZIP無圧縮でまとめれば、ファイル構造を考えることなく簡単に済むな。

>>951
まずは自分のローカルファイルシステムが荒れるのを防止するために作ってみた。
それと、手元に数万のファイルが鎮座してる状況から脱却できるメリットも大きい。

収納したDATを解凍してから相手に送る処理自体は予想外に軽く、
同時に1〜2個のレベルならオーバーヘッドにもならなそうな感じ。

それと、DATとスレタイと展開先のフルパスを紐付けするINIファイルを作成して、
dat番号を指定するだけでJaneのログディレクトリへ戻すオプションを付けてみた。
Janeで開いた直後は灰色の無効タブだが、再読み込みしたらログが復活した。

しばらくこれで使ってみる。

圧縮の有用性については理解しました。
やってみる価値はありそう。
展開時のレスポンスがネックかなと思っていたので。

あとは、圧縮対応版と非対応版がネットワーク上に混ざったときの
過渡期にどうするか。
非対応版が圧縮データを送りつけられたときに、ちゃんと無視できるかどうか…。

あとは、新しく受け取ったデータから圧縮していくとして、
既存の無圧縮データをどのタイミングで圧縮するか…。
別途コンバータを用意するとか。

tar.gzがいいです＞＜

やっぱLinuxでも使えた方が良いって事には間違い無いよな。
WebUIベースでCUI起動で十分だしね。
Linux鯖にちょこんと載せてやりたい

FYI:
圧縮データベースを使おう
http://alpha.mixi.co.jp/blog/?p=191

http://www.3ch.net/にアクセスしたら、負荷の少ない拠点へつないでそこから掲示板できるように頼む。
一般ユーザーは、インストール不要って事。　P2P型クライアントサーバーモデルね。

Information.comってとこにドメイン確保されてたよ・・・・　別のドメインで。・

基礎から勉強もかねて、unix ,windowsで共通して動くコードにしようぜ。まずはネットワークはどうやったらいい?

perlかrubyかpythonで実装しなおすのがベストだろうな。

>>957
Linuxについては、Wineで動きつつあるっぽいので、そっち方面でなんとか。
オプション画面をWebUIに移せたら、CUIでなんとかなるかも。

>>958
現状でもスレッドはアドレスをハッシュ化した物で管理しているので、
datをDBに突っ込んでも検索速度については変わらないかと思います。
1000行って一ヶ月経ったものはDB化とかにすれば、
フラグメンテーションについても気にしなくて良いでしょうし。

変更するにしても時間がかかるので、とりあえず断片化を何とかしたい人は
フラグメントについてはAusLogics Disk Defragでも使ってもらうとして。

>>949
実況スレとかは圧縮展開のほうに処理が取られそうなので、
DBに突っ込むのは、更新されないと確定したときが良いです＞＜

>>962
よろしく

エクスプローラでもファイル数多いと、表示に時間かかるみたいに
数が多いと、どこかで負荷がかかりそう。

メモリ管理(空き探し、開放など)のような事を、独自で、HDDに対して行えば
一つのファイルのまとめられると思ったが、現実のHDDみたいにセクタで区切れば
連続極域を確保しなくても済むな・。

>>963
ああ、俺Wineで動作確認してた人だけど、やっぱりLinux鯖(常時稼働PC的に)として使ってる人は
Xを入れてる人の方が圧倒的に少ないと思うからCUI+WebUIで完全制御出来たら良いなって事ね

>>967
VirtualPC on CentOS5.2 + wineで実行してみたけど、
dat検索画面の左フレームがパースエラーになった（firefox 3.0.5）のと、
ノードを追加しようと思ったら、管理画面で落ちてしまいますね。
とりあえずそのへんから何とかしないと…。

スレッド1000を閾値にすると
昔1000制限なし時代の一部とか
http://maruheso.at.infoseek.co.jp/index/g_main.html
イレギュラーだが1001ストッパーが壊れた時はどうなるのかなあ

2chはつぶれる危機なので、2chユーザーを全員P2P掲示板へ誘導しようぜ
海外企業へ売却され、いつ保守やサーバー停止するかわからん、

>>969
昔のなら更新される事はないのでアーカイブして問題なし
今現在存続しててストッパーが壊れた場合はちょっとした祭りになるだろうから
数日間放置される事も無いのでは？ という考えで数日未更新ならアーカイブしても良い気がする

>>970

そんなことよりそろそろ誰か次スレを

gzip形式のEXTRA_FIELDにdatのキーと圧縮後のサイズを入れ、ひたすら積み上げる。
そうすると、(.gzを扱うツールはcatしたデータを続けて扱うため)巨大なファイルにも見える。
で、キーとアーカイブ内の位置と圧縮前後のサイズ、および最終更新日を別ファイルに持つ。
(元のファイルから作成可能だけど速度のため)

追加は、フラグメントを避ける(過去にマップ時にOSが数秒間凍るほどの状況になった)ため
ある程度のまとまりを別途作ってから追加する機能だけ。
削除は、インデックスから削除する機能はあるけどremakeしない限りアーカイブには残る。
更新は、同じキーがあったら後半の方を優先することで、見かけ上だけ。
あ、直接HTTPで送れるようにとgzip互換にしたのに、圧縮後のイメージを取り出す機能つけてないや。

というのを以前作ったんだけど、興味のある人いるかな。

>>968
薄い記憶ですが、バージョンが上がった後管理画面が落ちなく(落ちにくく？)なったような・・・
勘違いかも知れませんのでアレなんですが。
他にWinからノードを読み込み済みのファイルだけ持ってきた記憶もありますがｗ
ノードを入れた後は問題無く動いてたと思いました。

管理画面の管理タブ以外を直接開いたら問題無いのですが、管理タブの時に落ちた様な気も。
また時間があったらテストしてみますね。

>>974
ｶﾞﾝｶﾞﾚ。期待してる。

*GB〜サイズ、***ファイルを扱う事になるので、
数個程度の大きなファイルを擬似的なシステムとして扱って
インデックス?ジャーナル?をメモリ上に読み込みつつライトバッファも利かせて・・・
CPU負荷も低くて済む透過的な圧縮が扱えるDBがあれば理想的だと思う。

転送に乗せるのはgzipが一番資料が多そう。
２chのdatの圧縮の時間やサイズはppmdがいい感じだった気がする。

.tar.gzみたいにp7zipも透過的に扱えたような気がする。
データ配置構造で一番参考になりそうなのは
googleや各種wikiエンジンよりもman-dbかなっと思います。

あと数年立てば超巨大容量SSDが一般化して圧縮ぅ〜?って感じになってることはほぼ間違いない。
それでも今は転送の無駄についてはきちんと考えた方がいい。

プログラムの分からない外野からの意見でした。

それよりも全文検索機能を

気持ち悪いコーディングスタイルを何とかして欲しい
戻り値の型とクラス名とメソッド名の間に改行入れるとかなんなの

見る時に不要な改行を消すバッチでも組め

>>978
どの時点で、あのコーディングスタイルになったのかわかりませんけど、
個人的には違和感があるのですが、共同作業なので我慢してますｗ

他の作業者も違和感があるようでしたら、手を付けるタイミング出直していくのもありかなと思います。

管理画面からスレへリンクさせたり、スレのアドレスを専ブラへ渡したりできない？
全レスが取れたか確認したり、補完したログを専ブラで読むときに毎度毎度アドレスをコピーするのが手間なんだけど…

なんか最近拾ってきたDatが妙な事になってたりするな・・・
HDDも少なくなってきたし初期化して1から集め直した方がいいのかな？

>>981
firefox使いの方なら、
\admin\thread.xlsの80行目を
<a href='{url}'><xsl:value-of select="url"/></a>
に書き換えて、拙作URL Relayを使うと、専ブラで開けるようになります。
http://www.osa-p.net/soft.html#urlrelay

IEだとちょっとわかんないです。

>>982
妙なことをｋｗｓｋ

>>983
1000を超えたスレを収集したから、見たら
1-xxxまでログが続いたと思ったら、次のレスが1になってる

いま気がついたんだけどアニラジ実況はスレスト3000みたい

それ2chじゃないだろ

2chがつぶれる前に完成させないと誘導できないだろ。早期完成におねがいします。

何か最近気になるんだが数日つけっぱだと終了時設定を保存していますで
10分くらい待っても正常に終了しないことがある
これはどうしたものか

ほしいファイルを内容で検索する方法考えた。indexを作るのは無理だろう。
そこで、各ファイルごとに24bit(3バイト)ごとの出現回数を調べておき、「大車輪」を検索したかったら
大(車の前半)、　(大の後半)車　、　(車の後半)輪　の3バイトが全てカウントされているファイルを選べばいい。
24bit全てのデータを保持しておくのは負荷が大きいので、良く出る1万個くらいでいいとおもう。
さらにこの方法で、ある文書を指定したら類似するファイルを列挙できる。
2^24のベクトル空間と見なして、そのなす角を求める。

そうね

カウントを2バイトで記録したとしても1万種類だと、各ファイルごとに20Kバイト追加する事になる。
種類を減らせば、検索効率が落ちる。

ほとんどの単語は2語以上の合成だとすれば、2バイトごとに
語の合成が起こる所だけ統計を取れば、数は減らせるな。

(大の後半)(車の前半)、　(車の後半)(輪の前半)

P2Pの相手に、例えば52551番、7784番を含むファイルはあるかとたずねて、あったら出現回数やタイトルや部分的な内容を送信してもらう。

油断してた次スレ立てました

http://pc11.2ch.net/test/read.cgi/tech/1231570128/

namazu

ume

2chのオーナー変わったみたいだからな
マジでこれから取り潰しになる鴨試練

>>994
乙

ume

次スレ

http://pc11.2ch.net/test/read.cgi/tech/1231570128/

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。