Share(仮称)Part 21

公式更新
村長乙です
<!--

ライブデバッグの時間がなさそうなので明日あたり公開しよう。

とっくの昔に拡散周りの修正は終わっていたが、ほったらかしのGUIの実装をやってたり。

推定クライアント数は文字通り推定であってそれが全部ではない。
前にも書いたが、接続したホストのIP、ノードのIP、キーのIPでカウントされている。
最もカウントの割合が多いのがキーである。
今の値はどちらかといえば検索可能範囲の数値に近い。

前の検索アルゴリズムは他人のクエリ結果を自分のリストに追加する動作を連鎖的に行うことで
キーの移動が行われていたため、キーの検査量が多かったために推定クライアント数のカウント率が
Alphaより高かったわけである。

Alphaからは検索アルゴリズムが大きく変更されたために、とっても遠くのクラスタのキーは殆ど伝播されない。
その代わり周辺のホストならば効率よくキーをかき集めることができるようになっている。
条件は細かく指定するほど、1回で効率よくキーを収集することができる。

あと、どうでもいいがリソースリークは存在しない。つーかフラグメーションも直した。
それでもメモリ馬鹿食いしているのは、開放されていないSearchやShareの接続があるからだろう。
この問題は次のバージョンで多分直る。でもちゃんと報告してくれないから原因が不明の部分もあるんだよね。
バージョンと回線速度、その時のSearch Shareの接続数、トリガ、カタログ、キー保持数などの設定、
キャッシュの保持数、およびLinkキャッシュの総数をきちんと書いた報告を今まで見たことがない。
特にログのコピペは最低限バージョン書け。それと時間とか勝手に削るな。日に何回もバージョンアップする時は
どの時のログか分からんし、時間はタイミングを知る上で重要な情報である。
落ちてコネーと喚くなら、まず自分の環境を晒せ。設定による問題かそれともプログラム的な問題なのかそれを知る必要がある。
とは言うものの、現在カタログ登録状態だと登録しているファイルはアップロードが発生しないのも事実。

ちなみに、a6bはキャッシュフォルダの容量が少ないと中の人エラーがおきるバグが発生することは確認できている。


GPoxますます凶悪になってます。2、3日放置すると外部からのReferが多いとリネームしてます。
でこないだは、どこから持ってきたか知らないが古いデータで捏造を生成してくれました。
こんな豪華な意地悪機能を稼動させるくらいなら、さっさとアカ削除でもすりゃいいのに。
毎日更新するなら大丈夫なんだけどね。長期公開に向かない。
新しい移転先を探しているけどないんだよね。分割して公開すればいいだけの話だけど
分割すればしたでそのまま流す人もいるだろうし、そういうのが何となく気分的に嫌なので分割したくないのでした。

-->