JP2007201740A

JP2007201740A - ネットワーク機器

Info

Publication number: JP2007201740A
Application number: JP2006016948A
Authority: JP
Inventors: Takahiro Aso; 貴宏麻生
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2006-01-25
Filing date: 2006-01-25
Publication date: 2007-08-09

Abstract

【課題】接続したい通信相手に接続できなくなる事態の発生を低減することのできるネットワーク機器を提供する。
【解決手段】同一ネットワークインタフェース上に異なるバージョンのプロトコルスタックを複数有したネットワーク機器であって、上記ネットワークインタフェース上で動作中のプロトコルスタックを検出する手段と、動作中のプロトコルスタックのうち名前解決に使用するプロトコルスタックおよび／もしくは問い合わせ先のネームサーバを決定する手段とを備える。
【選択図】図２

Description

本発明は、特定の通信相手に接続する際に名前解決を行うプロトコルスタックを一つのネットワークインタフェース上に複数持つネットワーク機器に関する。

ＯＳＩ（Open Systems Interconnection）参照モデルのネットワーク層のプロトコルであるＩＰｖ６（Internet Protocol version 6）は、現在主流のＩＰｖ４（Internet Protocol version 4）と比較してＩＰアドレス長が４倍（３２ｂｉｔ→１２８ｂｉｔ）となっている。インターネットの普及によって今後のＩＰアドレスの枯渇が懸念されるが、ＩＰｖ６は重要な解決策の一つであり、今後の普及が見込まれている。

このような背景からＩＰｖ６に対応したネットワーク機器も増えつつあり、ＩＰｖ４とＩＰｖ６とが混在した状況になっている。ＩＰｖ６に対応したネットワーク機器としては、一つのネットワークインタフェースに、例えば、ＩＰｖ４プロトコルスタック、ＩＰｖ６プロトコルスタック、ＩＰｖ４／ＩＰｖ６共用プロトコルスタックといった複数のＩＰプロトコルスタックが搭載されており、いずれかのＩＰプロトコルスタックが選択されて使用される。

一方、特定の通信相手に接続する際、人間にとって扱いやすいドメインネーム（例えば「ricoh.co.jp」）からＩＰアドレスへの変換として、選択されているＩＰプロトコルスタックに基づきリゾルバ（ＤＮＳ（Domain Name System）クライアント）からネームサーバ（ＤＮＳサーバ）へ問い合わせることによる名前解決が行われる。

なお、特許文献１には、複数のＩＰネットワークに同時接続されている際、名前解決時に接続するサーバに優先順位を設け、各サーバに再帰的に問い合わせを同報で行い、ネームサーバからの複数の回答を一定時間保管し、その中からアプリへ回答するアドレスレコードを選択する名前解決方法が開示されている。

また、特許文献２には、ネットワークドライバを複数搭載するクライアントが、接続可能な異なるアドレス体系にて、名前解決にアクセスするネームサーバに優先順位をつけて選択する手段を具備する優先選択ネームサーバシステムが開示されている。

また、特許文献３には、管理する情報のうち更新されない情報については一定時間のみ保持するネームサーバに、名前とアドレス情報との対応関係を継続的に保持させることのできる画像処理装置が開示されている。
特開２００３−２６４５７４号公報特許第３６７６７１４号公報特開２００５−９４４４６号公報

上述したように、ＩＰｖ６に対応したネットワーク機器は、一つのネットワークインタフェースに複数のＩＰプロトコルスタックが搭載され、いずれかのＩＰプロトコルスタックが選択されて使用されるものであるが、選択されているプロトコルスタックでしか名前解決を行わないため、接続したい通信相手に接続できなくなる場合があるという問題があった。例えば、ＩＰｖ６プロトコルスタックが選択されている場合にＩＰｖ４専用のネームサーバに対して名前解決を行ってしまうと、ネームサーバは自分で名前解決できない場合に上位のネームサーバを順次に辿っていくという動作を行うため、長時間にわたって名前解決の処理が完了せず、その後の処理が滞るという問題があった。ＩＰｖ４プロトコルスタックが選択されている場合にＩＰｖ６専用のネームサーバに対して名前解決を行ってしまう場合等も同様である。

なお、通常のＰＣ（Personal Computer）であれば、処理が止まっていることにユーザが気付き、問題の解決等を試みるため、その弊害はある程度食い止められる可能性がある。しかし、画像形成装置（ＭＦＰ（Multi Function Printer）等）等の組み込み型のネットワーク機器にあっては、離れた場所のＰＣ等から操作される場合が多いため、何らかの障害によって処理が止まっているとしか認識されず、後続の処理も進行することができないことから、サービス性が低下するという問題がある。

なお、ＩＰプロトコルスタックについて問題点を述べたが、その他のプロトコルスタックについても同様な問題が予想される。

一方、上述した特許文献１にあっては、異なる独立したネットワークを対象としており、同一ネットワーク内の異なるＩＰプロトコルバージョンにおける名前解決に関するものではない。

また、複数のネームサーバへ同報で名前解決要求を送信し、サーバから得られた回答の中から優先順位に従ってアプリへの回答を選択するため、ネットワーク内に無駄な問い合わせパケットが流れ、ネットワークおよびサーバに負荷がかかってしまうという問題もある。また、複数のネームサーバへ問い合わせを行うことでクライアントが名前解決に要する時間が非常に長くなり、パフォーマンス上の問題もある。

更に、複数のサーバアドレスに問い合わせを行ったとしても、通常はネームサーバ同士で再帰的に問い合わせを行うため同一の回答が得られるのが一般的であり、仮に異なる回答が得られたとしても期待する相手かどうかの判断は困難である。

また、特許文献２にあっては、異なるネットワークインタフェースで異なるネットワーク環境に対してアクセスを行う場合を前提としており、同一ネットワークインタフェース上の異なるプロトコルスタックに関するものではない。

また、特許文献３は名前登録時に関する技術であり、名前解決に関するものではない。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、接続したい通信相手に接続できなくなる事態の発生を低減することのできるネットワーク機器を提供することにある。

上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、同一ネットワークインタフェース上に異なるバージョンのプロトコルスタックを複数有したネットワーク機器であって、上記ネットワークインタフェース上で動作中のプロトコルスタックを検出する手段と、動作中のプロトコルスタックのうち名前解決に使用するプロトコルスタックおよび／もしくは問い合わせ先のネームサーバを決定する手段とを備えるネットワーク機器を要旨としている。

また、請求項２に記載されるように、請求項１に記載のネットワーク機器において、名前解決に使用するプロトコルスタックを選択可能とすることができる。

また、請求項３に記載されるように、請求項１に記載のネットワーク機器において、名前解決に使用するプロトコルスタックに優先順を設定可能とすることができる。

また、請求項４に記載されるように、請求項１に記載のネットワーク機器において、名前解決に使用するプロトコルスタックの優先順をＤＨＣＰサーバから取得したネームサーバアドレスか否かで変更することができる。

また、請求項５に記載されるように、請求項１に記載のネットワーク機器において、名前解決に使用するプロトコルスタックの優先順を名前解決できた確率に応じ変更することができる。

また、請求項６に記載されるように、請求項１に記載のネットワーク機器において、名前解決に使用するネームサーバのアドレスを選択可能とすることができる。

また、請求項７に記載されるように、請求項１に記載のネットワーク機器において、名前解決に使用するネームサーバのアドレスに優先順を設定可能とすることができる。

また、請求項８に記載されるように、請求項１に記載のネットワーク機器において、名前解決に使用するネームサーバのアドレスの優先順を名前解決できた確率に応じ変更することができる。

また、請求項９に記載されるように、同一ネットワークインタフェース上に異なるバージョンのプロトコルスタックを複数有したネットワーク機器における制御方法であって、上記ネットワークインタフェース上で動作中のプロトコルスタックを検出する工程と、動作中のプロトコルスタックのうち名前解決に使用するプロトコルスタックおよび／もしくは問い合わせ先のネームサーバを決定する工程とを備える名前解決制御方法として構成することができる。

本発明のネットワーク機器にあっては、接続したい通信相手に接続できなくなる事態の発生を低減することができる。

以下、本発明の好適な実施形態につき説明する。

＜装置構成＞
図１は本発明のネットワーク機器を画像形成装置に適用した実施形態を示すネットワーク構成図である。図１において、リゾルバを備えた画像形成装置１Ａ、１Ｂと、ＰＣ２と、ネームサーバ３Ａ〜３Ｃと、配信サーバ４と、メールサーバ５とがネットワーク６に接続されている。ここで、画像形成装置１Ａ、１ＢはＩＰｖ４／ＩＰｖ６を搭載し、ネームサーバ３ＡはＩＰｖ４／ＩＰｖ６を搭載し、ネームサーバ３ＢはＩＰｖ４を搭載し、ネームサーバ３ＣはＩＰｖ６を搭載しているものとしている。

図２は画像形成装置１（１Ａ、１Ｂ）およびネームサーバ３Ａ〜３Ｃのモジュール構成図である。図２において、画像形成装置１（１Ａ、１Ｂ）は、ユーザがタッチパネル等により操作する操作部１１と、各部を制御し各種データを処理するためのコントローラ部１２と、原稿を読み取るためのスキャナ部１３と、印刷データを出力（プリント）するためのエンジン部１４と、送受信するデータの管理や設定情報を保持するための記憶部１５と、リモートのマシンと通信を行うためのネットワークＩ／Ｆ（Interface）部１６とを備えている。また、ネームサーバ３ＡはＩＰｖ４とＩＰｖ６のアドレスレコードデータベースを備え、ネームサーバ３ＢはＩＰｖ４のアドレスレコードデータベースを備え、ネームサーバ３ＣはＩＰｖ６のアドレスレコードデータベースを備えている。

図３はプロトコルスタックの例を示す図であり、下位よりＨ／Ｗ（Hard Ware）、Ethernet（登録商標）、ＩＰｖ４／ＩＰｖ６、ＴＣＰ（Transmission Control Protocol）／ＵＤＰ（User Datagram Protocol）、Applicationの順となっている。なお、Ethernet（登録商標）を例として示しているが、無線ＬＡＮやIPover1394の場合でもよい。

図４は画像形成装置１のコントローラ部１２のソフトウェア構成図であり、動作において関連する操作部１１および記憶部１５も併せて示している。

図４において、操作制御部（ＯＣＳ:Operation Control Service）１２１は、操作部１１から、データ送信先のサーバ情報（ホスト名）、ネームサーバ情報（サーバアドレス）、名前解決に使用するプロトコル情報、ネームサーバを決定する条件、ネームサーバの取得先等を受け取る。なお、これらの情報はリモートからも設定可能である。システムコントロール部（ＳＣＳ：System Control Service）１２２は、操作制御部１２１で取得した情報を記憶部１５に保存する。

図５はデータ送信先のサーバ情報の例を示す図であり、スキャナの送信先とＦＡＸの送信先が設定された状態を示している。

図６はネームサーバ情報およびプロトコル情報等が設定されるアドレス等管理テーブルの例を示す図であり、「Record No.」、「ネームサーバアドレス」、「種別」（情報取得の種別であり、ここでは手動設定とＤＨＣＰ(Dynamic Host Configuration Protocol)からの取得とを示している。）、「プロトコルスタック」（名前解決に使用するプロトコルプロトコルスタック）のフィールドの他、後述する動作に使用する「成功数」（名前解決が成功した数）、「失敗数」（名前解決が失敗した数）、「確率」（名前解決が成功した確率（確率＝成功数／（成功数＋失敗数）により算出される値））、「使用済みフラグ」（名前解決に使用したことを示すフラグ）が設けられている。

図７はネームサーバを決定する条件およびネームサーバの取得先が設定される条件等設定テーブルの例を示す図であり、「ネームサーバを決定する条件」と「ネームサーバの取得先」のフィールドが設けられている。ネームサーバを決定する条件としては、
・プロトコルスタックによる選択
・プロトコルスタックによる優先順
・確率によるプロトコルスタック選択
・サーバアドレス直接選択
・ネームサーバによる優先順
・確率によるネームサーバ選択
等がある。ネームサーバの取得先としては、
・ＤＨＣＰサーバから得られたネームサーバを使用
・手動設定されたネームサーバアドレスを使用
等がある。

図４に戻り、ネットワーク制御部（ＮＣＳ：Network Control Service）１２３は、接続要求時に記憶部１５からネームサーバ情報、プロトコル情報、ネームサーバを決定する条件、ネームサーバの取得先を読み出し、動的にresolv.conf１２４を生成する。図８はresolv.confの例を示す図であり、名前解決を行うサーバ（server）のアドレスと、ドメイン名の後半が省略されていた場合にサーチ（search）を行うドメイン名とが含まれている。

図４に戻り、ＦＡＸアプリ１２５もしくはスキャナアプリ１２６は、データ送信に際して記憶部１５からデータ送信先のサーバ情報を取得するとともに、転送サービス部（ＤＣＳ：Delivery Control Service）１２７にデータ転送を依頼する。転送サービス部１２７はリゾルバ１２８にホスト名の名前解決を依頼し、リゾルバ１２８はresolv.conf１２４から名前解決に使用するプロトコルスタックおよびネームサーバを決定し、実際に名前解決を行う。

＜基本動作＞
図９は接続要求から接続先との通信までのコントローラ部１２における処理例を示すフローチャートである。図９において、動作を開始し（ステップＳ１０１）、ＦＡＸアプリ１２５もしくはスキャナアプリ１２６からリモートの通信相手へのホスト名を指定した接続要求があると（ステップＳ１０２）、ホスト名で接続相手が指定されているため、ホスト名をＩＰアドレスに変換するために問い合わせるネームサーバアドレスを決定する（ステップＳ１０３）。

そして、問い合わせネームサーバアドレスを決定すると、決定したネームサーバにクエリーを送信し（ステップＳ１０４）、クエリーの応答を受信する（ステップＳ１０５）。次いで、名前解決が成功したか否か判断し（ステップＳ１０６）、失敗した場合（ステップＳ１０６のＮｏ）はクエリー失敗数をカウントアップし（ステップＳ１０７）、問い合わせネームサーバの決定（ステップＳ１０３）に戻る。クエリー失敗数は図６に示したアドレス等管理テーブルの「失敗数」フィールドに記録し、「確率」についても算出し直す。

一方、名前解決が成功した場合（ステップＳ１０６のＹｅｓ）は、クエリー成功数をカウントアップし（ステップＳ１０８）、接続先との通信を行い（ステップＳ１０９）、処理を終了する（ステップＳ１１０）。クエリー成功数は図６に示したアドレス等管理テーブルの「成功数」フィールドに記録し、「確率」についても算出し直す。

図１０は図９における問い合わせネームサーバ決定（ステップＳ１０３）の処理例を示すフローチャートである。図１０において、処理を開始すると（ステップＳ２０１）、動作中のＩＰプロトコルスタックを確認し（ステップＳ２０２）、複数のＩＰプロトコルスタックが動作中であるか否か判断する（ステップＳ２０３）。動作中のＩＰプロトコルスタックはＯＳ（Operating System）から知ることができる。

複数のＩＰプロトコルスタック（例えばＩＰｖ４とＩＰｖ６）が動作中である場合（ステップＳ２０３のＹｅｓ）は、指定された条件にてネームサーバの選択を行う（ステップＳ２０４）。一つのＩＰプロトコルスタックが動作中である場合（ステップＳ２０３のＮｏ）は、動作中のＩＰプロトコルスタックに対応するサーバアドレスを選択する（ステップＳ２０５）。

次いで、対象となるネームサーバを確認し（ステップＳ２０６）、複数の選択肢があるか否か判断する（ステップＳ２０７）。そして、複数の選択肢がなく条件に一致するネームサーバが一意に検索された場合（ステップＳ２０７のＮｏ）はそのネームサーバを問い合わせネームサーバを決定し（ステップＳ２０９）、処理を終了する（ステップＳ２１０）。

複数の選択肢がある場合（ステップＳ２０７のＹｅｓ）は取得先（ＤＨＣＰもしくは手動設定）を確認し（ステップＳ２０８）、取得先に応じて問い合わせネームサーバを決定し（ステップＳ２０９）、処理を終了する（ステップＳ２１０）。複数の選択肢がある場合の問い合わせネームサーバの決定（ステップＳ２０９）としては、取得先が「ＤＨＣＰサーバから得られたネームサーバを使用」する旨の設定になっている場合は、図６に示したアドレス等管理テーブルの種別が「ＤＨＣＰ」のネームサーバを選択し、「手動設定されたネームサーバアドレスを使用」する旨の設定になっていた場合は、種別が「手動設定」のネームサーバを選択する。ただし、ＤＨＣＰサーバから取得したサーバアドレスが複数存在していた場合は、ＤＨＣＰサーバ側で指定されている順でネームサーバを決定する。手動設定されたネームサーバアドレスが複数存在していた場合は、登録が新しい順（テーブルの逆順）でネームサーバを決定する。

＜ネームサーバ選択の処理例１＞
図１１は図１０におけるネームサーバ選択（ステップＳ２０４）の処理例を示すフローチャートであり、ネームサーバを決定する条件が「プロトコルスタックによる選択」であった場合の処理である。

図１１において、処理を開始すると（ステップＳ３０１）、ＩＰプロトコルスタックの選択を確認し（ステップＳ３０２）、ＩＰｖ４のみであるか否か判断する（ステップＳ３０３）。

そして、ＩＰｖ４のみである場合（ステップＳ３０３のＹｅｓ）はＩＰｖ４プロトコルスタックに対応するサーバアドレスを選択し（ステップＳ３０４）、ＩＰｖ４のみでない場合（ステップＳ３０３のＮｏ）はＩＰｖ６プロトコルスタックに対応するサーバアドレスを選択し（ステップＳ３０５）、処理を終了する（ステップＳ３０６）。

例えば、ＩＰｖ４プロトコルが選択されていた場合、図６に示したアドレス等管理テーブルでは、レコード（Record No.）「１」と「２」のものが選択され、それらに対応するネームサーバアドレス「192.168.1.2」と「192.168.2.2」が選択される。

＜ネームサーバ選択の処理例２＞
図１２はネームサーバ選択（ステップＳ２０４）の他の処理例を示すフローチャートであり、ネームサーバを決定する条件が「プロトコルスタックによる優先順」であった場合の処理である。

図１２において、処理を開始すると（ステップＳ４０１）、ＩＰプロトコルスタックの優先順を確認し（ステップＳ４０２）、ＩＰｖ４優先であるか否か判断する（ステップＳ４０３）。

そして、ＩＰｖ４優先である場合（ステップＳ４０３のＹｅｓ）はＩＰｖ４プロトコルスタックに対応するサーバアドレスを選択し（ステップＳ４０４）、ＩＰｖ４優先でない場合（ステップＳ４０３のＮｏ）はＩＰｖ６プロトコルスタックに対応するサーバアドレスを選択し（ステップＳ４０５）、処理を終了する（ステップＳ４０６）。

例えば、ＩＰｖ４プロトコルが優先されていた場合、図６に示したアドレス等管理テーブルでは、レコード「１」と「２」のものが優先され、レコード「１」と「２」のネームサーバでクエリー失敗した場合にレコード「３」と「４」が使用される。

＜ネームサーバ選択の処理例３＞
図１３はネームサーバ選択（ステップＳ２０４）の他の処理例を示すフローチャートであり、ネームサーバを決定する条件が「確率によるプロトコルスタック選択」であった場合の処理である。

図１３において、処理を開始すると（ステップＳ５０１）、アドレス等管理テーブルの「確率」フィールドを確認し（ステップＳ５０２）、確率により一意に決定できるか否か判断する（ステップＳ５０３）。

そして、一意に決定できる場合（ステップＳ５０３のＹｅｓ）は決定したプロトコルスタック（確率の最も良いプロトコルスタック）に対応するサーバアドレスを選択し（ステップＳ５０４）、決定できない場合（ステップＳ５０３のＮｏ）はデフォルトでＩＰｖ４プロトコルスタックに対応するサーバアドレスを選択し（ステップＳ５０５）、処理を終了する（ステップＳ５０６）。

例えば、図６に示したアドレス等管理テーブルでは、選択されるのはレコード「１」と「２」に対応するＩＰｖ４プロトコルスタックとなる。ただし、一度もクエリーが行われていない場合もしくは同率のプロトコルスタックが複数存在する場合は、デフォルトではＩＰｖ４プロトコルのネームサーバが優先されるものとする。なお、デフォルトのプロトコルスタックの選択も可能とする。

＜ネームサーバ選択の処理例４＞
図１４はネームサーバ選択（ステップＳ２０４）の他の処理例を示すフローチャートであり、ネームサーバを決定する条件が「サーバアドレス直接選択」であった場合の処理である。

図１４において、処理を開始すると（ステップＳ６０１）、ネームサーバの選択を確認し（ステップＳ６０２）、そのネームサーバに決定して処理を終了する（ステップＳ６０３）。

＜ネームサーバ選択の処理例５＞
図１５はネームサーバ選択（ステップＳ２０４）の他の処理例を示すフローチャートであり、ネームサーバを決定する条件が「ネームサーバによる優先順」であった場合の処理である。

図１５において、処理を開始すると（ステップＳ７０１）、ネームサーバの優先順を確認する（ステップＳ７０２）。次いで、優先ネームサーバを決定し（ステップＳ７０３）、使用済フラグがＯＮであるか否か判断し（ステップＳ７０４）、ＯＮである場合（ステップＳ７０４のＹｅｓ）はネームサーバの優先順の確認（ステップＳ７０２）に戻る。

使用済フラグがＯＮでない場合（ステップＳ７０４のＮｏ）は優先ネームサーバの使用済フラグをＯＮに設定し（ステップＳ７０５）、処理を終了する（ステップＳ７０６）。

すなわち、クエリー失敗した際に次の優先順位のネームサーバが選ばれるよう、一度使用されたネームサーバには使用済フラグを設定することで、次回のネームサーバ選択時にはスキップされることになる。なお、クエリーが成功するか全てのサーバに対してクエリーが失敗した場合、使用済フラグは解除される。

＜ネームサーバ選択の処理例６＞
図１６はネームサーバ選択（ステップＳ２０４）の他の処理例を示すフローチャートであり、ネームサーバを決定する条件が「確率によるネームサーバ選択」であった場合の処理である。

図１６において、処理を開始すると（ステップＳ８０１）、アドレス等管理テーブルの「確率」フィールドを確認し（ステップＳ８０２）、確率により一意に決定できるか否か判断する（ステップＳ８０３）。

そして、一意に決定できる場合（ステップＳ８０３のＹｅｓ）は決定したサーバアドレス（確率の最も良いサーバアドレス）を選択し（ステップＳ８０４）、決定できない場合（ステップＳ８０３のＮｏ）はデフォルトでＩＰｖ４のネームサーバを選択し（ステップＳ８０５）、処理を終了する（ステップＳ８０６）。

例えば、図６に示したアドレス等管理テーブルでは、選択されるのはレコード「１」のネームサーバとなる。ただし、一度もクエリーが行われていない場合もしくは同率のネームサーバが複数存在する場合は、デフォルトではＩＰｖ４プロトコルのネームサーバが優先されるものとする。なお、デフォルトのプロトコルスタックの選択も可能とする。

＜まとめ＞
本発明では、複数のプロトコルスタックを有する場合に異なるバージョンのネームサーバアドレスに対して問い合わせできることにより、いずれのプロトコルスタックにおいても名前解決を行うことができる。

また、名前解決に使用するプロトコルスタック（問合せ先サーバアドレス）をユーザが選択できることにより、ネットワーク環境に応じたクエリー設定を行うことが可能となる。

また、名前解決に使用するプロトコルスタック（問合せ先サーバアドレス）に優先順位を設けることにより、ネットワーク環境に応じたクエリー設定を行うことが可能となり、サーバが存在しない場合にも優先順位によりクエリーを継続することができる。

また、名前解決に使用するサーバアドレスの取得先に基づいて優先順位を変更することにより、ネットワーク環境に応じたクエリー設定が可能となる。例えば、ＤＨＣＰサーバから取得したアドレスを優先にすることで、ネットワーク管理者の管理意図に合わせて動作することができるようになる。

また、名前解決成功可否情報を管理することで、名前解決による時間を削減することができるとともに、ユーザによる設定が不要となる。

また、前述した特許文献１のように複数のネームサーバへ同報送信するのではなく、送信先のサーバアドレスのプロトコルスタックに優先順位を設けることで問い合わせ先サーバを選択しており、こうして選択したサーバにのみ問い合わせを行うことから、再帰的な問い合わせを行わず、無駄な問い合わせパケットが送信されないため、ネームサーバやネットワークに掛かる負荷を低減することができる。

また、指定したネームサーバが存在しない場合にのみ次の優先順位のサーバへ問い合わせを行うようにしているため、無駄なパケットが送信されず、ネットワークトラフィックが増大することがなくなる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

本発明のネットワーク機器を画像形成装置に適用した実施形態を示すネットワーク構成図である。画像形成装置およびネームサーバのモジュール構成図である。プロトコルスタックの例を示す図である。画像形成装置のコントローラ部のソフトウェア構成図である。データ送信先のサーバ情報の例を示す図である。アドレス等管理テーブルの例を示す図である。条件等設定テーブルの例を示す図である。 resolv.confの例を示す図である。接続要求から接続先との通信までのコントローラ部における処理例を示すフローチャートである。問い合わせネームサーバ決定の処理例を示すフローチャートである。ネームサーバ選択の処理例を示すフローチャート（その１）である。ネームサーバ選択の処理例を示すフローチャート（その２）である。ネームサーバ選択の処理例を示すフローチャート（その３）である。ネームサーバ選択の処理例を示すフローチャート（その４）である。ネームサーバ選択の処理例を示すフローチャート（その５）である。ネームサーバ選択の処理例を示すフローチャート（その６）である。

符号の説明

１、１Ａ、１Ｂ画像形成装置
１１操作部
１２コントローラ部
１２１操作制御部
１２２システムコントロール部
１２３ネットワーク制御部
１２４ resolv.conf
１２５ＦＡＸアプリ
１２６スキャナアプリ
１２７転送サービス部
１２８リゾルバ
１３スキャナ部
１４エンジン部
１５記憶部
１６ネットワークＩ／Ｆ部
２ＰＣ
３Ａ〜３Ｃネームサーバ
４配信サーバ
５メールサーバ
６ネットワーク

Claims

同一ネットワークインタフェース上に異なるバージョンのプロトコルスタックを複数有したネットワーク機器であって、
上記ネットワークインタフェース上で動作中のプロトコルスタックを検出する手段と、
動作中のプロトコルスタックのうち名前解決に使用するプロトコルスタックおよび／もしくは問い合わせ先のネームサーバを決定する手段とを備えたことを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
名前解決に使用するプロトコルスタックを選択可能としたことを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
名前解決に使用するプロトコルスタックに優先順を設定可能としたことを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
名前解決に使用するプロトコルスタックの優先順をＤＨＣＰサーバから取得したネームサーバアドレスか否かで変更することを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
名前解決に使用するプロトコルスタックの優先順を名前解決できた確率に応じ変更することを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
名前解決に使用するネームサーバのアドレスを選択可能としたことを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
名前解決に使用するネームサーバのアドレスに優先順を設定可能としたことを特徴とするネットワーク機器。
請求項１に記載のネットワーク機器において、
名前解決に使用するネームサーバのアドレスの優先順を名前解決できた確率に応じ変更することを特徴とするネットワーク機器。
同一ネットワークインタフェース上に異なるバージョンのプロトコルスタックを複数有したネットワーク機器における制御方法であって、
上記ネットワークインタフェース上で動作中のプロトコルスタックを検出する工程と、
動作中のプロトコルスタックのうち名前解決に使用するプロトコルスタックおよび／もしくは問い合わせ先のネームサーバを決定する工程とを備えたことを特徴とする名前解決制御方法。