メッセージを送るには その５ 標準実装のTCP

OW 標準実装の TCP はちょっと不思議な感じ。まあ調べればちゃんと理由はあるんだけど。
トランスポート層として TCP を使用し、１つのノードと送受信する場合を考える。
こちらからそのノードへ送信しようとすると、コネクションが張られる。これは ow.messaging.tcp.ConnectionPool でプールされるので再利用可能。
もしプール数が ow.messaging.tcp.TCPMessagingConfiguration.getConnectionPoolSize()
を超えると、ランダムでプールされている中から切断するコネクションが選ばれる。
ランダムってのがちょっと悩むところ。使用しなくなって一番時間が経過した
コネクションの方がよさそうなんだけどな。まあそれは大きな問題ではなかろう。
では受信。あるノードに送信したとする。そうするとそのノードへのコネクション
はすでにプールされている。その状態で相手ノードがメッセージを送りたいとする。
すでに張られているコネクションを利用するのか？

利用しないんだな。

実は OW の TCP 実装は一方通行。全二重（もう古い言い方なんだろうか。私は
世代的には半二重を知ってる世代なもんで）のはずなのになんともったいない。
と貧乏根性を最大発揮してもしかたない。なぜこうなっているのか？
たぶん接続してきた相手が、いったい誰なのかわからないからだろう。
２つのノードが同一の IPv4 アドレスを持つこと、つまりあるマシンが２つの
P2P を起動することは十分に可能だ（ポート変えりゃ簡単だ）。そうなると、
接続してきた元の IPv4 アドレスからだけでは相手を判断できない。
もちろん接続してきたそのコネクションのポート番号を調べても無駄だ。
そのポート番号はランダムに割り当てられたものなのだから。
そうなると、接続された側は相手が誰だかわからない、だからそのコネクション
へは送信しない（できない）わけだ。たとえメッセージをそこから受信し、
そのメッセージの src を取り出しても相手のアドレスとは限らない。
延々とルーティングでたらいまわしにされたメッセージかもしれないからだ（
以前、メッセージの src を詐称できちゃうんじゃ、って書いてたのは間違いで、
実際には送信元を示すために必要なのだ。メッセージは直接相手に届く場合だけじゃ
なく、転々と転送されて届けられることもあるから、送信元情報の格納が必須）。

送信は Encode された byte 列を書き込むだけ。ここはぜひとも channel で並列処理
したいところだ。で、受信なんだけどここはちょっと気にしておきたいってことで
明日に続く。たぶん明日だろう、きっと。