PR

 疑似的にネットワーク障害(ルーターの異常など)を引き起こす方法として,コンピュータにつながっているLANケーブルを引き抜く方法が知られています。しかしこの方法を実施しても,驚くほど多数のアプリケーションは,何も起こさずにじっと待った状態のままになります。ネットワーク障害のシミュレート方法として,LANケーブルを引き抜くという方法は適切ではありません。

 この方法を好んで行うのは,だいたいにおいて,40代以上の技術者です。40代以上の技術者が新人のときにテストの手伝いを先輩からやらされていた,約20年前のネットワークというのは,今のネットワークと大きく異なります。現在のLANとは異なり,「BSC」や「HDLC」といった伝送制御手順を利用していました。ネットワークのレイヤー数も少なく,せいぜい低レベル・ドライバ+プロトコル・ドライバの2層程度でした。

 このようなネットワークであれば,ケーブルを引き抜くと,すぐに低レベル・ドライバがリンク・シグナルの落ちたことを検出し,ネットワーク・ダウンと判定します。物理的なリンク・レベルのダウンと,ソフトウエア的なネットワーク・ダウンの区別はほとんどありません。

 しかし,今のTCP/IPのネットワークは,リンク・レベルのダウンとは無関係に動作します。実際に試してみれば分かりますが,LANケーブルを抜いて,また差し直せば,大抵のアプリケーションは何事もなかったかのように処理を継続します。これはTCP層が確定応答方式でパケットの欠落を防止するように考慮しているからです。そのため,リンク・レベルのダウンがそのままネットワーク・レベルのダウンとされるわけではありません。これは,多層化することで,個々の層が独立して責務を果たすように考慮されているからです。

 従って,ルーターの異常などに伴うネットワーク障害を検出するには,アプリケーション自身による判断が必要です。この判断は多くのシステムで,タイムアウト時間として組み込まれています。ただほとんどの場合,タイムアウト時間は数分から数10分になっていると思われます。これは,業務システムの利用者の立場からすると,1ケタ以上長いと言えるでしょう。

arton(本名:田島 暁雄 / たじま あきお)
業界特化型のコンピュータ・メーカーに勤務。入社当初はメインフレームのミドルウエア開発を担当。その後,ダウンサイジングに合わせてUNIXサバー,Windowsクライアント/サーバー,組み込み機器をカバーする分散型業務シーステムの設計から実装まで幅広く担当する。JavaEE,C#,Rubyに関する複数の著書がある。2007年度マイクロソフトMVP(XML)