私は、ローカル ネットワークを介してピアのアドレスをブロードキャスト/マルチキャストすることにより、自己構成をサポートする通信プロトコルに取り組んでいます。直観的な方法はアドレスをブロードキャストすることですが、結局のところ、現在のマシンのローカル IP アドレスを確実に把握することはかなり困難です (構成によっては、「127.0.0.1」または別の役に立たないアドレスを取得する可能性があります)。 .
別の方法は、ブロードキャスト メッセージにホスト アドレスを含めずにrecvfrom、受信データだけでなく送信者のアドレスも返すソケットを受信者に呼び出させることです。私が見たところ、この呼び出しは Unix と Windows (私の要件の 1 つ) の両方で利用でき、おそらくその他のいくつかのプラットフォームでも利用できます。私の質問は、これが失敗しrecvfrom、到達不能または役に立たないアドレスを返す可能性がある状況はありますか?
この手法をブロードキャスト UDP のみに制限する場合は、問題ありません。これを台無しにする傾向があるのは、デュアル NAT やヘアピン NAT などだけです。とにかく、ローカルのみのブロードキャストでは、それは行われません。
どのアドレスも、いつでも到達不能になる可能性があります (したがって、あなたの定義では役に立たなくなります)。あなたのソフトウェアはそれに対処する準備ができている必要があります。
インターフェイスを列挙することで、システムの IP アドレスを確実に特定できます (複数形であることに注意してください。これについては後で詳しく説明します)。標準 (POSIX など) にはその方法を指定するものがないため、これを行う方法はプラットフォームによって異なります。多くの Unixy システムにはgetifaddrs()呼び出しがあります。Windows は別の処理を行います。いずれにせよ、そのコードを分離するのは簡単なはずです。
また、ソフトウェアは、遭遇する IP が「その」アドレスであると仮定するべきではありません。複数のインターフェイス (ループバックを数えるとほとんどのインターフェイス) を持つシステムでは、ルーティングが変更されるか、誰かがデフォルト ルートと同じインターフェイス上にないセグメントでプロトコルを実行する可能性があります。
メッセージをブロードキャストする場合は、別の方法で構成されていない限り、アップしているすべてのインターフェイスで 1 回実行する必要があります。ループバックが含まれます。ブロードキャストは、適切なアドレスを持つように、これらの各インターフェイスからも発生する必要があります。インターフェイスと同じセグメントにある他のホストが、他のインターフェイスを認識している、またはそれらのアドレスにルーティングする方法を持っていると想定することはできません。
プロトコルが接続されたセグメントでのみ使用することを意図している場合、接続されていないサブネットからのデータを破棄することは合理的なことです。