14/05/20 03:58:15.26 XZ8PbsoH
いつのまにか Vidalia 単体のダウンロードができなくなった‥
ブラウザででしか使用できない‥
165:デフォルトの名無しさん
14/05/20 06:54:05.58 gZsncm2t
素人には危険だからかな
166:デフォルトの名無しさん
14/05/20 10:24:43.89 PJc6Nn45
URLﾘﾝｸ(github.com)
これまんま掲示板に転用できないか？
167:461 ◆Of8OpFdQADOA
14/05/24 18:37:39.78 OAvaL96R
開発者向けの話題を提供しましょう。
ノード間のメッセージングにはTCPかUDPを使われるかと思いますが、皆さんならプロトコルをどう設計しますか？
バイナリで組む人もおられるでしょうし、HTTP風にテキストベースで書く人もおられると思うのですが、皆さんの知恵を聞かせてください。
168:デフォルトの名無しさん
14/05/24 19:40:20.45 uWBH7T6t
そんなのどっちでもよい
169:デフォルトの名無しさん
14/05/24 19:59:57.61 jYoMAPG8
>>167
こっちでは今PDですら遮断される状況だから偽装してほしいな
170:デフォルトの名無しさん
14/05/24 20:32:26.64 7m1F5+NU
今迄のは開発者の話題ではないと思ってたのか。なんかこいつにイラっとくるのってオレだけかな
171:デフォルトの名無しさん
14/05/24 20:33:42.07 9qFFfmjf
>>170
アスペかよ
172:デフォルトの名無しさん
14/05/24 20:35:25.26 8L8QZ0Si
>>167
扱いやすいしバイナリ一択だな
173:デフォルトの名無しさん
14/05/24 20:44:07.64 uWBH7T6t
そんなのどうでもいいって言った理由は、
バイナリかテキストかによってアプリの機能や
開発しやすさになんら影響をあたえることがないから。
プロトコルをオープンにしてだれでもあつえるようにするなら
テキストのほうがやりやすいだろうし、逆に解析をしづらくしたいのなら
バイナリのほうがいいだろう。程度の意味しかない。
アプリからすれば、そんなプロトコルの違いは、下層のレイヤーが
吸収してオブジェクトの形にするから、どっちでも同じだし、
あとから変えることだって簡単。プロトコルの命令の種類の話しならともかく。
テキストかバイナリかという表現形式なんか、どうでもいい。
174:デフォルトの名無しさん
14/05/24 21:07:02.75 8L8QZ0Si
機能面ではそうだが、テキストはパースにも構築にも、バイナリに比べて数十倍数百倍の時間が掛かるからなぁ
比較とかもバイナリの方が簡単だし
175:デフォルトの名無しさん
14/05/24 21:13:01.28 uWBH7T6t
それは全体の1%にも満たない部分だから
時間がかかっても問題ない。
176:デフォルトの名無しさん
14/05/24 21:15:21.89 oWuOT6f1
どうでもいいことに拘ってないで、まずは要件定義をしろｗ
177:デフォルトの名無しさん
14/05/24 22:08:44.78 7CvGDBUR
>>167
UDPで経路毎の最大パケットサイズ調べたりメッセージ分割したり結合したり、絶対ダルいからUDPは嫌だな
バイナリで組むかテキストで組むかは趣味の領域な気もするけど…
単一接続で長いメッセージを含む複数のメッセージを送る場合はテキストだと無駄が多い気がする
ていうかそれ以前に遮断の防止などでSSLなどに偽装したコネクション張る事から考える
178:デフォルトの名無しさん
14/05/24 22:48:03.61 oWuOT6f1
要素技術なんぞ詳細設計の段階の話だろうがｗ
まずは要件定義しろｗ
179:デフォルトの名無しさん
14/05/24 23:07:23.72 rfdD6r00
Unicodeをデフォルトにしようず。
UTF-8が無難だが日本的にはUTF-32にも惹かれる
180:Unicodeキボンヌ
14/05/25 00:00:09.81 wqNjSVko
書込時の匿名性はP2Pによって実現するといっても、
閲覧時にP2Pは不要（cf.新月ネットワークの場合は閲覧用にもP2Pを利用する）。
サーバーは有志の運営に委ねる（中央集権的管理の完全否定）。
運営者は現在の2ちゃんねるの過去ログ転載サイトのように、広告収益などを目当てにネットワーク資源を提供すればよい。
サーバーのログ上の特定の書き込みを、何らかの問題発生時に、削除するかしないかは各サーバー管理者の判断による。
サーバー間の信頼関係システムも設け、専門外の板については、他サーバーのログをそのまま信用してクローンする。
理想的にはスレ毎に、スレ立て人自身が管理者となって、サーバーを立てているような状態。
ちゃんと管理されているスレは繁栄することが期待できる。
一般ユーザーの書き込みの匿名性は、P2Pによって、ユーザー同士の端末を一定HOP経由してから、サーバーへの書き込みがされるようにする。
サーバー同士の書き込みの伝播にまでP2Pを適用するかどうかは、確保したい匿名性のレベルの議論による。
181:デフォルトの名無しさん
14/05/25 02:30:20.38 UOeAOsx2
>180
つまり、一番最初に見た人が、
一番最初に書き込んだ人である確率が極めて高い
ってことでいいですか？ｗ
182:Unicodeキボンヌ
14/05/25 04:05:32.41 wqNjSVko
意味不明。
サーバーに反映されないと誰も見れないのに、なぜそうなるの？
183:デフォルトの名無しさん
14/05/25 04:51:54.21 dtutVys2
>>180
匿名化対象は、投稿者→匿名、配信者→公開、閲覧者→公開、だと仮定して、
その構造でサーバ間を暗号化する目的がよく分からんのだが…
サーバの持ってる前データはオープンで、サーバにデータを投稿した人間は不明でしょ？
サーバ間での同期は複製元も複製先もオープンで、匿名化すべき部分が見当たらないのだけど。
それとも匿名化対象が、投稿者→匿名、配信者→公開、閲覧者→匿名、であり、
複製先サーバがオープンな配信者として動作しない、読み専の閲覧者である場合も含むってこと？
>>182
閲覧に関して普通の専ブラと同じ方式をとった場合は、
投稿者は書き込み直後にそのスレの更新動作をする。
この動作は他の閲覧者の自動更新や手動更新よりも先行する可能性が非常に高い。
プッシュ配信でもしてしまって投稿者閲覧者問わずに更新させるか、
閲覧に関してもオニオンルーティングするかしないと隠蔽できない。
プッシュ配信だと閲覧者数が少ない場合に投稿者がバレてしまうので、
閲覧者数が少ないスレッドでは匿名読み込みに切り替えないと不味い、かな。
184:デフォルトの名無しさん
14/05/25 05:24:34.63 NeNyrW9A
>>180
それは ny で失敗したはず
IP -> ID 識別は、ID の寿命を長くするとレインボーテーブルで一網打尽は前のスレでも散々
トリップ‥‥どうだろうか？