- - PR -
全二重・半二重の混在時の通信について
1
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2008-05-23 17:35
Autoネゴと10M全二重固定の機器で通信した場合に、問題が発生する仕組みを教えてください。
ネットワーク分野ではやってはいけない常識のようですが、以下のような環境において、Autoネゴと10M全二重固定の機器を混在させた結果、レスポンス遅延や通信が不安定となる事象が発生しました。 （RTがAutoネゴ、ONUが10M全二重固定で、結果的にRTは10M半二重で通信。現在は両機器とも10M全二重固定とし解消済み） ＜ネットワーク構成＞ 複数のPC・ﾌﾟﾘﾝﾀ---SW---RT----ONU====広域ｲｰｻﾈｯﾄ====ONU---RT---SW---複数の機器 あるサイトの解説に基づくと、 半二重側（RT）は、全二重側（ONU）の送信時にはCSMA/CDを用いて送信を回避するが、全二重側（ONU）は、半二重側（RT）の状態に関わらず、いつでも送信を行うので、半二重側（RT）のパケットと衝突する可能性がある。パケット衝突が頻発する結果、遅延等の問題が発生すると解釈できます。 <http://techtarget.itmedia.co.jp/tt/news/0702/16/news01.html> ①しかし、本当にパケットが衝突する可能性があるのでしょうか？ 半二重通信といっても10BaseTの環境下では、ケーブル内の伝送路（銅線）は送信・受信で別であり、単に同時に送受信できないだけと認識しています。 少なくとも今回の構成の場合、半二重と全二重の機器は1対1で接続されており、衝突する可能性はないと思いますが、いかがでしょうか？ ②半二重側（RT）がパケット送信中に、全二重側（ONU）がパケット送信した場合、半二重側（RT）はどのような動きをしますか？ 半二重側（RT）はそのパケットを受信できないので破棄してしまい、問題が発生すると推測するのですが、いかがでしょうか？ 機器に依存するなら、一般的な機器の動作で構いませんので、上記質問についてお教え下さい。 [ メッセージ編集済み 編集者: mick 編集日時 2008-05-23 17:36 ] | ||||
|
投稿日時: 2008-05-23 22:51
通信量がある閾値までは、殆どエラーが出ません。
開通試験でのPingだけでは全く気付かないでしょう。 一般的なPingは、半二重アプリケーションですから。 半二重のルータは、受信を優先して送信を抑制した時に、衝突をカウントアップします。 「衝突回避」も衝突と言うことです。 もっと細かく言うと、送信バッファにフレームが存在するタイミングで 受信側のメディア電圧の変化を検知したら、衝突をカウントアップします。 ルータは送信バッファに送信フレームを保持して一時的に凌ぎますが、 バッファフルになると、古いフレームから破棄していきます。 このときに、インタフェース統計として送信エラーと破棄をカウントアップします。 破棄されたデータは、本来通信先で受け取る筈のものですから、 それが返ってこないので、通信先から直前のパケットを再送します。 通常のTCPでの制御のみであれば、再送は2回発生します。 アプリケーションレベルで再送を試みる設定の場合、もっと増えるでしょう。 ルータは、通常のフレームと再送フレームの受信をしなければならなくなり、 さらに送信のタイミングを逃してしまいます。 人間的に表現すれば「相手のため」の基本動作が、墓穴を掘っていることになります。 _________________ ＿福田太郎＿ | ||||
|
投稿日時: 2008-05-23 23:25
返信ありがとうございます。
興味深い内容ですね。 つまり、衝突は実際には起こっていないのに半二重側の一方的な判断で衝突にしてしまう、ということですか？ 確かに今回の事象でも受信を優先していたようで、半二重側→全二重側への通信において、全二重側→半二重側への通信と比較して圧倒的にパケットロスが発生していました。 また、TCPのセッション確立時に半二重側（実際には上記ネットワーク構成図の左側の機器）から送信したパケットがロストし、通信先から直前のパケットが再送されたため、再度同一パケットを再送しましたが、またロストし、最終的には全二重側（実際には上記ネットワーク構成図の右側の機器）から、RSTパケットが送信され、セッション確立に失敗していました。 | ||||
|
投稿日時: 2008-05-25 19:37
追加質問させていただきます。
>半二重のルータは、受信を優先して送信を抑制した時に、衝突をカウントアップします。 >「衝突回避」も衝突と言うことです。 この仕様は、イーサネットの仕様でしょうか？それとも機種依存でしょうか？ | ||||
|
投稿日時: 2008-05-27 17:03
なんか、いろんな話がごっちゃになっているような気がするのですが。 半二重は、もともとバス接続の時に使うプロトコルで、通信線を共有されていることを想定しています。 半二重、全二重側が同時にフレームを送信すると、 －半二重側は、コリジョンを検出してジャム信号を送出(でも送られるのは半二重から見て送信側の線のみ) －全二重側は、コリジョンを検出しない という動作をします。 結果として、 －半二重側から全二重へのフレームは、ジャム信号により FCS が合わなくなるので全二重側は廃棄。 半二重側は、バックオフアルゴリズムにより再送。 －全二重側から半二重へのフレームは、ジャム信号の影響を受けないので、そのまま届く。 全二重側は、そもそもコリジョンを認識していないので、再送はしない。 という動作となるのでしょう。 ジャム信号が届くのが、片方の線だけで、扱い方が半二重と全二重で異なるので、面白いことになるのですね 
バックオフの最大回数が１６回で、一回当たり数十ミリ秒は待つでしょうから、全二重->半二重でバースト転送 などをやっている間は、ほとんど半二重->全二重側は通信できないでしょう。 それで、Ethernet のレイヤーで解決できないなると、こんどは TCP やアプリケーションによる再送が行われ、結果的にどんどん遅くなることになります。 | ||||
|
投稿日時: 2008-06-02 10:15
返信いただき、ありがとうございます。
大変勉強になりました。 通信モード不一致による問題は多いにも関わらず、（少なくともネット上では）意外に、その仕組みについての情報ってないんですね。 | ||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。