２ちゃんねる互換P2P匿名掲示板の実装を考える１

**デフォルトの名無しさん** · 2014/04/23(水) 23:29:44.09

このスレは「P2P型の完全匿名掲示板はまだ出来ないの？」スレからforkして生まれました
2ちゃんの代替となる2ちゃん型掲示板をP2Pで実装してみようぜ、なスレです
名前が長いので若干スレタイは変えましたファイル共有ソフト等の話題はスレ違いなのです

origin：P2P型の完全匿名掲示板はまだ出来ないの？その4
http://toro.2ch.net/test/read.cgi/tech/1390486453/

wiki
http://www34.atwiki.jp/p2p-anon/

[参考]

Tor（The Onion Router）のHidden Service(onionドメイン)Onionちゃんねる
http://xiwayy2kn32bo3ko.onion/ (Tor経由でのみアクセス可能)
Syndie - distributed forums
http://syndie.i2p2.de/
Freenet - P2Pコミュニケーションフレームワーク
https://freenetproject.org/

[関連するP2P掲示板ソフトウェア等]

新月 - P2P匿名掲示板
http://shingetsu.info/index.ja
P2P2ch
http://p2p2ch.web.fc2.com/
ちらしの裏
http://chiraura0.web.fc2.com/
alias
https://code.google.com/p/alias/
o2on
https://github.com/o2on/o2on

**デフォルトの名無しさん** · 2014/05/03(土) 19:45:46.73

>>79
利用者減ってるのか。
運営のせいか、時代の流れなのか。

**デフォルトの名無しさん** · 2014/05/03(土) 21:15:21.72

江崎浩のP2P教科書を斜め読みしてると、P2Pの既存実装、ツールキット、テスト環境があることがわかった
（既存実装は自明だけど・・・）つまり誰かが車輪を作りまくって置いてることになる

【BambooDHT】
http://bamboo-dht.org/

分散ハッシュテーブルの研究で作られたソフトウェア、安心と信頼のMIT製

【OverlayWeaver】
http://overlayweaver.sourceforge.net/index-j.html

オーバーレイネットワークアプリを３層に分けて、それぞれ差し替え可能にしている開発ツールキット
階層０：ルーティング（Chord, Pastry, Kademlia...)
階層１：高レベルサービス（DHTとか）
階層２：アプリ

これはどの程度使えるのだろうか・・・

【PIAX】
どちらかというと車載機器や携帯機器への実装を目指してるプロジェクト？
低レイヤな部分でlibjingleとか使ってるっぽい
阪大製

**デフォルトの名無しさん** · 2014/05/03(土) 21:18:42.74

OverlayWeaverはP2Pで通信するアプリケーションを”オーバレイ”ってひとくくりにしてるぐらいだから
なかなかすごいプロジェクトかもしれんね、ゲーム開発ツールキットで言えばUnityみたいなもんかな

**デフォルトの名無しさん** · 2014/05/03(土) 21:33:59.64

知ってるからいちいち紹介しなくていいよ

**デフォルトの名無しさん** · 2014/05/03(土) 21:51:27.46

使ったことないけど新月はなにがいけないの？
自分的にはp2pにこだわりすぎてるからじゃないかと思うけど
これをサーバーからでも閲覧や書き込みしやすいようにすりゃいいんじゃ？

**デフォルトの名無しさん** · 2014/05/03(土) 22:10:59.90

>>84
別にお前個人に教えてやろうと思って書いてるわけじゃないだろ。

**デフォルトの名無しさん** · 2014/05/04(日) 00:26:00.32

>>65
DNSの浸透、のほうがいいかもしれないよ
DHT の場合データが取得できない場合がある、所持しているノードが起動していなくてね
ファイル共有の場合は、そのノードが参加するのを待てばよいが、掲示板の場合はどうかな？

>>64
chord 調査中です。

**デフォルトの名無しさん** · 2014/05/04(日) 05:20:21.25

>>85
P2Pというのはサーバ兼クライアントなんだから、こだわりすぎというのは意味不明。

過去ログ読まない貴方には向かないかもしれないけれど、
大事な事でも一度書かれれば充分な>>84なんかには新月も悪くないだろう。

**デフォルトの名無しさん** · 2014/05/06(火) 04:29:26.74

>>87
DNSの浸透は設定ミスでTTLが延長される等のクソ環境の言い訳だし(故に浸透言う業者は無能な可能性が高い)、
そんな「データの伝達経路がぶっ壊れてるけど運がよけりゃデータ読める」状態を意図的に作ってどうすんだって。
DHTでは最悪のケースとしてデータ所有ノードが全て断線しても「ファイル共有の場合」の状態を再現できるし、
通常の場合は断線するノードが出たり明示的に切断する場合に複製数増やして最低データ保持ノード数を確保するだけ。

**デフォルトの名無しさん** · 2014/05/06(火) 07:28:02.05

大抵のDHTアルゴリズムには、特定のノードが退出してもそのノードの担当範囲のデータが消えないようにする仕組みがあるよ

**デフォルトの名無しさん** · 2014/05/06(火) 10:12:26.17

>>90
＞特定のノードが退出してもそのノードの担当範囲のデータが消えない
詳しく

投稿単位AのハッシュH の結果H(A)でノードBを特定し，そのノードBが実際に投稿単位を持っているノードCを保持しているんだね (Chord)
じゃ，特定のノードBが前触れも無くいきなり退出（P2Pではよくあること）した場合は， C のことを知っているノードはいなくなるのでは？

**デフォルトの名無しさん** · 2014/05/06(火) 13:05:02.81

まず、DHTでは基本的にデータを複製していく点に留意。
>>91の例の場合、ノードCからノードBへ投稿Aそのものがコピーされる。
どのノードが持っているか、という情報を転送していくのはWinny方式だから勘違いせぬよう。

**デフォルトの名無しさん** · 2014/05/06(火) 13:39:18.25

DHT上に保存したいデータをA、そのデータのハッシュ値をH(A)、Aを担当するノードをNとする。
取り敢えず、自分の知ってるChordとKademliaってアルゴリズムを例にする。

Chordの場合、Nはその前(ノードID的に)のノードN'、N''、…へAを複製する。
円状のネットワークを構成するアルゴリズムだから、Nが抜けると(例えば)N'が次のNになるので、Aは消えない。

Kademliaの場合、Nに近い幾つかのノード(N自体が入っているとは限らない)へAをばら撒く。
各ノードは、定期的に自分の持つデータをNに近い幾つかのノードへばら撒く。
Aを取得する時も、Nに近い幾つかのノードにリクエストを送る。
データはひたすら複製されていくから、いずれかのノードが抜けても問題ないワケ。
円状のきれいなネットワークを構築するChordに比べると力技っぽいけど、実装が簡単らしいね。

◆Ky/cs3er/I · 2014/05/06(火) 18:07:43.97

>>91 >>92
どちらの実装もあり得る。
大きいデータとかファイル共有だったらDHTの担当ノードに直接データを持たせるということはしないだろう。
掲示板のデータはそれほど大きくないし、新しいレスが素早く反映される必要があるから
担当ノードが直接保持するべきだろう。

**デフォルトの名無しさん** · 2014/05/06(火) 18:25:11.36

まじかよ
コンテンツをDHTに直接入れてる実装って現時点で存在するのか？
おれは知らん

**デフォルトの名無しさん** · 2014/05/06(火) 18:32:09.33

>>93
なるほど、ハッシュ＝ノードID のサイズが 160ビットならば、ノードIDをローテートして生成されるノードID群で持ち合うんだね
あとはノードIDの決め方だけれども

**461** ◆Of8OpFdQADOA · 2014/05/06(火) 18:52:44.17

DHTに直接データを置くのではなく、一旦メタデータを置く事が主流であるようですが、間接配置（他に正確な呼び名があるならそう読み替えてください）のメリットは何でしょうか。
私には大きなファイルの分割による負荷分散ぐらいしか思いつきませんが、他に何か応用があるのかな？

**デフォルトの名無しさん** · 2014/05/06(火) 19:04:51.40

というか直接配置の実例があるなら提示していただきたい
参考にするから

**461** ◆Of8OpFdQADOA · 2014/05/06(火) 19:05:21.89

あ、いま思い浮かびました。連投をお許しください。
荒らしがいるとします。彼は大量の無意味な投稿をするのですが、これを直接DHTに配置すると多大なネットワーク負荷が発生します。
間接的にアドレスだけを配置し実体を投稿したノードに持たせれば、無駄な負荷を発生させずに済みます。
ただ投稿ノードが抜ける時に結局データの移動が起きてしまいますが。

**デフォルトの名無しさん** · 2014/05/06(火) 19:36:34.06

だめだこりゃ。ちゃんちゃん。

**P.Yumina** ◆Ky/cs3er/I · 2014/05/06(火) 20:29:15.99

>>97
P2Pはノードの出入りが激しいから
DHTで大きいデータを直接配置すると
出入りの度に大量のデータ転送が必要になるからとても非効率

ファイル共有だとファイルをダウンロードするノードとDHTの担当ノードは
異なるのが普通だから、間接配置にならざるを得ない。

>>98
CREAの掲示板はDHTの担当ノードが管理する方式だったから
担当ノードが直接保持していた。
ちなみに、動画ファイルはもちろん間接配置だった。

**デフォルトの名無しさん** · 2014/05/06(火) 20:51:39.18

ここは帯域の無駄でしか無い中継をやらない
まともなP2Pスレってことでいいの？

**デフォルトの名無しさん** · 2014/05/06(火) 20:55:23.86

>>101
実装できるんだ
パフォーマンスはどんな感じなんだろう

**P.Yumina** ◆Ky/cs3er/I · 2014/05/06(火) 21:19:26.66

>>103
それが作った自分も分かってないんだよｗｗｗ
そもそも自分がP2Pを作ったのってP2Pシステムのテストをしたかったっていう
個人的な理由があったからなんだけど（その他にも色々理由はあったけど）、
P2P掲示板を作っても誰も使ってくれないから全くデータが取れなかったｗ
で、動画共有機能を追加したら多少はノードが増えると思っていたんだが
それでも全然増えなくて、これはいったん止めにするしかないわ、となった。

そんな訳で、直接配置でどれくらいパフォーマンスが出るのかはよく分からない。
ただ、10ノード程度で動いていたときはDHT絡みで特に問題はなかったと思う
（繋がらないノードの扱いには結構苦労した記憶があるけど）。

**デフォルトの名無しさん** · 2014/05/06(火) 21:25:59.34

インフラが整ってきたせいで
P2Pの必要性が減ってきてしまったからね。

動画配信はP2Pの出番のように
考えられていた時期もあったけど、
今や個人が無料で配信できてしまう時代。

P2Pよりも優れていて、すぐに再生できる
アップ者はアップが終わったらネットに繋がなくていいといった
メリットもある。この点でP2Pを超えてしまっている。

**デフォルトの名無しさん** · 2014/05/06(火) 22:17:05.56

作るやつがいないものをいくら議論したって無駄だろ。

**デフォルトの名無しさん** · 2014/05/07(水) 01:17:20.12

>>104
なるほど
でも使える可能性があるわけだね
これは光明か

多分人が集まらなかったのはプラットフォームの限定と広報不足では

個人的にBitTorrent Liveの実装が早く見たい

**デフォルトの名無しさん** · 2014/05/07(水) 02:19:06.09

CREAのひとだったのか

匿名にするなら実データをバケツリレーでポストしないと誰が書いたかバレバレになるよ

**デフォルトの名無しさん** · 2014/05/07(水) 06:03:42.93

匿名にする必要ないだろ。

**デフォルトの名無しさん** · 2014/05/07(水) 18:11:42.50

>>38
golangみたいな今日明日にでも消えそうな言語で開発とかｗｗ

**デフォルトの名無しさん** · 2014/05/07(水) 20:37:08.51

goはいい言語だと思うけど「俺がgoで作ってやったったｗｗｗ」ぐらいじゃないと使うことにはならないだろうな

**デフォルトの名無しさん** · 2014/05/08(木) 07:36:21.65

>>95
でかいコンテンツを直接格納するとそのキーを割り当てられた奴が悲惨なことになるから、
格納するデータをメタデータや十分に分割した物する実装じゃないと実用にならないんじゃないの？
>>96
前スレでChordかなんかでの一例は出てたね。クライアントが制御しきれない情報(例:IPアドレス)のハッシュ＋α
>>98
ビットトレントのDHT(Kademliaだっけ？)はトレントファイルを共有してた筈だけど、
トレントファイルをコンテンツとみなせば直接格納には該当しないかな？実装知らんので詳しく分からん。
>>102
匿名化って目的のために帯域を消費して中継してんだから、無駄ではないだろ。
あんまりスマートではないけど、だからって「まともでない」って判断はどーかと。
匿名性が必要か否かは別の議論。

**デフォルトの名無しさん** · 2014/05/08(木) 08:45:43.26

>>112
1キーあたりのデータは例えば1MBみたいな制限を加えるべき。
１キー１掲示板みたいな極端な事をせず、１キー１レスぐらいで設計すべきだね。

**デフォルトの名無しさん** · 2014/05/08(木) 09:12:30.09

>>113
だね。2chのスレッドは1スレッド512kBいかない程度な事も多いから、スレッド単位かレス単位かは悩ましそうだけど…

**デフォルトの名無しさん** · 2014/05/08(木) 09:37:14.61

google app engineの仕様では1キー1MBだから、それに合わせてもいいね。

**デフォルトの名無しさん** · 2014/05/08(木) 09:42:07.96

DHTで掲示板を作る事自体は簡単なんだけど、
問題は、P2Pではピアが信用出来ないので、
改ざん耐性を高める必要があって、どういう設計をすればよいか、なんだよねぇ。

**デフォルトの名無しさん** · 2014/05/08(木) 09:44:19.68

つまり、自分が所有するピアのデータを自分自身で書き換えられないか、
書き換えた事が検出可能な設計にするにはどうすればよいか。

**デフォルトの名無しさん** · 2014/05/08(木) 09:49:16.77

複数のソースをゲットすればいい
別ルートからのデータを比較して同一じゃなければ改ざん認定
正しいのがどれか判別する方法は知らん

**デフォルトの名無しさん** · 2014/05/08(木) 09:50:37.46

データと書いたがハッシュね

**デフォルトの名無しさん** · 2014/05/08(木) 09:54:07.68

確率論的には3つのうち1つだけ違っていたらそれが改ざんとしてしまってもいい

**デフォルトの名無しさん** · 2014/05/08(木) 13:47:43.26

あと、掲示板のレスの順番は正確でなければならないが、
ACID（atomicity, consistency, isolation, durability）をどうやって保証するか。

P2PのDHTでのACID保証について議論したい

**デフォルトの名無しさん** · 2014/05/08(木) 13:52:15.09

>>121
実際の処理はユニークIDで処理して、UIに番号で表示すればよい

**デフォルトの名無しさん** · 2014/05/08(木) 13:54:55.86

P2PでACIDという発想がどこから出てくるのか

**デフォルトの名無しさん** · 2014/05/08(木) 14:12:32.37

>>123
P2Pというか、分散DBの類だからこそACID意識するんじゃないの？

**デフォルトの名無しさん** · 2014/05/08(木) 14:29:26.84

>>122
ユニークなキーを振るのは当然として、
どうやってレス番1の書き込みとレス番2の書き込みの順番がわかるんですか？
書き込み時間にしたって、ピアの時計が正確とは限らないわけだし。

**デフォルトの名無しさん** · 2014/05/08(木) 14:41:08.06

レス1の次に書き込まれたレスは、必ずレス2にならなくてはならない。
これを保証するにはどういう設計にすればよいのだろう。

**デフォルトの名無しさん** · 2014/05/08(木) 14:45:19.56

>>125
別ピアのUIの表示番号が違っていて良い
内部で整合性がとれていれば

めんどくせえ

**デフォルトの名無しさん** · 2014/05/08(木) 14:53:49.00

レスが改竄されないことを前提とすると
レス2にレス1のハッシュ値を添付しなければならないようにすれば
少なくともレス2がレス1より前に存在しなかったことは保証できるな
レスが改竄されない方法は知らんｗ
掲示板のためにproof of workを使うのはコスト高すぎだろうしなー

まあ、多少順番が狂っても別にいいと思うけど

**デフォルトの名無しさん** · 2014/05/08(木) 15:30:16.25

必ず分岐が起こるがその場合どうするのか？
単純にタイムスタンプで同期させると改竄が容易になる。
改竄に対しては多数決で改竄防止という話が出ているが、
そうすれば新規書きこみは全て捨てられることになる

**デフォルトの名無しさん** · 2014/05/08(木) 20:32:46.09

レスの順番なんてどうでもいいだろ
本当に必要な場面になったら、後から安価して順序を説明すりゃいい

**デフォルトの名無しさん** · 2014/05/08(木) 20:42:45.56

順序の制御は無理だろう
>>127 のいうとおりだ、UI に渡すときに整合性が取れていればなんら問題ない、そのためにアンカー先を別途探しにいく実装があってもよい
アンカー先探しをあきらめる条件をどうするか、だね

**デフォルトの名無しさん** · 2014/05/08(木) 21:07:16.40

レス順が変わるのはスレッドが分岐したときの副作用で、この分岐には適切に対処しないと改竄スレッドを流されてしまう穴になる
書きこみを複数のノードに投げて、最新スレッドの取得同期は多数決にすると最新投稿が捨てられる可能性が高くなる

**デフォルトの名無しさん** · 2014/05/08(木) 21:12:09.26

改竄は防げない前提で考えたほうがいいんじゃないの？
された場合にどうするかを考えたほうが現実的な気がする

例えば、他の人とログを比べて改竄されてそうな場所をピックアップする機能とか
改竄してまくってそうなやつをブロックする機能とかあればいいんでない？

**デフォルトの名無しさん** · 2014/05/08(木) 21:16:48.49

内容に不一致があればそれ以降はフォークとみなすしかないんじゃね

**デフォルトの名無しさん** · 2014/05/08(木) 21:23:14.60

ワーキングディレクトリに他のノードからの更新を受けておいて、
そこから手動で自分のログに指定したレスをプルする。
こうすれば常に綺麗な状態は保てるんじゃない？
プル地獄になりそうだけど

**461** ◆Of8OpFdQADOA · 2014/05/08(木) 22:04:50.39

私の実装ではレスごとに固有のIDを与えて内部で自動変換していますね。
見た目が変わらなければどうということはないです。

**デフォルトの名無しさん** · 2014/05/09(金) 09:39:28.91

レス番は投稿情報のハッシュ(仮にレスIDとする)とかにしとくと楽だわな

>>128
レスを識別する情報(レスID)をそのレスの全情報のハッシュにしとけば、
強衝突性を突破しない限り同一レスIDのレスを捏造することは阻止できる。
全コピーの削除はネットワークの規模と複製回数で頑張ればいいし、
不正な投稿(といっても問題なのは未来や過去のタイムスタンプ位か？)さえ防げればいい。
>>129 >>132
直線構造に拘る必要はなくね？ツリーでも一方向メッシュでもそれなりの順序は持つし。
基本は直線で、分岐見つけたら全ての先端のIDを添付して合流させてけばいい。
表示順は原則タイムスタンプ順で、あまりに古いレスID使って伸びた枝は閲覧時に警告を付ける。
本格的にチェックしたいなら信用できるタイムスタンプサーバを借りて部分的にP2Pをやめる。
>>133
プロトコル的な攻撃の話って、攻撃→防御じゃなくてバグ→攻撃の順で考えたほうがいいと思う
というか既存投稿の上書きな改竄は、異なる内容のレスを別のレスとして扱う実装だと無意味になる
元の投稿消したデータ群渡されても、元の投稿を含むデータ群読んで差分を挿入して終わり
元の投稿を持つやつ全員が結託して抹消しない限り、そいつと接触できれば直ぐ復元できる

**デフォルトの名無しさん** · 2014/05/09(金) 11:03:34.80

特定のレスをNGにして、自分ノードではやりとりしないっていう機能も必要だね
薬売買とか個人情報のやりとりあるレスは持ちたくない人いるでしょ

手動でNGに入れるのも面倒だから
つまり共有NGみたいなものが必要になるのか？

**デフォルトの名無しさん** · 2014/05/09(金) 15:06:49.62

>>138
いちいち本文チェックなんてしたらクソ遅くなるわ
キャッシュと同じ扱いでいいだろ

**デフォルトの名無しさん** · 2014/05/09(金) 15:09:17.80

なんつーかツリー型サーバーでしか出てこない様な概念を持ち出してくる奴なんなの？

**デフォルトの名無しさん** · 2014/05/09(金) 18:37:25.91

レス順が変わることの本質はスレッドの分岐で、それをマージするときにノーチェックでやるのか？ってところがポイント
ノーチェックだとレスを自由に増やせると思うけどね

**461** ◆Of8OpFdQADOA · 2014/05/10(土) 02:49:08.11

そもそもどうして投稿をマージして、しかもそらを再送出する必要があるんですか。
その都度自分が表示できるレスを集めて表示すればいいじゃないですか。

**デフォルトの名無しさん** · 2014/05/10(土) 03:10:36.81

>>140
データの最小単位が伝達する経路自体はツリーになるけどそういう話ではなく？
>>141
極端な話ネットワークが二分割されてから結合した場合はマージせざるを得ない。
分岐してマージされたレスは異常状態(ログ破損に近い状態)としてマークしといて、どう処理するかは各自自由とかでよくね？
表示順としてローカルでの取得順かタイムスタンプ順かも選択したい人は居るだろうし。
>>142
この場合のマージはレスにつけるメタ情報から構成されるツリー(チェイン)のマージだから関係ないかと。
スレを意味するブロックにレス番情報がある場合はそれが該当するし、
レス毎に投稿時点での最新レスIDを参照させる場合はそれが該当する。
順序を付ける利点は、不正な投稿時刻を前後のレスの投稿時刻で検証・排除出来る事と、
ネットワークの分断の発生をツリー情報から観測・表示しやすくなることなんかが有ると思う。

**デフォルトの名無しさん** · 2014/05/10(土) 10:02:50.39

総論の話中だが、

要素技術にWebRTCのプラットフォームを使うのはどうだろう？

skyway
http://nttcom.github.io/skyway/

javascriptで開発できるから、web系の人も開発に参加できる。

**デフォルトの名無しさん** · 2014/05/10(土) 10:41:46.80

>>144
SkyWayその物はNTTのクラウドサービスだから、
https://github.com/peers/peerjs-server
辺りを使ってサーバを(あとTURNサポートしてるのでTURNサーバも)提供しなきゃ駄目だけど…
違うサーバにぶら下がるとネットワークが隔絶しちゃうのをどーにかせんと。

**デフォルトの名無しさん** · 2014/05/10(土) 11:17:44.29

課題はあるけど、WEB系の技術を使うことができれば、
通常のWEB通信に紛れてプロバイダの方でブロックしにくい。
（暗号化すれば内容によるブロックもできない）

**デフォルトの名無しさん** · 2014/05/10(土) 12:15:33.26

ほう、それでWEB系の技術だけで
暗号化するにはどうしたらいいのかね？

**デフォルトの名無しさん** · 2014/05/10(土) 12:43:23.93

>>147
jsライブラリならいっぱいあるだろ。

**デフォルトの名無しさん** · 2014/05/10(土) 14:43:55.94

>>147
コンテンツボディとして暗号化データ流せば済む話だが、
SSL/TLSを使ったHTTPSっていうプロトコルがあってだね…
ま、コンテンツボディを暗号化する場合だとヘッダ周りで検出されるが。

**デフォルトの名無しさん** · 2014/05/10(土) 14:53:52.12

つまりはWEB系の技術というのは
要するに既存技術をJavaScriptで実装したものって
だけの話だな

**デフォルトの名無しさん** · 2014/05/10(土) 15:18:11.43

WEB系の技術って既存技術の内WEB系の物って意味じゃねーの？
あと「JavaScriptで実装したもの」って制限はどっから出てきたん？

**デフォルトの名無しさん** · 2014/05/10(土) 15:18:41.10

WebRTC使うならOpenPeerがあるってだいぶ前に書いたよな
http://openpeer.org

**デフォルトの名無しさん** · 2014/05/10(土) 17:45:32.03

>>143
普通は新規の書きこみが発生するたびに分岐するんじゃないのかな？
書きこみを受けとったノードが処理をして隣接ノードへの伝達(同期)は分岐処理になるのでは？

それとも新規書きこみは新規書きこみとしてDHTの隣接ノードに伝達されるのか？
この場合は各ノードが独自に新規書きこみの処理を行なうことになるが、分岐が起こらない場合は
その書きこみを所持しているべき全ノードがこの処理を行なうことが前提になると思うが

とても行儀の良い人だけが参加する理想的なネットワークが形成されることが前提になっているのでは？

**デフォルトの名無しさん** · 2014/05/11(日) 09:02:01.38

>>153
投稿を示すデータの塊をデータのハッシュをキーとして伝達すれば何処から何処へ移動しても変質しない
後はデータの塊の中に投稿時点で存在していた既存投稿のキーを含めれば参照関係ツリーは縦に伸びていく
書き込み処理といっても、投稿を示すキーに対する投稿を示すデータの塊がネットワーク上に追加されて、
スレッドを示す情報に順不同でそのスレッドに投稿された投稿のキーが追加されるだけで、この辺りに特殊な処理は必要ない
スレッドを示す情報側は順不同なのでネットワークが接触したら重複除いてマージするだけで良いし、
スレッドの分岐の痕跡や後始末は各投稿データに含まれる既存投稿キーを参照して表示時に解決すればよい

スレッドを示す情報にキーを追加する際は、キーが示すデータを検証してから追加する、とかは必要かな…
行儀に関しては連投DDoSあたりはproof of workとか仮想通貨を導入しないと対策できないんでほどほどでいいかと

**デフォルトの名無しさん** · 2014/05/11(日) 09:41:42.34

え？DDoS？

**デフォルトの名無しさん** · 2014/05/11(日) 10:28:28.25

確定投稿と未確定投稿に分けて考えればいいんだよ。
特にフラグ設けなくてもレス番の有無で判断がつくし。

未確定投稿を２ｃｈ互換で掲示するのは無理なので、外部に掲示されるのは確定投稿になってからで、
拡散された状態で一足先に見ることができるのは参加者の特典でいいんじゃないかと？

**デフォルトの名無しさん** · 2014/05/11(日) 18:29:50.66

>>155
行儀の良くない人がどの程度まで想定するのか分からんかったから
防ぐのが困難なレベルの行儀の悪さを想定したらそうなった
>>156
なんでそんな時間差付ける必要が？…って思ったけど、確定未確定ってレス番の確定か
確定条件によるけど、分断状態でそれぞれが違う内容で確定させたら駄目なような…
あと、ここで言う分断は引き継ぎに失敗しつつ稼働するノード群が入れ違いに休眠した場合とかでも起きる筈

**デフォルトの名無しさん** · 2014/05/18(日) 19:40:42.92

>>48
hidden service の情報が FBI にごっそり抜かれたそうだ、pure でない限り必ず弱点が発生するね
http://www.gizmodo.jp/2013/08/post_12892.html

tor 規制も遠くない

**デフォルトの名無しさん** · 2014/05/19(月) 07:33:43.51

記事の内容読んだか？
>Firefoxの脆弱性を突いてTorユーザーの身元を特定できるカスタムのマルウェアが広まっていたんですね。
FBIがスパイウェア撒いたって話だから、通信形態は関係ない

**デフォルトの名無しさん** · 2014/05/19(月) 17:58:41.42

アノニマスが開発した「AirChat」が凄い！インターネットなしでデータ通信
http://blog.livedoor.jp/itsoku/archives/38902170.html

**デフォルトの名無しさん** · 2014/05/19(月) 21:46:42.22

>>160
読んでないけど、手旗信号と見た

**デフォルトの名無しさん** · 2014/05/19(月) 22:31:10.57

最終的にはインターネットに繋がるらしいが、
「ローカルネットを沢山繋いでインターネット」
って意味で言うと結局インターネットの一部なんだよな。

-- 我々はボーグだ。お前達は同化される。抵抗は無意味だ。

**デフォルトの名無しさん** · 2014/05/19(月) 23:14:38.92

だから、DSの擦れ違い通信だって

**デフォルトの名無しさん** · 2014/05/20(火) 03:58:15.26

いつのまにか Vidalia　単体のダウンロードができなくなった‥
ブラウザででしか使用できない‥

**デフォルトの名無しさん** · 2014/05/20(火) 06:54:05.58

素人には危険だからかな

**デフォルトの名無しさん** · 2014/05/20(火) 10:24:43.89

https://github.com/gitchain/gitchain
これまんま掲示板に転用できないか？

**461** ◆Of8OpFdQADOA · 2014/05/24(土) 18:37:39.78

開発者向けの話題を提供しましょう。
ノード間のメッセージングにはTCPかUDPを使われるかと思いますが、皆さんならプロトコルをどう設計しますか？
バイナリで組む人もおられるでしょうし、HTTP風にテキストベースで書く人もおられると思うのですが、皆さんの知恵を聞かせてください。

**デフォルトの名無しさん** · 2014/05/24(土) 19:40:20.45

そんなのどっちでもよい

**デフォルトの名無しさん** · 2014/05/24(土) 19:59:57.61

>>167
こっちでは今PDですら遮断される状況だから偽装してほしいな

**デフォルトの名無しさん** · 2014/05/24(土) 20:32:26.64

今迄のは開発者の話題ではないと思ってたのか。なんかこいつにイラっとくるのってオレだけかな

**デフォルトの名無しさん** · 2014/05/24(土) 20:33:42.07

>>170
アスペかよ

**デフォルトの名無しさん** · 2014/05/24(土) 20:35:25.26

>>167
扱いやすいしバイナリ一択だな

**デフォルトの名無しさん** · 2014/05/24(土) 20:44:07.64

そんなのどうでもいいって言った理由は、
バイナリかテキストかによってアプリの機能や
開発しやすさになんら影響をあたえることがないから。

プロトコルをオープンにしてだれでもあつえるようにするなら
テキストのほうがやりやすいだろうし、逆に解析をしづらくしたいのなら
バイナリのほうがいいだろう。程度の意味しかない。

アプリからすれば、そんなプロトコルの違いは、下層のレイヤーが
吸収してオブジェクトの形にするから、どっちでも同じだし、
あとから変えることだって簡単。プロトコルの命令の種類の話しならともかく。
テキストかバイナリかという表現形式なんか、どうでもいい。

**デフォルトの名無しさん** · 2014/05/24(土) 21:07:02.75

機能面ではそうだが、テキストはパースにも構築にも、バイナリに比べて数十倍数百倍の時間が掛かるからなぁ
比較とかもバイナリの方が簡単だし

**デフォルトの名無しさん** · 2014/05/24(土) 21:13:01.28

それは全体の1%にも満たない部分だから
時間がかかっても問題ない。

**デフォルトの名無しさん** · 2014/05/24(土) 21:15:21.89

どうでもいいことに拘ってないで、まずは要件定義をしろｗ

**デフォルトの名無しさん** · 2014/05/24(土) 22:08:44.78

>>167
UDPで経路毎の最大パケットサイズ調べたりメッセージ分割したり結合したり、絶対ダルいからUDPは嫌だな
バイナリで組むかテキストで組むかは趣味の領域な気もするけど…
単一接続で長いメッセージを含む複数のメッセージを送る場合はテキストだと無駄が多い気がする
ていうかそれ以前に遮断の防止などでSSLなどに偽装したコネクション張る事から考える

**デフォルトの名無しさん** · 2014/05/24(土) 22:48:03.61

要素技術なんぞ詳細設計の段階の話だろうがｗ
まずは要件定義しろｗ

**デフォルトの名無しさん** · 2014/05/24(土) 23:07:23.72

Unicodeをデフォルトにしようず。
UTF-8が無難だが日本的にはUTF-32にも惹かれる

**Unicodeキボンヌ** · 2014/05/25(日) 00:00:09.81

書込時の匿名性はP2Pによって実現するといっても、
閲覧時にP2Pは不要（cf.新月ネットワークの場合は閲覧用にもP2Pを利用する）。

サーバーは有志の運営に委ねる（中央集権的管理の完全否定）。
運営者は現在の2ちゃんねるの過去ログ転載サイトのように、広告収益などを目当てにネットワーク資源を提供すればよい。

サーバーのログ上の特定の書き込みを、何らかの問題発生時に、削除するかしないかは各サーバー管理者の判断による。
サーバー間の信頼関係システムも設け、専門外の板については、他サーバーのログをそのまま信用してクローンする。
理想的にはスレ毎に、スレ立て人自身が管理者となって、サーバーを立てているような状態。
ちゃんと管理されているスレは繁栄することが期待できる。

一般ユーザーの書き込みの匿名性は、P2Pによって、ユーザー同士の端末を一定HOP経由してから、サーバーへの書き込みがされるようにする。

サーバー同士の書き込みの伝播にまでP2Pを適用するかどうかは、確保したい匿名性のレベルの議論による。

**デフォルトの名無しさん** · 2014/05/25(日) 02:30:20.38

>180
つまり、一番最初に見た人が、
一番最初に書き込んだ人である確率が極めて高い
ってことでいいですか？ｗ

２ちゃんねる互換P2P匿名掲示板の実装を考える １

２ちゃんねる互換P2P匿名掲示板の実装を考える１