ソケット通信の受信サイズ

MFC VC++6.0で、ソケット通信を勉強しています。

サーバー側を
http://athomejp.com/goldfish/mfc/socket/socketse …
を参考に「ソケットから何かを受信する」ところの
配列サイズとwhileの条件を

char szBuf[1024];
while( nret != 0 )

に変更しました。

クライアントからは64バイトの送信をしているのですが、
サーバでReceiveしたサイズが16バイトで、whileを抜けてしまいます。
何が原因でしょうか、ご教示ください。
お願いいたします。

No.3 ベストアンサー 回答者： chie65535 回答日時： 2009/08/02 02:49

＞サーバでReceiveしたサイズが16バイトで、whileを抜けてしまいます。

＞何が原因でしょうか、ご教示ください。

質問ページの下の方に
------------------------
また、一回のSendやReceiveでは、データが送受信できるとは限らないため、ソケットの送受信は、必ず、戻り値をチェックすること。
------------------------
と書いてあります。

ちょっと判りにくいですが、これは
------------------------
また、一回のSendやReceiveでは、すべてのデータが１回で送受信できるとは限らないため、ソケットの送受信は、必ず、戻り値をチェックすること。
また、送信した直後、送信バッファが一杯だと、２回目以降の送信バイト数が0になる事がある。
同様に、受信した直後、受信バッファにまだ続きのデータが何も溜まってないと、２回目以降の受信バイト数が0になる事がある。
------------------------
と言う意味です。

また、受信の場合「運が悪いと、ソケットが繋がった直後の最初の受信で、受信バッファがまだ空っぽで、0バイトしか読まない」なんて事も起きます。

質問者さんの場合では、送り側で64バイト送信しても、受け側で「何か来た！受け取れ！」と思って受け取っても「まだ64バイト全部来てなくて、頭の16バイトしか受け取れず、続きを受け取ろうと２回目の受信をしてみたらまだ続きが全然来てなくて何も受け取れず、nretが0になってループを抜けちゃった」って事が起きた訳です。

送信側で64バイト送っても、受信側は
・１回目で16バイト受け取る
・２回目で0バイト受け取る
・３回目で0バイト受け取る
・４回目で8バイト受け取る
・５回目で0バイト受け取る
・６回目で0バイト受け取る
・７回目で8バイト受け取る
・８回目で0バイト受け取る
・９回目で0バイト受け取る
（以下略）
って事が起きちゃう訳です。

ループ条件を
while( nret != 0 )
にしてしまうと、２回目の「続きがまだ全然来てなくて0バイト読んだ」って状態でループを抜けてしまうのです。

この問題は「CSocketが、ノンブロッキング、ブロッキング（ノンバッファリング、バッファリング）をかなり無茶な方法で実装している」のが原因で発生します。

No.4 回答者： chie65535 回答日時： 2009/08/02 02:52

訂正。

質問ページの下の方に
は
質問文で参考にしたページの下の方に
の誤りです。

No.2 回答者： oldman50 回答日時： 2009/08/01 23:01

http://www.kt.rim.or.jp/~ksk/wskfaq-ja/articles/ …

CSocketは色々と問題があるみたいですね。
なんらかの原因でnretの値として0が返されている可能性があります。
while( nLen != sizeof( szBuf))
の場合は
nLen += nret;
でnLenがクライアント側の送出データサイズに到達するまではループから抜けることができないので、すべてのデータが受信できているのでしょう。

No.1 回答者： Wr5 回答日時： 2009/08/01 14:53

>char szBuf[1024];

>while( nret != 0 )
>に変更しました。
>クライアントからは64バイトの送信をしているのですが、
>サーバでReceiveしたサイズが16バイトで、whileを抜けてしまいます。
>何が原因でしょうか、ご教示ください。

当然、nretが0ではないからループから抜けたのでしょう。
送信側のsend()で1024バイトを１度で送信しても、受信側のreceive()1回で1024バイト受信できるとは限りません。

16バイト受信した後で、再度receive()を実行すると残りの48バイトが一度でとれるかも知れません。
# 勿論、そんな保証はないので16バイトずつ繰り返しになるかも知れませんし、もっと分断して受信するかも知れません。