日々の破片

_ ネイグルのアルゴリズム

うーんと単純に言えば、バッファリングできる限りして、小さなパケットでネットワーク帯域が無駄に消費されるのを抑制しようっていうことだ。ちなみに、RFC896。

大いに結構なことなのだが、100m秒程度の遅延でも十分に問題になる場合がある。で、その場合は、回避するために、TCP_NODELAYをsetsockoptしたりする。 たとえば、スモールデバイスだと、制御電文をバシバシ投げたかったりするんだが、良く考えずにUDPを選ばずにTCP使ったりすると、こんな恐ろしいことが待っていたりする。

MSの資料は引きやすいので引用を続けると、これなんか、出た当時は熟読したもんだ。

で、まあ、こういうのは最近、すっかり忘れていたんだが(というか、このあたりのチューニングを目的としてFreePeekとか作ったりしたわけだが)、Oracleが思い出させてくれたよ。タイプ4のネットワークドライバだ。Javaの制限で、ローカルマシン間の通信でも、UnixドメインじゃなくてTCP/IPを使うから、しっかり影響されるんですな。で、つい直前のOracle9iだと（今現在は違うらしい）、隠し属性がDriverManagerにあったりするんだが、DataSource(やConnectionPoolDataSource)使いたい場合が、問題なんですな。最悪、オレConnectionPoolDataSource作るかとか思ったけど、なんとなく誤魔化せてるから(多重度上げれば—しょせん、待ち状態になってるだけだからCPU的には閑—、結局、全体の処理量はそれほど変わらない＝スループットは変わらないが、ターンアラウンドタイムは悪くなると言うので正解だったかな？）まあ、いいや。

と思い出したのでメモ。

_ って言うか

小さなパケットがばかばか出ると、コリジョンが起きやすくなったり、キャリアセンスで引っ込みやすくなったりするから、っていうのが理由だったりすると、今や、あまり意味ないような気も。もっともrfc896を読むと、TCPとIPそれぞれのヘッダのオーバーヘッドが馬鹿にならないという点が重要みたいだけど。

ノンプリエンティブネットワーク。

通れるだけの細い道をあけてください！

さもないと大きな岩を動かしますよ——と！　（大山倍達 談）

ちなみに、rfc1122では、MUSTで、アプリケーションが個々のコネクションについてネイグルアルゴリズムを回避するための手段を提供しろとなってる。

_ こんなのがあった

...