次期P2Pの仕様 part8

>>861もテンプレに入れましょう

>>861
中継における転送速度の低下って、どれぐらい出てくるのかよくわからんのよね。

さてさて、結構前に開発宣言した者です。
あれからいろいろ考えて、いくつか思ったので...

DL したらこれを再びキャッシュにして落としやすさを上げる。としたけれど、
ネットワーク全体でみたときのキャッシュ容量はどんどん膨れ上がることになり、
いつか飽和するんじゃないかと思って、結構悩んでいます。
落として一ヶ月たったキャッシュは消す、とかどうでしょうか。

あと、クラスタ化の、"キーワードが近い" ってどうやって判定するんでしょう？
あんまりシビアだとつながらないし、緩いと関係ないものがつながってきて……

ところで、UNIX 対応にしてほしい人って居ます？
いるなら GTK+ で開発しようかなどと思っています。

( だれが次スレを立てるんだろう… )

> ネットワーク全体でみたときのキャッシュ容量はどんどん膨れ上がることになり、
> いつか飽和するんじゃないかと思って、結構悩んでいます。
> 落として一ヶ月たったキャッシュは消す、とかどうでしょうか。
一ヶ月でも十分容量が膨れそうな気がする。ユーザが上限を決められるのがいいな。
キャッシュが多いほど落としやすい仕組みが理想だけど、オープンソースだと難しいかなあ・・・。
いずれにせよ、勝手に容量を圧迫する＆キャッシュを持っていてもメリットがないという条件が揃うと
キャッシュ全消し厨が増える予感。

> あと、クラスタ化の、"キーワードが近い" ってどうやって判定するんでしょう？
> あんまりシビアだとつながらないし、緩いと関係ないものがつながってきて……
nyは部分一致チェックもしてたみたいだけど、個人的には完全一致でもいいような気がする。
ユーザがちゃんと大分類・中分類・小分類といった感じで入れるなら問題ないかと。
部分一致で行くのなら、アルゴリズムの検討を手伝いたいと思うのでレスください。

> ところで、UNIX 対応にしてほしい人って居ます？
> いるなら GTK+ で開発しようかなどと思っています。
個人的には UNIX 対応欲しいけど、それ以上に Win に入れるときに別なものインスコするのが面倒い。

> ( だれが次スレを立てるんだろう… )
950踏んだ人。

>>929
> DL したらこれを再びキャッシュにして落としやすさを上げる。
これが良く分からないんですが、具体的にはどう落としやすくなるんでしょうか？
XOR方式ならキャッシュしないでそのまま転送した方が効率がいい気がするんですが…

>>931
ひとりしかキャッシュがないと、アクセスが集中して順番待ちが起きる。
その人がつないでない時間帯には落とせない。

>>932
あぁ、いやそういうことではなくてXOR分割したファイルをそのままコピーしただけじゃダメなんですか？
という意味です。
キャッシュという別のファイルに変換をするのかと思ったもので
言葉足らずですみません

>>930
> 一ヶ月でも十分容量が膨れそうな気がする。ユーザが上限を決められるのがいいな。
なるほど、上限は自分で決めれるようにしたほうがよさそうですね。
キャッシュのサイズとかでも指定できればなおよさそうですね。

> キャッシュが多いほど落としやすい仕組みが理想だけど、オープンソースだと難しいかなあ・・・。
逆にキャッシュが少ないと損をする仕組みの方が考えやすいかも…
クライアントの自己申告はあてに出来ないので、たとえば
クライアントA がリクエスト送信、クライアントB はそれをもっているとして、
B は流れてるキーから適当にハッシュを何個か集めてそれを逆に
A に向けてリクエスト。双方向ともいくつか中継した上で交換にしてやれば、
キャッシュ拡散にもなっていいかなぁ…とか。今度は偽造が増えるか…

> nyは部分一致チェックもしてたみたいだけど、個人的には完全一致でもいいような気がする。
> ユーザがちゃんと大分類・中分類・小分類といった感じで入れるなら問題ないかと。
> 部分一致で行くのなら、アルゴリズムの検討を手伝いたいと思うのでレスください。
完全一致だと、"【合法】" というキーワードと "『合法』" が別になってしまいますし、
揺らぐのは括弧だけとも限らないので、よさそうなアルゴリズムを探しています。
完全一致にして、ユーザー側でどうにかしてもらおうというのもアリでしょうけどね。

> 個人的には UNIX 対応欲しいけど、それ以上に Win に入れるときに別なものインスコするのが面倒い。
GTK+ は LGPL なので、コンパイル済みWin32バイナリを同梱するのは可能だったと思います。
記憶違いだったらすいません…

>>931-933
１つの生データを生成するために二つのキャッシュファイルが必要になるため、
"片方しか手に入らない" という事態も充分にありうるので、生データをもう一回
今度は別の無作為データで XOR 化します。
ただ、あんまり種類が増えすぎても問題なので、乱数で確率的にやろうと。
もしくは「落としやすさを上げるためにUPしなおしますか？」とか聞いてみるとか。

>>934
なるほど、nyで言う完全キャッシュと部分キャッシュの関係と少し似てますね。(部分キャッシュは正確には違いますけど)
ただ、nyとの差別化を図るためにも完全に部分キャッシュでやる方法はないものかなとか思ってしまいます…。
完全キャッシュがあるとXORを使う意味がなくなってしまうんじゃないかなぁと

>>934
> 完全一致だと、"【合法】" というキーワードと "『合法』" が別になってしまいますし、
> 揺らぐのは括弧だけとも限らないので、よさそうなアルゴリズムを探しています。
ny はむかしクラスタワードがファイル名とも比較されるようになっていたので、
括弧が使われているのはその名残りでしょう。個人的にはユーザ側が合わせればいいと思います。

いちおう、部分一致チェックの方法を提案しておきます。こんなのはいかがでしょう。

まずクラスタワードを前処理して、連続文字リストを作ります。
クラスタワードは16bit文字(wchar)配列 cluster_word[] に格納されているとして、

typedef pair<wchar,wchar> wpair;
set<wpair> list;
for(wchar *pt=cluster_word; pt[1]!='\0'; ++pt) {
list.insert( wpair(pt[0],pt[1]) );
}

この連続文字リスト同士を比較して、優先度 point を算出します。

int point=0;
for(set<wpair>::iterator itr=list1.begin(); itr!=list1.end(); ++itr){
if( list2.find(*itr)!=list2.end() ) {
++point;
}
}

連続する２文字のペアのリストを作っておき、両者に含まれている連続文字の数を
数える方式です。

>GTK+ は LGPL なので、コンパイル済みWin32バイナリを同梱するのは可能だったと思います。
あ、そんなら問題ないですね。UNIX対応希望です。

うわっ、インデントが消えてしまった。サンプルコードが見づらいのはご容赦を・・・

>>934
１ヵ月後とか期間じゃなくて、ダウンロードされた回数で判断したら？
増える時はねずみ算式で倍増するから、
前の日は全然落とせなかったのに、次の日は楽々３重ダウンロードとかよくあるよ。
皆が同じファイル持ってても無駄なだけだし、
逆に回転が遅いファイルは、１ヵ月じゃ全然足りないだろうね。

でも連続ダウンロードされたらまずいから、
検索して自分以外にキャッシュが存在するのを確認した方がよいかも。

あと回線速度と接続時間も考慮してほしい。
回線速度ｘ接続時間が大きい人は、サイズの大きいファイルを残す。
回線速度ｘ接続時間が小さい人は、サイズの小さいファイルを残す。

>>935
完全キャッシュは持ちませんよ。すべてXORデータのみが流通します。
ほしい人はリストどおりのXORデータを集めて、複合化して結合します。

>>936
なるほど…そういう判定法があったのか……
どちらのキーワードを for ループにかけるかで点数が違いますね。
長いほうを for にかける、とか統一したほうがいいかもしれないですね。
そういえば文字コードはどうしよう… wchar に統一でいいかなぁ…

>>938
キャッシュファイルに参照された回数を記録すれば実現可能ですね。
日付やサイズで切るより効率が良いかもしれないと思います。

> でも連続ダウンロードされたらまずいから、
> 検索して自分以外にキャッシュが存在するのを確認した方がよいかも。
リクエストパケットから、相手がほしがっているファイルは割り出せないように
しているので、それは無理です。中継もしていることだし、毎回経路を変えれば充分かと。

> あと回線速度と接続時間も考慮してほしい。
これは 実効帯域 と 平均接続時間 と読み替えさせてもらいます。
大きいファイルを小数 or 小さいファイルを多数 といったところでしょうか。

>>939
>どちらのキーワードを for ループにかけるかで点数が違いますね。
>長いほうを for にかける、とか統一したほうがいいかもしれないですね。
そうですね、ご指摘の通りです。
上記のサンプルコードは簡易版です。ソート済みリストを使ったより効率的なアルゴリズムがあります。
こちらはどちらをループにかけるかで結果が違うような問題は出ません。
釈迦に説法になりそうですが、もし必要でしたらまとめておきます。

>>どちらのキーワードを for ループにかけるかで点数が違いますね。
>>長いほうを for にかける、とか統一したほうがいいかもしれないですね。
>そうですね、ご指摘の通りです。
あ、ウソ、どっちをforループにかけても得点は同じになります。
いずれにせよ、実装するときはソート済みリストの方が効率いいです。

どうでも良いけど、まず一通り動くのを作ってくれ。

>>942
仕様はおろそかでもいいから、とりあえず動くものが欲しい。そんなあなたに。
http://tmp2.2ch.net/test/read.cgi/download/1074979399/

>>939
>そういえば文字コードはどうしよう… wchar に統一でいいかなぁ…
UNIX対応も考えるなら、内部は16bitで統一しちゃうのが簡単でよろし。
通信時は、文字列は固定ハフマンで圧縮して送るのがいいかな。
最初からそこまでやるのも大変なので、圧縮に対応するのは後々のバージョンアップの時で。
それはともあれ、821さん期待してますよ〜

Wiki に、クラスタワード類似度評価法についてのページをアップさせていただきました。

特に誰からリクエストされたわけでもありませんが(w 説明に不足な部分が多かったこと、
他の共有ソフトの開発にも有用であると（自分的に）思われることからページを用意しました。

この方法を応用すると、簡易で高速なファイル名のあいまい検索も実現できます。
Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。

あまりネットワークの検索法について議論されてないような気がするんだけどWinnyと同じと考えていいのかなあ？
これ素直に読めばキャッシュの暗号強度以前に検索情報がだだ漏れしてるようにしか思えないんだけど…
ttp://internet.watch.impress.co.jp/static/column/jiken/2004/01/07/index.htm
完全共有はネタとしても、検索情報を拡散しないダミーファイルシステムは一考願いたし。

検索情報が漏れて何が悪い

とーとつですが、通信をＩＰ電話の様に偽装できんもんかね？

ＩＰ電話って標準のプロトコル規定されてたっけか？

それはともかく、どこのプロバイダも無料ＩＰ電話をサポートすれば、
ＩＰ電話上のアナログモデム通信で完全な匿名性が実現できるな。

IP電話は単なるUDP。

>>949
それだ！

規約に「長電話禁止」が出来たりして

>>950
次スレよろ。

>>944
> UNIX対応も考えるなら、内部は16bitで統一しちゃうのが簡単でよろし。
ふと思い立って、調べてみました。Win で mbstowcs() やると UTF-16BE になるのに、
FreeBSD 4.8 だとコード変換せずに wchar_t のサイズに調整されただけでした……
UNIX の時だけ libiconv を使って UTF-16BE に統一することにします。
( 微妙に実装が違うのか…組み合わせたこと無いから気づかなかったよ... )

>>945
> Wiki に、クラスタワード類似度評価法についてのページをアップさせていただきました。
おつかれさまです。とても参考になります。
> Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
> ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。
ではお願いさせてもらってよろしいでしょうか。
こちらとしてはものすごくありがたいです。よろしくお願いします。

こちらでは、Win/UNIXの細かい差異を吸収するソケットライブラリを作り始めました。
帯域制限もこのレベルに組み込もうと目論んでいます。需要があるならこの
ライブラリ単体での提供もしましょうか、などと発言してみる…

あ。書いてたら950レス超えた。次スレお願いしますねー。>>950

ホスト規制でスレ立て出来ませんでした。
どなたかお願いします。

私もホスト規制で立てれなかった・・・。

>>953
> > Wiki の方にも書いてありますが、クラスタワード類似度評価、およびあいまい検索のための
> > ライブラリを提供する意思があります。共有ソフト開発者の方、ぜひご検討ください。
>ではお願いさせてもらってよろしいでしょうか。
ありがとうございます、では用意しておきますね。
日本語はSJIS前提で大丈夫でしょうか？　すでに日本語コードについては準備を進められている
ようなので、wchar を受け付ける形式の方がいいのかなと考えています。それなら EUC でもOKなので。

> こちらでは、Win/UNIXの細かい差異を吸収するソケットライブラリを作り始めました。
それは需要あるんではないでしょうか。
個人的にも欲しい・・・つっても、共有ソフト作るわけではないんですが(ぉ

今の時点で、プロジェクトが具体的に動き出してるのって、
新月とShare!だけかな？

このスレ出身26氏のCauserie Alphaが抜けてるってば

>>957
alphaに低能な荒らし発生中w

alphaって久しぶりにバージョンしてみたんだがラジオなんて機能がついてた。
26氏って興味が移り変わっていって迷走気味な印象を受ける。
このスレから誕生したくせに肝心のファイル共有機能を実装してないし。
荒らされるのもわかるよ。

>>959
P2Pってファイル共有だけを指すんだねｗ

>>953
Windowsしか知らない人は勘違いしがちですが
wchar_t == Unicodeではありません。中身は何でもいいのです。

>>959
26氏って前スレで

> 26 名前：前スレ843[sage] 投稿日：03/12/06 21:05 UuWDxw0l
> 前スレの671が言っていたようなP2P掲示板を作りたくなったのだが、
> 需要ってあるか？
（後略）

と言ってたわけで、ファイル共有ソフトを作ると言って開発を始めたんじゃないしなあ。

ｎｙやMXもあるし俺はむしろファイル共有付いてなくてもいいとも思ったりするし。
しかしやり方が閉鎖的過ぎるのがどうかと思うな。

掲示板に関しては雑誌厨も積極的に取り込んで行かないと成長が止まると思うんだが、
26氏はそうした理屈とは無関係の単純な嫌悪感で排除しようとしてる気がする。

>>963
別に取り込んでるし。着々と増えてるよ。
色々なところからね・・・。

>>959>>963
なるほど、お前か

最近接続が不安定だし、雑誌厨の投入はもう少し後がいいかな。
荒らし対策もあるしね。

>>966
２系統は安定してた・・・

そこに嵐が来たって感じ。
かなり改善してたよ。

せっかくny2b6.6の逆アセソースが公開されてるんだから、winny互換にして欲しい。
ここで出た仕様をまとめたオープンソースny3を期待……


漏れがやれって？
漏れはsrc2の中身見てもサッパリだったので、あきらめますた。

>>968
互換ってWinny2と接続できるように、ってか？
それは無理じゃないか？

>>969
可能だろ。
ソース出てるんだから。
ただあの状態じゃリンクすらできないからなぁ・・・

今日の読売にちょっと出てたけど、
プロバイダに対するP2P通信の
隠蔽（？）の方法もよろ。。。

>>967
掲示板部分はα1から変わってないよ。
αで改善したのはラジオだけ

つーかシステム的には最初のバージョンからほとんど変わってない気がする。
根本を改良せずに、機能追加しまくったのがまずかったんだろなぁ

>>970
ここで出た仕様を使うとなると難しいんじゃないか？

Winny2と接続ってのはできてもあまり意味がないような。
このスレで出てるような仕様を色々載せるとなると実用的な互換は難しくない？
そうじゃなくて、キャッシュを流用できればny1・2ユーザーを丸ごと取り込めるんじゃないかと。
(実際には丸ごとなんて無理だろうけど)

src2の中身があれば、
正確にはソースを整形してオープンソース用に見やすくすれば、可能だと思う。

あ、かぶってた。

……やっぱアレはクラッカーとコレクターにしか意味がないものなのかな。
47氏の遺志を継いで闘う、という錦の御旗になりそうなんだが。

(´-`).｡oO(実は、“winnyのソースから作られた「オープンソースP2P」”という触れ込みに惹かれてるだけかもしんない)

Winnyと互換を取るということは最大の弱点であった｢作者がいないと何もできない｣を克服できないかと。
Winnyでオープンソースにという話は出ていて、47氏もできるならそうしたかったと言っていた。
だが現在出ているオープンソースでも可能なシステムは、どれも互換を取れそうな仕様ではないので、
ソースが出たところで参考にする以外には使い道がないのでは。