UDPはコネクション型プロトコルではないことは知っていますが、UDPは私がしなければならないことの要件です。
クライアントアプリケーションからサーバーアプリケーションに大量のパケットを送信しているときに、サーバーアプリケーションが閉じられたかどうか（たとえば、ユーザーがプロセスを終了したかどうか）を知る方法はありますか？
1つの方法は、サーバーに定期的にpingを実行し（データストリームを送受信するスレッドとは異なるスレッドで）、応答を待つことです。サーバーがpingを確認しない場合は、ダウンしている可能性があります（保証はされていませんが、これは結局UDPです）。
しかし、より良い/より簡単な方法はありますか？
信頼できる方法はありません。トランスポートとしてUDPを使用する、私が実装したプロトコルは、要求/応答モデルを使用します。たとえば、SIPは、次のように実行します（もちろん、一般的に）。
2つのピア（AとB）があるとします。ピアAがピアBに要求を送信する場合、ピアBは常に応答を返送する必要があります。ピアAが特定の時間内に応答を受信しない場合、ピアAは前のメッセージを再送信します。ピアAは、ピアBから応答を受け取るまで、または指定された有効期限（これが何であるかはあなた次第）まで、メッセージを再送信し続けます。その時間が経過した場合は、ピアBがダウンしていると見なします。
サーバープロセスが実行されていない場合、サーバーOSは「宛先ポートに到達できません」などのICMPパケットを送信者に送り返す場合があります。tcpdumpまたは他のパケットスニファで確認してください。もしそうなら、あなたのクライアントはそのような応答が受け取られたかどうかを知ることができるかもしれません。
サーバーへのping（ICMPエコー）は、サーバープロセスが実行されているかどうかに関係なく、OSがpingに応答するため、あまり役に立ちません。
そうですね、UDPは信頼性の低いプロトコルです。ハンドシェイク、確認、信頼性はありません。
最善の策は、新しいスレッドでpingを実行することですが、UDP方式（同じエンドポイント実装）でpingを実行しますが、宛先に「受信した」UDPパケットを返送させるよりも信頼性は高くありません。状態のある開いた接続ではないため、それよりもはるかにうまくいくことはありません。パケットを送信して到着したと見なすか、データを受信しただけです。また、受信の順序についての保証はありません。そのため、pingが成功し、実際のペイロードを上回っていなかったか、別のリクエストから成功の応答が返されなかったと想定する必要があります。