私たちは、UDP上で通信を行うシステム（C言語で構築されています）を用意しています。最近、パケットの配信を保証する必要があることが判明しました。私の質問は、ackパケットを使った配信を保証するために、UDPベースのシステムに最低限必要なものは何でしょうか？また、理想的には、パケットヘッダーを操作する必要もありません。シーケンス番号とACK/NACKフラグを含むパケットに対するアプリケーションレベルの制御があります。私はこれが失われた原因であるかどうか、私たちがやろうとしていることは基本的にTCPの欠陥で壊れたバージョンであると思っています。基本的に、保証された配信を実現するための最小限の改善があります（輻輳制御などのTCPの多くの機能は必要ありません）。ありがとう！UDPを使ってackを実装していますか？
難しい問題です。私は、TCPの信頼性を達成することはできないだろうと言います。しかし、私は時々、あなたは信頼できるUDPを持つ必要があることを理解しています。
RUDP（もう少しハードコア）
はスティーブンのUNIX Network Programming, volume 1の第8章と第20章を見てみましょう。彼はさまざまなアプローチをカバーしています。 20.5項「UDPアプリケーションへの信頼性の追加」はおそらくあなたにとって最も興味深いでしょう。
+1を参考にしてください。以前はプログラミングの割り当てに似たようなことをしていたとき、そのセクションは素晴らしかったです。 – mrduclaw
「信頼できるUDPが必要なときに何を使用するか」に対する回答を収集しているhereという質問があります。答えはあなたが必要とするものよりもはるかに多いかもしれませんが、あなたはUDPで構築されたプロトコルのいくつかを見て、あなたが必要とするACK部分だけを得ることができるかもしれません。
私はENetプロトコル（信頼性の高いUDPプロトコル）を使って作業していますので、各UDPデータグラムにシーケンス番号が必要です。受信したデータグラムのACKを送信する方法、保留の方法あなたがACKを受け取るか、タイムアウトするまでに送信したデータグラムの数と、まだACKを受け取っていないデータグラムの再送をタイミングする方法...あなたが決定したときに特定のデータグラムを提供するつもりはないと思います。アプリケーション層へのコールバックが、この失敗を通知するためのものです...
TCP関連の3つのサービスがあります。もっとたくさん、しかし私は話すつもりです3）
あなただけがフロー制御を必要としないことを言ったので、私も（どのように広告を掲載することを対処していないだろうウィンドウのサイズなどは、あなたがおそらくウィンドウが必要であることを除いて。私はそれに行くでしょう）
あなたは信頼できる配送が必要だと言いました。これはあまり難しくありません。送信者がパケットを受信したことを示すためにACKを使用します。基本的な信頼性の高い配信は、次のようになります。
これらの3つのステップは、これらの問題に対処しませんか？
あなたのアプリケーションでは、信頼性の高い配信が必要だと言われましたが、必要なことは何も言いませんでした。これは、プロトコルの実装方法に影響します。
（イン・オーダーは重要ではありません例：。。あなたは、あるコンピュータから別のコンピュータに従業員レコードをコピーしているアリスの記録がボブの前に受信された場合に限り、両方がそこに着くよう、関係ありません）
あなたはあなたがあなたの記事の中で言ったことがあるので信頼できるだけの必要があるという前提で、あなたはこれをいくつかの方法で達成することができます。
送信者は未確認のパケットを追跡できます。したがって、3番、4番、5番、6番を送信し、3番と4番のACKを取得しない場合、送信者は再送が必要であることを認識します。 （送信者は、パケット3と4がロットであるかどうか、またはACKが失われているかどうかはわかりませんが）再送信する必要があります。
しかし、送信者は累積ACKを行う可能性があります3、4、および5を受信した場合は、＃6を返すだけです。これは、受信者がの場合、前に受信していない場合はパケット6をドロップすることを意味します。ネットワークが非常に信頼性が高い場合、これは悪い選択肢ではないかもしれません。
しかし、上記のプロトコルにはウィンドウがあります。つまり、送信者が一度に送信するパケットの数はありますか？つまり、フロー制御の目的ではなく、何らかのウィンドウ処理が必要です。どのようにウィンドウサイズを送信しますか？
ウィンドウのサイズを一定にするか、stop-and-waitのような方法で行うことができます。前者がより良い選択肢かもしれない。
とにかく私はあなたの質問に直接答えませんでしたが、私はこれを設計する際に検討する価値のあることをいくつか指摘しておきたいと思います。フロー制御の部分（ウィンドウ処理のような部分）を持たず、順不同の「信頼性の高い転送」を行うという作業は難しいです！ （私はこのようなもののいくつかの詳細を与える必要がある場合私に教えてください）
幸運！
ackを実装する最善の方法は、アプリケーション層で行うことです。 CoAPはudp上で動作するアプリケーションプロトコルの例ですが、信頼性の高いデータ転送を提供します。すべての確認可能（CON）メッセージのメッセージIDを保持し、受信者は同じメッセージIDを持つACKパケットを送信します。すべてのackおよびmessage idフィールドは、アプリケーション層部分に保持されます。したがって、送信者が彼が送信したメッセージIDでAckパケットを受信しなかった場合、送信者はそのパケットを再送信します。アプリケーション開発者は、信頼性の高いデータ転送に必要なニーズに合わせてプロトコルを変更できます。
本当に価値がありますか？実証済みのテクノロジーと自家製システムを単純に使用します。パフォーマンスのメリットが明確か、時期尚早に最適化していますか？ –
システムはリアルタイムであり、既にUDPを要求する仕様に準拠しています。 –