Path: sranha!katsu From: katsu@sra.co.jp (WATANABE Katsuhiro) Message-ID: Date: 3 Dec 90 08:27:26 Organization: Software Research Associates, Inc.,Japan In-reply-to: nisimura@srava.sra.co.jp's message of 28 Nov 90 02:41:44 GMT Newsgroups: sra.unix Subject: Re: TCP send buffer size Distribution: sra References: <4805@srava.sra.co.jp> 記事 で t-ishii@sra.co.jp (Tatsuo Ishii) さんいはく > getsockopt() で SO_SNDBUF を取ってくると、たとえば NEWS OS R3.4 では > 4096 と出ます。これは、scoket に対し、１回の write() で 4096 バイトま > では送信してくれるという意味だと思っているのですが、果たしてこれは正し > いでしょうか？ > (1) 正しい > (2) 正しくない > (3) 受信側の SO_RCVBUF のサイズによって１回の write() で送信できる場合 > とできない場合がある > (4) その他 受信側の影響を受けるという点では(3)に近いですが、成功するか失敗するか の別れ目の本質は write() する大きさの分だけバッファが空いているかどうか なので(2)もしくは(4)だと思います。 例えば SO_SNDBUF で得られる値が 4096 でも、送信側も受信側も 全部バッファがうまっていれば、write(,,1) でさえも失敗（正確には 成功するまでブロック）します。逆にバッファが空で、受信側での処理が 滞りなく進めば、write(,,65536) でさえも（一瞬ブロックするものの） １回で成功して返り値 65536 を受けとることができます。 逆に言えば、ソケットを利用する側から見た時には、write が成功して 戻ってきたならば、それはすべて（socket layer での意味で）送信して くれたことになるはずです。（TCP セグメントもしくは IP データグラム として送信されたかどうかはもちろん不明）だから、NFS soft mount された先の file に write()したけれども timeout してしまった時のように、write() から 戻ってきたのに全部書ききれていないなんていうことは起きないはずです。 さて、上のように書いた根拠ですが、 記事 <4805@srava.sra.co.jp> で nisimura@srava.sra.co.jp (Tohru Nisimura) さんいはく > SO_SNDBUF 以上のデータを write しようとすると > > (1) 全部一度に write できる > (2) 全部一度に write できるが、実はブロックする > (3) SO_SNDBUF だけ write できる 「Unix System Manager's Manual」の「Network Implementation Notes」の 6.1.2 Socket data queues のところには、 NIN> The socket routines cooperate in implementing the flow control NIN> policy by blocking a process when it requests to seend data and NIN> the high water mark has been reached, ..... とあります。ここで、high water mark というのは struct sockbuf （ソケット送受信バッファ）の sb_hiwat というメンバーで、実は getsockopt(,,SO_SNDBUF,,) で返される値はこれになっています。 早い話が、write したときバッファに空きがなければブロックするという ことなので、(2) ということになります > データが実際にどのようなタイミングで送信されるかはさっぱりわかりません。 理論として、あるいは仕様としてどうなのかは、私は(わからない * 0x10) ですが、ある動いている特定のソケットについて実験として調べるなら、 setsockopt(,,SO_DEBUG,,)をしておいて trpt(8C) を使えば protocol layer での 監視はできると思います。 （ただ、NEWS の trpt はどうもフラグの表示がうまくいっていません。） -- ----____----____ 渡邊克宏＠ソフトウェア工学研旧所