私はソケットプログラミングに不慣れであり、研究でスキームを検証するために、UDPベースのレートレスファイル伝送システムを実装する必要があります。これが私がする必要があることです：
サーバーSがピアA、B、Cなどのグループにファイルを送信するようにします。ファイルはいくつかのパケットに分割されます。最初に、ピアは送信を初期化するためにサーバーに要求メッセージを送信します。Sはクライアントから要求を受信するたびに、エンコードされたパケットをレートレスで送信します（エンコード方法は私の設計で行われ、エンコード自体には消去修正機能があるため、UDPを介してレートレスで送信できます）。クライアントはパケットを収集し続け、それらをデコードしようとします。最終的にすべてのパケットをデコードしてファイルを正常に再構築すると、サーバーに停止メッセージが返され、Sはこのクライアントへの送信を停止します。
ピアはファイルを非同期的に要求します（異なる時間にファイルを要求する場合があります）。また、サーバーは複数のピアに同時にサービスを提供できる必要があります。異なるクライアントのエンコードされたパケットは異なります（ただし、それらはすべて同じセットのソースパケットからエンコードされます）。
これが私が実装について考えていることです。私はunixネットワークプログラミングの経験があまりないので、それを評価し、それが可能か効率的かどうかを確認するのを手伝ってくれるかどうか疑問に思っています。
サーバーを2つのソケットポートを備えた同時UDPサーバーとして実装します（UNPブックによるTFTPと同様）。1つは、制御メッセージを受信することです。これは、私のコンテキストでは、要求メッセージと停止メッセージの場合と同じです。サーバーは、リクエストごとにフラグ（最初は= 1）を維持します。クライアントから停止メッセージを受信すると、フラグは0に設定されます。
サーブはリクエストを受信すると、2番目のソケットとポートを使用してエンコードされたパケットをクライアントに送信する新しいプロセスをfork（）します。フラグが1である限り、サーバーはクライアントにパケットを送信し続けます。フラグが0になると、送信は終了します。
クライアントプログラムは簡単に実行できます。リクエストを送信し、サーバーをrecvfrom（）し、ファイルを段階的にデコードして、最後に停止メッセージを送信するだけです。
このデザインは実行可能ですか？私が抱えている主な懸念事項は次のとおりです。（1）、複数のプロセスをフォークすることで効率的ですか？または、スレッドを使用する必要がありますか？（2）、複数のプロセスを使用する必要がある場合、子プロセスはフラグビットをどのように知ることができますか？コメントしてくれてありがとう。