tcp - TCP で検証は必要ですか?

Question

要するに、数秒ごとにサーバーにパケットを送信するアプリケーションを実装する必要がありました。サーバーがそれらを受信すると、クライアントに応答を送信し、クライアントは別のパケットを送信し始めました。これはすべて良いように聞こえますが、TCP を使用していたため、サーバーがパケットを取得するとすぐに応答が返され、後処理などは行われませんでした。それで、なぜこのようなことをするのだろうと思いますか？クライアントには、すべてのパケットを保持するキューがあり、次のようなことを行いました。

try {
    send packet // exception is thrown if connection is lost
    remove packet from queue
} catch exception {
    try to reconnect 
}

したがって、この場合、パケットは送信が成功した場合にのみキューから削除されます。

これについて何か考えはありますか？これはベストプラクティスですか？誰かが私のためにこれをクリアしていただければ幸いです。

ありがとう

Answer 1

送信だけでは不十分な場合があります。ドアの外に押し出しているデータを受信する必要があることが絶対に重要な場合は、パケットがリモート エンドによって受信/処理されたという確認応答を待つ必要があります。

ネットワーク レベルの処理が完全に機能し、パケットが宛先に到着したとしても、宛先マシンがクラッシュしたり、データが失われたりする可能性があります。送信時に削除すると、そのデータはなくなります。リモート エンドからの確認応答を待つことで、少なくとも、破損/紛失したパケットを再送信できるようになります。

Answer 2

1 つのオプションは、パケットをキューに入れて送信することです。送信後、それらを「保留」キューに移動します。相手側がそれらを処理したら、完了としてマークします。次に、他の問題に直面します。相手側がそれらを処理しても、確認応答があなたの側に届かない場合はどうなりますか? これは比較的研究されている問題であり、確実にする必要がある場合は、分散トランザクションと 2 フェーズ コミットを調査することをお勧めします。