HTTP リクエストへのレスポンスを次のように記述します。
response.getOutputStream().write()
クライアントがそれを受け取ったことを確認したい。
TCP は確認応答を送信するため、可能である必要があります。
この要件は、書き込みがブロック操作でなければならないことも意味します (私には問題ありません!)。
では、上記の方法で行われたかどうかをどのように知ることができますか (そうではないと思われます)。それを保証する仕様はありますか？それを実現する方法はありますか？私はTomcat 6を使用しています。
... PS、クライアントにこの確認を別のHTTPリクエストで送信させる以外の方法を意味します:)
まず、出力ストリーム バッファを確実にフラッシュすることができます。
response.getOutputStream().flush();
データが実際に送信されることを保証します。TCP はそれが到着することを確認します。さもないと、サーバーにエラーが発生し、IOException に変換されます。
つまり、書き込みができてエラーが発生しない場合、クライアントはデータを受信したことになります。少なくとも TCP スタックでは。クライアントは、メッセージを消費する責任があることは明らかです。
TCP は、データの整合性と配信の保証の両方を提供します。受信者がパケットの受信を確認するまで、再送信を続けます。しかし、これはすべて TCP スタック内で行われます。コードは、それが発生したか、エラーを受け取ったと想定できます。この 2 つの場合のみ可能です。
また、出力ストリームを確実に閉じることをお勧めします。そうしないと、クライアントがストリームの終わりを受信するまでデータをバッファリングしている可能性があります。
これが役立つことを願っています
それがあなたが望むものであると確信していますか？書き込みが成功したかどうかをテストしますか? TCP は確実に機能するように設計されており、パケットが失敗すると、切断と IOExecutions が発生し始めます。実際、RunTimeException が発生します。これを行う方法は、応答をソースに送り返すことです。そして、返事が来るまで待ちます。
待つときは、ハングアップしないように、必ず一定時間待ってからあきらめてください。
コードをデバッグするだけだと仮定します。デバッグしたい場合は、ethereal のようなパケット スニファーを使用します。私を信じてください。ロジックを正しく理解したら、ack パケットは必要ありません。
TCP は、データがピアによって受信されたことのみを認識します。ピアアプリケーションがデータを受信したことはわかりません。また、TCP 書き込みは非同期であるため、書き込みまたはフラッシュが送信側アプリケーションに戻った後も、エラーが検出される可能性があります。
アプリケーションは別の HTTP トランザクションを介して受信を確認できますが、HTTP はステートレスであると想定されており、そうするとそのルールに違反します。
「二軍問題」について調べることをお勧めします。
代わりにすべきことは、トランザクションを冪等にすることです（調べてください）。その後、トランザクションが確実に発生するようにするのはクライアントの責任です。クライアントが応答を受信しない場合は、単にトランザクションを繰り返す必要があります。再試行回数に下限を設定します (2 回または 3 回など)。