OW はトランスポート層を取り替えることができる。
トランスポート層の実装は ow.messaging.MessageSender とか
ow.messaging.MessageReceiver を実装してるので、これらを JavaDoc で見れば
どういう通信手段があるかわかる。
現在のところ、TCP, UDP, シミュレーション, 分散シミュレーションの４種がある。
シミュレーション用実装は、メッセージを送る場合、Sender が Receiver に
直接データを渡しちゃう実装。なのでパケットロスとかはありえない。
分散シミュレーションは、自分に送る場合はシミュレーションと同様に直接
渡しちゃうが、他ノードへは UDP もしくは TCP で送るらしい。なんか入り組んでて
完全には判らなかった。というか、ポート番号変えて自ノードで複数 OW を起動
すりゃいいんじゃ…。
実際にインターネットで運用する気なら、最終的には TCP もしくは UDP となる
わけで、あとはどう使い分けるか。
と以前は思ってたのだが、どうにも UDP じゃ無理っぽいと思い始めている。
UDP でやるには結局のところ、パケットロスの補償が要るわけだが、だったら
TCP でやりゃいいじゃん、車輪再発明し過ぎという意見がある。
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
ここの５章 UDP の項目を見れば UDP でっていう気力が萎えてくる。
（ちなみに同一HPの http://www.kt.rim.or.jp/~ksk/wskfaq-ja/index.html
もオススメ。このHPの FAQ は、TCP/IP を扱う技術者は必読だと思う）
さらに UDP は、どのバイト数のパケットなら相手に届くかわからない。経路の途中
で断片化されるとパケットロスの危険が高まる。TCP なら Path MTU Discovery で
できる限りの効率で通信ができる。
http://www.microsoft.com/japan/technet/community/columns/cableguy/cg0704.mspx
http://wakita.no-ip.com/server/ProblemMTU.html
実際、Infoseek の無料 HP に申し込んで Perl スクリプトを動かし、自宅に向けて
パケットを送ってみたところ、1426byte のパケットなら届いたが 1427byte は
届かなかった。自宅は Flet's ADSL なので、MTU 1454byte が効いているものと
思われる。IP パケットのヘッダ 20byte と UDP のヘッダ 8byte のあわせて
28byte。1454-28=1426byte となってるわけだ。
じゃあ全員が全員このバイト数で良いかというと、そうもいかないだろう。経路
の途中でもっと小さい UDP パケットしか受け付けない経路があるかもしれない。
どこでも質の高い経路、ってわけじゃないし。
そう考えると、UDP でやる利点ってパケット単位で受け取れる（ストリーム志向
じゃない）ってのが最大の利点なのかなぁ、と。
OW では１メッセージを 1 UDP パケットで送るのが標準実装。ってことは、ちょっと
でもデカい情報は送れないってことになる。
とまあこれで UDP じゃダメだなぁってこと、決定。
小さい情報しか送らないとしても、DHT で get しようとしたら同一キーに複数の情報が存在しましたってなったらそれで 1426 byte 超えちゃうこともありうる。
しかし同一 LAN 内に限るのであれば、たぶん問題なく使えるんだろうな。以前、
仕事で UDP でメッセージをやり取りしたんだけど、デカいパケットでも同一 LAN 内
ならぜんぜん問題なかったしね。
UDPについてはこんなところか。TCPについては以下続く。たぶん今週末あたりになるけど。
トランスポート層の実装は ow.messaging.MessageSender とか
ow.messaging.MessageReceiver を実装してるので、これらを JavaDoc で見れば
どういう通信手段があるかわかる。
現在のところ、TCP, UDP, シミュレーション, 分散シミュレーションの４種がある。
シミュレーション用実装は、メッセージを送る場合、Sender が Receiver に
直接データを渡しちゃう実装。なのでパケットロスとかはありえない。
分散シミュレーションは、自分に送る場合はシミュレーションと同様に直接
渡しちゃうが、他ノードへは UDP もしくは TCP で送るらしい。なんか入り組んでて
完全には判らなかった。というか、ポート番号変えて自ノードで複数 OW を起動
すりゃいいんじゃ…。
実際にインターネットで運用する気なら、最終的には TCP もしくは UDP となる
わけで、あとはどう使い分けるか。
と以前は思ってたのだが、どうにも UDP じゃ無理っぽいと思い始めている。
UDP でやるには結局のところ、パケットロスの補償が要るわけだが、だったら
TCP でやりゃいいじゃん、車輪再発明し過ぎという意見がある。
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
ここの５章 UDP の項目を見れば UDP でっていう気力が萎えてくる。
（ちなみに同一HPの http://www.kt.rim.or.jp/~ksk/wskfaq-ja/index.html
もオススメ。このHPの FAQ は、TCP/IP を扱う技術者は必読だと思う）
さらに UDP は、どのバイト数のパケットなら相手に届くかわからない。経路の途中
で断片化されるとパケットロスの危険が高まる。TCP なら Path MTU Discovery で
できる限りの効率で通信ができる。
http://www.microsoft.com/japan/technet/community/columns/cableguy/cg0704.mspx
http://wakita.no-ip.com/server/ProblemMTU.html
実際、Infoseek の無料 HP に申し込んで Perl スクリプトを動かし、自宅に向けて
パケットを送ってみたところ、1426byte のパケットなら届いたが 1427byte は
届かなかった。自宅は Flet's ADSL なので、MTU 1454byte が効いているものと
思われる。IP パケットのヘッダ 20byte と UDP のヘッダ 8byte のあわせて
28byte。1454-28=1426byte となってるわけだ。
じゃあ全員が全員このバイト数で良いかというと、そうもいかないだろう。経路
の途中でもっと小さい UDP パケットしか受け付けない経路があるかもしれない。
どこでも質の高い経路、ってわけじゃないし。
そう考えると、UDP でやる利点ってパケット単位で受け取れる（ストリーム志向
じゃない）ってのが最大の利点なのかなぁ、と。
OW では１メッセージを 1 UDP パケットで送るのが標準実装。ってことは、ちょっと
でもデカい情報は送れないってことになる。
とまあこれで UDP じゃダメだなぁってこと、決定。
小さい情報しか送らないとしても、DHT で get しようとしたら同一キーに複数の情報が存在しましたってなったらそれで 1426 byte 超えちゃうこともありうる。
しかし同一 LAN 内に限るのであれば、たぶん問題なく使えるんだろうな。以前、
仕事で UDP でメッセージをやり取りしたんだけど、デカいパケットでも同一 LAN 内
ならぜんぜん問題なかったしね。
UDPについてはこんなところか。TCPについては以下続く。たぶん今週末あたりになるけど。