Windows：TCP/IP：強制的に接続を強制：カーネル/ユーザーレベルでmemleakを避ける

Question

Windowsネットワークプログラミングの専門家に質問。

私はこのような擬似コードを使用する場合：

reconnect: 
    s = socket(...); 
    // more code... 

read_reply: 
    recv(...); 
    // merge received data 
    if(high_level_protocol_error) { 
     // whoops, there was a deviation from protocol, like overflow 
     // need to reset connection and discard data right now! 
     closesocket(s); 
     goto reconnect; 
    } 

は、カーネルの非準を行い、待っている、カーネルメモリに、それは本当に既に存在でなければならないので、「物理的」NIC（から受信したすべてのデータを解放します私はclosesocket（）を呼び出すと、ユーザーレベルでrecv（）を使って読むことができますか？データは内部オブジェクトに関連付けられていないため、論理的にはそうでしょうか？

「」のようなクリーンシャットダウンの時間が分からないので、recv（）が返されるまでエラーはになるため、それは意味をなさない：何かがエラーを返すことは決してないと言うと、サーバーはデータを永遠に送信し続け、接続を閉じないが、それは悪い振る舞いであるか？

私のアプリケーションがメモリリークをどこにでも引き起こしたくないので、私はそれについて疑問に思います。このように強制的に接続をリセットする方法ですが、それでもまだが送信されると予想されますデータ量は正しいですか？

//このオプションがWindowsに適していると思われる場合は、UNIX対応OSの場合（closesocket()〜close()の変更あり）は正しいと考えることができますか？

Answer 1

tcpip.sysを含むWindowsのカーネルドライバ（実際にはOS）は、ユーザモードで何をしているかにかかわらず、すべての状況でメモリリークを避けることになっています。私は、開発者がリソースが漏れていないことを確認するために、エラー状態を含む可能性のある状態をチャート化していると思います。ユーザーモードに関しては、わかりませんが、あなたのプロセスでリソースが漏洩しているとは思わないでしょう。

ソケットはWindowsのファイルオブジェクトです。ファイルの最後のハンドルを閉じると、IOマネージャーはファイルを所有するドライバーにIRP_MJ_CLEANUPメッセージを送信して、関連するリソースをクリーンアップします。ソケットに関連付けられた受信バッファは、ファイルオブジェクトとともに解放されます。

closesocketdocumentationでは、保留中の操作はキャンセルされますが、関数が返された後で非同期操作が完了することがあります。それは、使用中にソケットを閉じるように思えますが、サポートされているシナリオであり、メモリリークにつながることはありません。

Answer 2

リークはなく、終了する前にストリームをEOSに読み込む義務はありません。送信者が閉じた後も送信者がまだ送信している場合、最終的には「接続のリセット」が発生します。