goo blog サービス終了のお知らせ 

P2Pとかプログラミング全般とか

P2Pアプリ開発を目指していこうかと。
基本、週末更新なので遅々として進まず。

メッセージを送るには その6 TCPの受信でスレッドいっぱい

2008-02-17 18:29:16 | Overlay Weaver
TCP のコネクションプールで補足。プールする接続数は ow.messaging.tcp.TCPMessagingConfiguration
で決まるんだけど、その数は動的に変更可能。TCPMessagingConfiguration.setConnectionPoolSize(int size)
で設定する。

で、受信なんだけど ow.messaging.tcp.TCPMessageReceiver で行ってる。具体的には
start() メソッドでスレッドを起動し、run() メソッドで接続の accept を待つ。
accept した接続はどうするかというと、内部クラスの TCPMessageHandler クラスの
インスタンスを生成、そのインスタンスに渡してそれをスレッド起動(!)する。
ということは接続されればされるほどスレッドがどんどん増えると…。
これは看過できない。しかもこちらから積極的に接続を閉じることはしない。
うーん…。

データの受信、これもちょっと…。具体的には ow.messaging.Message.decode(ByteChannel in)
にソケットチャンネルを渡して終わり。そのメソッド内では必要分の情報を受信する
まで channel からデータを読み出す。ブロッキングソケットだから、データが受信
できるまでそのスレッドは止まり続けるわけだ。だからこその別スレッド起動なんだけど。

まあ実装は正しいんだけど、スレッドが大量に起動する可能性があるのはいただけないなぁ。
要はメッセージ境界がハッキリしないからブロッキングソケットで必要分が届くまで
受信し続けるって実装なんじゃないかな、想像だけど。
だったら送信する際にバイト配列にしたメッセージ情報のバイト数を相手に送信して、
メッセージ境界をはっきりさせればいいのでは?1スレッドで複数の受信ソケットを
select なりで扱い、データを溜め込む。メッセージ境界まで読み込んだら decode
する。これでいいと思うのだが。

とまあ6回もメッセージ送受信で書いた結論としては、標準実装の TCP で頑張ってみようということ。
次からは少しずつ実装を行っていけたらいいな。では次の土曜日にまた。