ackでのブロードキャストとUDPの使用（既存のシステムをサポートしているため、使用する必要があります）。ネットワークを介したメッセージの同期
AがmsgをBに送信すると、Aのタイマーは実行を開始し、タイムアウトする前に同じメッセージをBに再度送信します。多くのシステムのコーディネーターであるBは、Aに返答するのが遅れている可能性があります。さらに、返事は処理中に失われる可能性があります。 AはいつでもBに任意のメッセージを送信できます。
BのackがAに達する前にAが再送B msgの危険を減らす（私は解くことはできないと思われます）ので、Aはmsgを失敗（2回再送した後）に登録してからBのackに達するでしょうか？
これは実際にブロードキャスト、つまり1対多の伝送ですか？それはあなたが受信機ごとに再送信の決定を言及するので、純粋な放送のようには聞こえません。だから私はあなたが独立して各受信機にパケットを送ることができると仮定して答えるでしょう。
TCPから概念を借用すれば、信頼性の高いメカニズムを構築できます。 TCPは、アウトオブオーダーの再組み立てを処理し、（ACKウィンドウを使用して）高レイテンシで高帯域幅に拡張することができ、チャネル条件にいくらか適応性があります。
あなたがやっていることによっては、それは過度のことかもしれません。代わりに、USBから借用することもできます.USBは、パケット配信と確認応答に信頼性と曖昧さ回避の仕組みも備えています。ただし、一度に未処理の1つのパケット（ウィンドウサイズ== 1など）しか処理できず、高帯域幅または高遅延の要件がある場合は、主要なパフォーマンスリミッタになるアウトオブオーダー配信を処理できません。
いずれの場合も、通常の操作中にヒットすると予想されないほど、全体的なタイムアウト（アプリケーション層への配信エラーを通知するため）が長くなる必要があります。たとえば、TCP実装では、配信をやめてアプリケーション層に問題を通知するために15秒以上待機します。
基本的な1パケットずつの配信を超えるものを設計するには、深刻なプロトコル設計とQAが必要です。コーナーケースはヒットしにくいです。要件が自明でない場合は、堅実なネットワークプロトコルエンジニアを雇うか、TCPのような既存のソリューションを使用する方法を見つけ出す必要があります。
の関連ディスカッションも参照してください。
アプリケーションに必要B書かれた高優先度、スケジュール好ましいリアルタイムに、スレッドがアプリケーションからのパケットを待って座っているように。 がパケットを受信すると、ペイロードをメモリロックされた循環バッファにコピーし、すぐにソケットのポーリングに戻ります。次に、実際の処理のために循環バッファから読み取ったアプリケーションBのビジネスレベルのロジックを持ちます。