注：セッション全体でマルチキャストまたはブロードキャストを使用する方法を尋ねているのではなく、ハンドシェイクのみを求めています
カーネルを変更せずに、自分のアイデアを Linux プログラムに実装できるかどうか疑問に思っていました。または、カーネルの変更が実際に必要な場合は、どのファイルを編集する必要があるかを知りたいです。
基本的な考え方は次のとおりです。「クライアント」は TCP SYN パケットをブロードキャストまたはマルチキャスト アドレスに送信し、accept() または同等の関数を呼び出して、返された SYN-ACK ごとに個別のファイル記述子を開きます。
理想的には、変更されたハンドシェイクを使用してから、標準の TCP メソッドに切り替えたいと考えていますが、それが不可能な場合は、別のスレッドを使用して unix ドメイン ソケットでエミュレートしてもかまいません。
大幅なカーネルの変更が必要になることは間違いありません。また、TCP RFC とは完全に互換性がないため、実装するものは TCP ではありません。
どのファイルを編集する必要がありますか? TCP カーネル実装ファイル。ただし、最初に Linux の TCP がどのように機能するかを十分に理解する必要があります。
ただし、より単純なソリューションを試してみませんか?
UDP マルチキャストを使用して、すべての潜在的なパートナーにメッセージを送信します。それぞれが UDP 経由で IP とポート番号を返信します。次に、それらすべてに対して通常の TCP 接続を開きます。
TCP に複数のクライアントを持たせることは簡単ではありません。理由のいくつかを次に示します。まず、複数の受信者がいる場合、どの送信レートを誰に使用するかを追跡するにはどうすればよいでしょうか。2 つ目は、複数の受信者が一連のパケットを見逃した場合、それらのパケットをどのように再送信するかです。第 3 に、レシーバーが特定のレシーバー バッファー (別名フロー制御) をアドバタイズする場合、どちらを選択しますか? アドバタイズされた最小のバッファーを選択して他のバッファーに影響を与えますか、それとも平均を選択して一部のレシーバーのみに影響を与えますか? 最後に、TCP は接続指向であるため、これを行うためにカーネルをハックしたとしても、send()/recv() などの通常のソケット呼び出しは、どのクライアントから送信または受信するかを認識しません。sendto()/recvfrom() を使用することもできますが、現在のところ、カーネルは通常、これらの呼び出しでアドレスを無視します。
TCP の上にアプリケーション層のオーバーレイを構築する方が良いかもしれません