アカウント名:
パスワード:
> データが最終目的地に到達することを保証する仕組みだそうだ。口で「保証する」と言うのは簡単だが、実際にやるのは・・・> 仮に二つのLunaNetノード間で障害が発生した場合でも、経路が明確になるまでデータを保存するとしている。「保証する」以上は、つまりこれは宇宙が滅びるかあるいは、相手先が利用可能になるまで「保存する」わけだろう？「保証する」のだから、ディスクが溢れそうだから諦めるということは許されない。
到達不能データの山で破綻するのでは？それとも、技術の発展でディスク容量が増えていくほうが速いとでも？
うまくすれば、空間そのものをメモリに使うことができます。宇宙規模だと相当の情報量が空間に記録できると思います。S/Nが悪くなる前に送り返してもらう必要がありますけど。ええ、空間遅延線メモリです。
プロキシマケンタウリ（距離4.24光年）に鏡を置いてそこに光を反射させてみよう。信号を送ってから戻ってくるまで8.5年。0.1bit/s（10秒で1ビット）の通信レートでデータを送信したとすると、
8.5 * 365 * 24 * 60 * 60 * 0.1 ≒ 2.7Gbit ≒ 340MB
思ったより多くのデータは詰め込めないなあ。
地球とプロキシマケンタウリの間の空間を水銀で満たせばもっと詰め込めるのでは？
銀河ハイウェイの建設予定地の情報を入れるには、十分な容量ですね。
プロキシマケンタウリ側のミラー角度制御精度が保証し切れないなら、ミラーを多少凹凸に歪めて反射光を散らし、投光側を「バベルの光」級の大出力光送信機化する必要があるかも。
> 到達不能データの山で破綻するのでは？
仕様読まずに書いてますが、もしもそれが問題になるほどトラフィックが増えたら古いデータから諦めて消していけばいいだけじゃないでしょうか。現在のTCPだとパケット損失率が一定を越えると通信が詰まってしまって性能劇落ちかコネクションが切れてしまうしラウンドトリップタイムが大きいとどんどん遅くなるしで、別のプロトコルが必要なのは確かでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
「届くのを保証する」 (スコア:0)
> データが最終目的地に到達することを保証する仕組みだそうだ。
口で「保証する」と言うのは簡単だが、実際にやるのは・・・
> 仮に二つのLunaNetノード間で障害が発生した場合でも、経路が明確になるまでデータを保存するとしている。
「保証する」以上は、つまりこれは宇宙が滅びるかあるいは、相手先が利用可能になるまで「保存する」わけだろう？
「保証する」のだから、ディスクが溢れそうだから諦めるということは許されない。
到達不能データの山で破綻するのでは？それとも、技術の発展でディスク容量が増えていくほうが速いとでも？
Re: (スコア:0)
うまくすれば、空間そのものをメモリに使うことができます。
宇宙規模だと相当の情報量が空間に記録できると思います。
S/Nが悪くなる前に送り返してもらう必要がありますけど。
ええ、空間遅延線メモリです。
Re: (スコア:0)
プロキシマケンタウリ（距離4.24光年）に鏡を置いてそこに光を反射させてみよう。信号を送ってから戻ってくるまで8.5年。0.1bit/s（10秒で1ビット）の通信レートでデータを送信したとすると、
8.5 * 365 * 24 * 60 * 60 * 0.1 ≒ 2.7Gbit ≒ 340MB
思ったより多くのデータは詰め込めないなあ。
Re: (スコア:0)
地球とプロキシマケンタウリの間の空間を水銀で満たせばもっと詰め込めるのでは？
Re: (スコア:0)
銀河ハイウェイの建設予定地の情報を入れるには、十分な容量ですね。
Re: (スコア:0)
プロキシマケンタウリ側のミラー角度制御精度が保証し切れないなら、ミラーを多少凹凸に歪めて反射光を散らし、投光側を「バベルの光」級の大出力光送信機化する必要があるかも。
Re: (スコア:0)
> 到達不能データの山で破綻するのでは？
仕様読まずに書いてますが、
もしもそれが問題になるほどトラフィックが増えたら古いデータから諦めて消していけばいいだけじゃないでしょうか。
現在のTCPだとパケット損失率が一定を越えると通信が詰まってしまって性能劇落ちかコネクションが切れてしまうし
ラウンドトリップタイムが大きいとどんどん遅くなるしで、別のプロトコルが必要なのは確かでしょう。