はじめまして!
間違えてブロードキャストアドレスを登録したら ネットワークがどう動くかということですね。 実際の動きを正確に予測するのは,結構難しい問題かもしれません。 仕様で動作が定義されているとは限りませんから。 でも,とりあえず考えてみましょうか。
最初に255のマシンから通信動作を始めるのか, つまり,255が最初にパケットを送るか, それとも,他のマシンが255に対して通信動作を行うのか, によって違うので,255からはじめることにしましょうか。 その場合は,255は通信相手のMACアドレスを調べるために, ARPの問合せをブロードキャストしますが, そこで,相手が応答するかどうかがポイントでしょう。 とりあえず,Linux 2.4とWindows XPで試してみた限りでは, 応答を返しませんから,通信できませんね。
他から255のマシンに通信動作を行うときは, 逆にそちらから255のMACアドレスを調べるために, ARPを送るところから始めなければいけないのですが, これも,Linux2.4とWindowsXPで試す限りは, IPアドレスがブロードキャストの場合はARPを送りませんね。 詳しく調べたわけではありませんが, TCPの接続動作を行うときに,相手アドレスがブロードキャストだと, TCP/IPプロトコルソフトがエラーにしてしまうんだと思います。
ということで,通常の通信では通常のアドレスとブロードキャストを 誤認することはなく,単に通信できない,というだけみたいですね。
問題はブロードキャストですね。 ブロードキャストを用いた通信は,普通, ブロードキャストで問合せを送り, それに,ユニキャストで応えるというパターンが多いので, 255からブロードキャストで問合せを送る場合は, 応答パケットを送るときにARPでMACアドレスを調べるところで, ARPを出さずにエラーになって終わってしまうように思います。多分。 先ほどのユニキャストの理屈と同じですね。
次は,他からブロードキャストを送る場合ですけど, ブロードキャストを送る側は,255というアドレスはブロードキャストだと思って 普通と同じように送るだけですから,そこまでは問題ないでしょう。 で,問題なのは,そのブロードキャストで何らかの問合せをしたとき, その該当者が応答するのと同時に,255のマシンも応答するかもしれません。 この辺の動作は,問合せの種類によるので, 一般論では考えにくいような気がします。 問合せに応える,というパターン以外の通信もありますし。
そのときにどれか一つでもネットワーク全体に悪影響を及ぼすものがあるといけないので, 真面目に答えようとすると,ブロードキャストを使う通信の仕組みを 一通り洗い出して,どうなるか検討しないといけないでしょうね。 四の五の言わずに試してみるのが,手っ取り速いような気もします。 もちろん,本番用では危ないので, 実験用のネットワークを作って試すんですけど。
More information about text formats
実際のところは試してみないとわからないかも?
はじめまして!
間違えてブロードキャストアドレスを登録したら
ネットワークがどう動くかということですね。
実際の動きを正確に予測するのは,結構難しい問題かもしれません。
仕様で動作が定義されているとは限りませんから。
でも,とりあえず考えてみましょうか。
最初に255のマシンから通信動作を始めるのか,
つまり,255が最初にパケットを送るか,
それとも,他のマシンが255に対して通信動作を行うのか,
によって違うので,255からはじめることにしましょうか。
その場合は,255は通信相手のMACアドレスを調べるために,
ARPの問合せをブロードキャストしますが,
そこで,相手が応答するかどうかがポイントでしょう。
とりあえず,Linux 2.4とWindows XPで試してみた限りでは,
応答を返しませんから,通信できませんね。
他から255のマシンに通信動作を行うときは,
逆にそちらから255のMACアドレスを調べるために,
ARPを送るところから始めなければいけないのですが,
これも,Linux2.4とWindowsXPで試す限りは,
IPアドレスがブロードキャストの場合はARPを送りませんね。
詳しく調べたわけではありませんが,
TCPの接続動作を行うときに,相手アドレスがブロードキャストだと,
TCP/IPプロトコルソフトがエラーにしてしまうんだと思います。
ということで,通常の通信では通常のアドレスとブロードキャストを
誤認することはなく,単に通信できない,というだけみたいですね。
問題はブロードキャストですね。
ブロードキャストを用いた通信は,普通,
ブロードキャストで問合せを送り,
それに,ユニキャストで応えるというパターンが多いので,
255からブロードキャストで問合せを送る場合は,
応答パケットを送るときにARPでMACアドレスを調べるところで,
ARPを出さずにエラーになって終わってしまうように思います。多分。
先ほどのユニキャストの理屈と同じですね。
次は,他からブロードキャストを送る場合ですけど,
ブロードキャストを送る側は,255というアドレスはブロードキャストだと思って
普通と同じように送るだけですから,そこまでは問題ないでしょう。
で,問題なのは,そのブロードキャストで何らかの問合せをしたとき,
その該当者が応答するのと同時に,255のマシンも応答するかもしれません。
この辺の動作は,問合せの種類によるので,
一般論では考えにくいような気がします。
問合せに応える,というパターン以外の通信もありますし。
そのときにどれか一つでもネットワーク全体に悪影響を及ぼすものがあるといけないので,
真面目に答えようとすると,ブロードキャストを使う通信の仕組みを
一通り洗い出して,どうなるか検討しないといけないでしょうね。
四の五の言わずに試してみるのが,手っ取り速いような気もします。
もちろん,本番用では危ないので,
実験用のネットワークを作って試すんですけど。