JP2013229935A - ネットワーク通信装置及び方法とプログラム - Google Patents

Abstract

【課題】ＩＰｖ６プロトコルを利用してネットワーク上の機器と通信する際のパケットのフィルタリングを実現し、またトラフィックを軽減する。
【解決手段】ＰＣ上で動作するプリンタドライバ１０において、通信相手の名前と名前解決したアドレスのうち、実際に通信に成功したアドレスを関連付けて記憶し、以降の同一通信相手との通信には記憶しておいたアドレスを使用する。
【選択図】図１

Description

本発明は、例えばPC（パーソナルコンピュータ）上で動作する、ネットワーク上の機器との通信機能に関する。特に、通信プロトコルとしてＩＰｖ６(Internet Protocol Version 6)を利用する通信機能に関する。

現行のインターネットプロトコル（ＩＰｖ４）のアドレスが枯渇しつつあることを受け、アドレス空間の増大、セキュリティ機能の追加、優先度に応じたデータの送信などの改良を施した次世代インターネットプロトコルとしてＩＰｖ６が実用になり始めている。ＩＰｖ６プロトコルでは一つのネットワークインターフェイスに複数のアドレスが割り当て可能な仕様となっている。たとえば、割り当てられるアドレスとしてリンクローカルユニキャストアドレス（以下リンクローカルアドレスと称する）、グローバルユニキャストアドレス（以下グローバルアドレスと称する）などが知られている。さらに、グローバルアドレスとして複数のアドレスを割り当てることができるため、ひとつのホストに対してＩＰｖ４アドレスと複数のＩＰｖ６アドレスとがＤＮＳ（Domain Name System）サーバへ登録される場合がある。

通信相手を特定する為には通常「名前」と呼ばれるＦＱＤＮ（Fully Qualified Domain Name）が用いられている。なおＦＱＤＮとは、ＤＮＳのドメインの階層構造に沿ってルートから表示したホスト名あるいはドメイン名である。ＦＱＤＮ のことを以下では単に「名前」と呼ぶことがある。ＤＮＳサーバに対して名前を指定してバイナリアドレスを問い合わせると複数のＩＰｖ６が取得されることがある。これらのアドレスには問い合わせ元のＰＣから全て到達可能であるとは限らない。その為、ＩＰｖ６を使ったTCP通信においてはＤＮＳを使った名前解決の結果として得られる複数のアドレスに対して順次接続試行を行い接続が成功した時点でのアドレスを相手アドレスとして使用することになる。ＩＰｖ６を使ったUDP通信ではなおさらアプリケーションが通信相手に対してパケット再送などの手法を使って到達性を確認しなければならない為、これも本質的にTCP通信と同じように順次複数のアドレスに対してパケットを送信することを試みなければならない。この様に、ＩＰｖ６通信は本質的に複数アドレスに伴うネットワークトラフィックの増大と接続までの試行時間の増大をもたらす。

さらに相手アドレスの対向である自アドレスとしても同様に複数アドレスが存在する。通信相手のアドレスが決まると、そのアドレスに対応する自アドレスはRFC3484（ "Default Address Selection for Internet Protocol version 6(IPv6)") として既定されているアルゴリズムに則り選択されることになっている。このアドレス選択アルゴリズムは通常プロトコルスタックと呼ばれるOS（Operating System）に近いプログラム内で実行されるため、アプリケーションプログラムは選択される自アドレスに関して関与できない。

上記のような複数のＩＰｖ６アドレスが2つの通信端点それぞれに存在することによって特にUDPプロトコルを使った通信を行う場合に以下に示すような状況が発生する。通信端点Ａ，Ｂ共に自身のＩＰｖ６アドレスを３つずつ保持しておりそれぞれ、Addr_A1,Addr_A2,Addr_A3と Addr_B1,Addr_B2,Addr_B3とする。このうち通信端点Ｂのアドレスのうち２つのアドレスAddr_B1,Addr_B2がＤＮＳに登録されているとする。

図３（Ａ）に示す様に通信端点Ａが通信端点Ｂに対して通信を開始する場合、まずはＤＮＳに対して通信端点Ｂの名前（ここでは"通信端点Ｂ"という名前であるとする）を指定して名前解決を依頼（クエリ）する。ＤＮＳサーバでは名前解決の結果として２つのアドレス（Addr_B1,Addr_B2）を通信端点Ａに対して返却（レスポンス）する。

名前解決の結果を受け取った通信端点ＡはAddr_B1に向けてリクエストを送信したところ、通信端点Ｂに到達したとする。通信端点Ｂはリクエストに対応したレスポンスを返信するが、このとき通信端点はリクエストの送信元アドレスとしてAddr_A1を知ったのでこのアドレスに対してレスポンスを返信する。すると前述のRFC3484に規定されているアドレス選択アルゴリズムが機能し、通信端点Ｂの保持する３つのアドレスのうち最適なアドレスとしてAddr_B1ではなくAddr_B3が選択されることがある。このようにして通信端点ＢからのレスポンスはAddr_B3から通信端点ＡのAddr_A1に向けて送出される。通信端点Ａの側に立つと、未知のアドレスからデータが送られてくるという状況になる。

通信端点Ａがリクエストを送出した相手が通信端点Ｂのみであることが確定している場合には未知のアドレスからのデータを「通信端点Ｂから送られてきたレスポンスである」と判断できる場合がある。しかし、図３（Ｂ）のように通信端点Ａからほぼ同時に通信端点Ｂと通信端点Ｃの2つの相手にリクエストを送出する場合を考えてみると上記の判断が不可能であることがわかる。図３（Ｂ）における通信端点Ａ、通信端点Ｂ、通信端点Ｃのアドレスは各々Addr_A1,Addr_A2,Addr_A3とAddr_B1,Addr_B2,Addr_B3とAddr_C1,Addr_C2,Addr_C3であるとする。さらに、通信端点ＢのアドレスのうちＤＮＳサーバに登録されているアドレスはAddr_B1,Addr_B2であり、同様に通信端点ＣのそれはAddr_C1,Addr_C2であるとする。通信端点Ａは通信端点Ｂと通信端点Ｃの名前をＤＮＳサーバに問い合わせ、先に説明した各端点あたり2つのアドレスをレスポンスとして受け取っているものとする。ここで通信端点Ａは通信端点Ｂと通信端点Ｃにリクエストを送出し、通信端点ＢはAddr_B3からAddr_A1に向けてレスポンスを送出し、通信端点ＣはAddr_C3からAddr_A1に向けてレスポンスを送出したとする。

通信端点Ａは見知らぬアドレスAddr_B3とAddr_C3からデータを受信することになる。この２つの受信データは通信端点Ｂと通信端点Ｃのいずれから送信されてきたレスポンスデータであるのか判断できない。リクエストの送信先アドレスから必ずレスポンスが送り返されてくることがあてにできるＩＰｖ４のようなプロトコルの場合は通信の両端点のポート番号も含んだアドレスの組によって通信相手が特定できるためこのような問題は起きない。このような状況ではレスポンスパケットの送信元アドレスをリクエストパケットの送信先アドレスと一致しない場合にはその受取を拒否するといアドレスに基づくパケットフィルタリングが行えなくなるというセキュリティ上の問題が発生する。

すなわち、見知らぬアドレスから送られてきたデータパケットは何らかのリクエストパケットに対する正規のレスポンスである可能性があるためフィルタリングして破棄することはできない。そのため、いったんどんなパケットも受信しなければならないということを意味する。

ＤＮＳサーバへの名前解決に伴うトラフィックの増加、処理の遅延を改善する目的で、ＩＰｖ４とＩＰｖ６のアドレスが登録されているサーバへのアクセスにいずれのプロトコルを用いるかを過去の実績に基づいて決定する方法がある（例えば特許文献１参照）。特許文献１で開示されている従来の技術は主に、ＩＰｖ４とＩＰｖ６が混在する状況を想定している。アクセスしようとするサーバプロセスと過去に通信が可能であったIPプロトコルをサーバプロセスと関連付けてキャッシュしておき、次回のアクセスの再にはそのIPプロトコルおよび対応するアドレスを利用しようとするものである。この従来技術ではＤＮＳサーバへのアクセスを低減すること、及びサーバプロセスがＤＮＳサーバに登録されているプロトコルアドレスの全てでは待ちうけていない場合に無駄なアドレスでのアクセス試行を減じることに効果を発揮する。

特開2007-19612号公報

しかし特許文献１が開示する発明によっても、サーバプロセスからの応答が未知のアドレスから送られてくるという状況では従来技術はキャッシュそのものが行われず、やはり以下の問題を解決することはできない。
1. 送信先として選択したアドレス以外からの応答データを基本的に受信しなければならない。すなわちアドレスによるパケットフィルタリングを解除しなければならないというセキュリティ面での問題がある。
2. ＩＰｖ４プロトコルとＩＰｖ６プロトコルの両方のアドレスを使って通信を行うアプリケーションではＤＮＳサーバへの名前解決の問い合わせ回数が増加する。これがトラフィックを増加させ、また応答時間を遅延させる。
3. ひとつの通信端点について複数のＩＰｖ６アドレスがＤＮＳサーバに登録されている場合には、複数のアドレスすべてでパケットの送信を行う可能性がある。すなわちトラフィックが増大する。

本発明は上記問題を解決することを目的とする。そのため、本発明は、複数のアドレスが付与されたネットワーク機器とネットワークを介して通信するデータ通信装置であって、
送信先のネットワーク機器に対応するアドレスを取得する取得手段と、
取得された前記アドレスに対し、送信データを前記送信データの識別情報とともに送信する送信手段と、
識別情報を含む応答データを受信する受信手段と、
前記応答データの識別情報と前記送信データの識別情報とが同じでない場合には前記応答データを要求元に引き渡さず、前記応答データの識別情報と前記送信データの識別情報とが同じである場合には前記応答データを前記要求元に引き渡す応答処理手段と、を有し、
前記応答処理手段は、前記応答データの識別情報と前記送信データの識別情報とが同じである場合には、前記送信データの送信先のアドレスまたは前記応答データの送信元のアドレスと、前記送信先のネットワーク機器とを対応づけて記憶手段に記憶する。

本発明によればアプリケーションは上記課題を解決するという効果を提供することができる。すなわち、アドレスによるパケットフィルタリングを解除しなければならないというセキュリティ面での問題を解消できる。また、ＩＰｖ４プロトコルとＩＰｖ６プロトコルの両方のアドレスを使って通信を行うアプリケーションでも、トラフィックの増大、応答時間を遅延を防止できる。また、ひとつの通信端点について複数のＩＰｖ６アドレスがＤＮＳサーバに登録されている場合にも、トラフィックの増大を抑制できる。

実施形態におけるプリンタドライバのブロック図である。 実施形態におけるPCの構成を示すブロック図である。 （Ａ）ＩＰｖ６アドレスをハンドリングする通信端点とＤＮＳサーバの関係を示す図である。（Ｂ）ＩＰｖ６アドレスをハンドリングする複数の通信端点間で使用されるアドレスの関係を示す図である。 （Ａ）実施形態におけるデータ取得処理を示すフローチャートである。（Ｂ）実施形態におけるリクエスト発行処理を示すフローチャートである。（Ｃ）実施形態におけるレスポンス受領処理を示すフローチャートである。 実施形態における送受信処理を示すフローチャートである。 （Ａ）実施形態における通信相手アドレス取得処理を示すフローチャートである。（Ｂ）実施形態における通信相手アドレス登録処理を示すフローチャートである。 （Ａ）実施形態におけるリクエストデータの構造を示した図である。（Ｂ）実施形態におけるレスポンスデータの構造を示した図である。

図２は本発明をプリンタドライバに適用した際にアプリケーションプログラムにロードされて動作するデータ通信装置としてのＰＣの構成を示すブロック図である。このプリンタドライバがインストールされたＰＣは、プリンタを制御する印刷制御装置として機能する。ＰＣのオペレーティングシステム（ＯＳ）はＲＡＭ４、ＨＤＤ５あるいは後述のディスクドライブ装置の記憶媒体のいずれかの記憶手段に格納されておりＣＰＵ３により実行される。さらに、ＯＳはプリンタドライバの依頼により表示装置６に表示を行い、入力装置７からのユーザの入力を取り込んでプリンタドライバに通知することを担っている。さらに、ＯＳは通信部８を制御し、通信部８で接続された周辺装置の他、周辺装置９の制御、入出力を行いプリンタドライバとのデータの入出力を行っている。制御対象の周辺装置には、ＰＣカード、各種ディスクドライブ装置、プリンタ、ネットワークカード等がある。さらにＯＳはファイルシステム機能を提供しており、ファイルの記憶媒体は図２のＨＤＤ５、ＲＡＭ４に限らず、通信部８を介して接続されたネットワーク上の他のＰＣも含めた外部記憶装置も含むものである。ＯＳおよびプリンタドライバはＰＣ上のシステムバス１、２を通じて互いに連結されたハードウエアモジュール群のデータを授受している。

プリンタドライバはＯＳが提供しているアプリケーションプログラムインターフェース（API）を通じてＰＣ上のリソースにアクセスしたりＯＳの提供する機能を使用したりする。プリンタドライバはアプリケーションプログラムにロードされて印刷データを渡され、それをプリンタが理解できる言語に翻訳することが主な処理である。加えてプリンタドライバは、使用者にプリンタの装備しているステープル装置、スタッカ装置、搭載している用紙トレイなどの状況を取得して表示する機能を提供している。さらに、プリンタドライバは、プリンタ内部に蓄積されている印刷待ちのジョブリストを取得して表示する機能も提供している。

プリンタドライバは、ＲＡＭ４、ＨＤＤ５あるいは後述のディスクドライブ装置の記憶媒体のいずれかの記憶手段に格納されており、ＣＰＵ３により実行される。さらにプリンタドライバはＯＳが提供するファイルシステムに記憶されているファイルを参照する。以下のプリンタドライバの構成及び動作の説明においては、印刷データの翻訳に関する機能の詳細説明は割愛する。本実施形態のプリンタドライバは使用者が指定した通信相手のネットワーク機器として、ネットワークプリンタや複写機等を想定している。これらネットワークプリンタや複写機等をまとめてプリンタと称する。以下の説明においては、これらプリンタにネットワークを介してアクセスし、プリンタの機種名、プリンタに搭載された機能リスト、プリンタ内部の印刷ジョブリストを取得して、図２の表示装置６に表示する機能に関して詳しく説明する。

図１は本発明のプリンタドライバの構成を示すブロック図である。プリンタドライバは、アプリケーションプログラム等によって作成されたデータを、ユーザが指定したプリンタが解釈実行可能なプリンタ記述言語に翻訳し、翻訳したデータを当該プリンタに送信する。送信されるデータはここでは一般的には送信データと呼ぶが、プリンタに送られる前述の翻訳したデータについては印刷データとも呼ぶ。プリンタドライバ１０は表示部５０、入力部６０、アクセスロジック部２０、トランスポート部３０、ドライバロジック部４０を備えている。最初にプリンタドライバの内部に存在する３つの機能ブロックの定義を行う。

ドライバロジック部４０は、アクセスロジック部２０に対してプリンタの名前を指定して情報の取得を指示する機能ブロックである。ドライバロジック部４０は、プリンタドライバ１０の印刷データの翻訳処理とＰＣの表示装置上に画面を表示する。また、使用者からのプリンタの選択手段、選択したプリンタの機能を取得する指示手段の制御とプリンタから取得した情報の画面への表示を担っている。さらに後述のアクセスロジック部に対してプリンタの名前を指定して所望の情報を取得するように要求を行い、結果を取得する処理も行っている。

なおアクセスロジック部２０は、送信データに基づいてリクエストデータを作成し、ドメイン名やホスト名（すなわちＦＱＤＮ）で指定されるリクエストの送信先を指定してトランスポート部に対しリクエスト送信依頼を行う処理を司るブロックである。リクエスト送信先としてはＦＱＤＮだけでなく、ＩＰｖ４やＩＰｖ６（インターネットネットプロトコルバーション６）のバイナリアドレス、コンピュータ名等の形式で指定することができるが、アクセスロジック部２０は、少なくともＦＱＤＮを指定する。

トランスポート部は依頼されたリクエストデータを依頼された送信先に送出し、それに対するレスポンスを受け取ってアクセスロジック部に引き渡す機能ブロックである。トランスポート部は、送信を依頼されたリクエストの内容およびレスポンスの内容に関して一切の知識を有しないものとする。さらにトランスポート部はＦＱＤＮで指定された送信先のバイナリアドレスを特定する目的でＤＮＳサーバへの問い合わせを行う。

プリンタドライバ１０はネットワーク上に存在するＤＮＳサーバにアクセスをおこなう。ＤＮＳサーバに対してプリンタドライバが通信対象としているプリンタのＦＱＤＮを指定し、応答としてそのプリンタに割り当てられているアドレスを受け取る。

入力部６０は図２の入力装置７を介して使用者の入力を受取りドライバロジック部に引き渡す。入力される情報として、通信相手であるプリンタのＦＱＤＮと取得開始指示とが渡される。表示部５０は図２の表示装置６に対して表示すべきデータを作成して表示させる処理を司る。表示内容はプリンタから取得した機種名、搭載された機能リスト、プリンタ内の印刷ジョブリストである。

ドライバロジック部４０は入力部６０から渡されたプリンタのＦＱＤＮとアドレスの取得開始指示をアクセスロジック部２０に引き渡す。

アクセスロジック部２０は、リクエストＩＤ生成部２０１、通信相手名−リクエストＩＤ関連記憶部２０２、リクエストＩＤ−リクエスト関連記憶部２０３と制御部２００とを備えている。アドレスの取得開始指示が与えられると、制御部２００はリクエストＩＤ生成部２０１にリクエストＩＤの生成要求を出す。リクエストＩＤ生成部２０１は制御部２００からの要求に応じてユニークなＩＤを生成して返す。リクエストＩＤは、比較的長い周期で巡回するＩＤを用いている。このため、あるプリンタに対して送信する際に生成されたリクエストＩＤと同じリクエストＩＤが、同一装置への別のリクエストや他のプリンタへのリクエストに同時に用いられる可能性は非常に低い。逆に言うと、リクエストＩＤの周期としては、同一のリクエストＩＤが同一システム内で同時に使用されることがない程度の長さが選択される。ひとつのリクエストＩＤは、最大で、（送信先のホスト名（本例ではプリンタ）に対してＤＮＳに登録されたアドレス数）×（応答待ち時間）＋（スリープからの覚醒時間）＋（応答所要時間）程度の時間にわたり使用される可能性がある。この時間を最大ＩＤ利用時間とすれば、リクエストＩＤの周期＞最大ＩＤ利用時間／（送信要求が発生する平均時間間隔）が満たされれば、リクエストＩＤのユニークさは保たれる。

通信相手名−リクエストＩＤ関連記憶部２０２は、制御部２００から通信相手のＦＱＤＮとリクエストＩＤを渡され、それらを関連付けて記憶する。さらに通信相手名−リクエストＩＤ関連記憶部２０２は、リクエストＩＤを指定されて関連つけられているＦＱＤＮを検索して返却する機能を有している。リクエストＩＤ−リクエスト関連記憶部２０３は制御部からリクエストＩＤとリクエストデータを渡され、それらを関連付けて記憶する。さらにリクエストＩＤ−リクエスト関連記憶部２０３は、指定されたリクエストＩＤに関連つけられているリクエストデータを検索して返却する機能を有している。

制御部２００は、リクエストＩＤ生成部２０１と、通信相手名−リクエストＩＤ関連記憶部２０２と、リクエストＩＤ−リクエスト関連記憶部２０３と、トランスポート部３０とを制御し、通信相手のプリンタから必要な情報を取得する。

また制御部２００は外部に存在するＤＮＳサーバ７０やプリンタ８０のネットワーク上の位置（アドレス）詳細については関知していない。制御部２００はトランスポート部３０に対してリクエストデータと呼ばれるプリンタとの間で取り決めたプロトコルデータを作成する。プロトコルデータには通信相手を一意に特定するためのユニークなＩＤであるリクエストＩＤが埋め込まれている。送信内容であるリクエストデータとその送り先であるところの通信相手名（ＦＱＤＮ）が制御部２００からトランスポート部３０に対して引き渡されて送信依頼がなされる。

トランスポート部３０は、名前解決部３０１、通信相手名−アドレス関連記憶部３０４、リクエスト送信部３０２、レスポンス受信部３０３を備えている。リクエスト送信部３０２は入力としてリクエストデータとその送信先であるプリンタの名前すなわちＦＱＤＮを受け取る。リクエスト送信部３０２はその後、名前解決部３０１に依頼して受け取ったＦＱＤＮをアドレスに変換させる。名前解決部３０１は、リクエスト送信部３０２から引き渡されたＦＱＤＮに関連づけられたアドレスを通信相手名−アドレス関連記憶部３０４により検索させ、関連するアドレスが見つかればそのアドレスをリクエスト送信部３０２に引き渡す。通信相手名−アドレス関連記憶部３０４は、ＦＱＤＮからアドレスを検索して返す名前解決部３０１の機能の実質的実行部分として機能している。リクエスト送信部３０２は、こうして送り先のＦＱＤＮに対応したアドレス（通信相手アドレス）を取得する。名前解決に指定するアドレスはＩＰｖ４とＩＰｖ６のどちらも用いることができる。なお前述したように、ＩＰｖ６では一つの名前（ＦＱＤＮ）に対して複数のアドレスが付与され得る。

リクエスト送信部３０２は、取得した通信相手アドレスに対して依頼されたリクエストデータをＵＤＰ(User Datagram Protocol)を使って送信する。このとき、名前解決部３０１から返されたアドレスが複数ある場合には各アドレスに対してリクエストデータを送信して一定時間経過後までに応答がなければ再送する処理を行う。

レスポンス受信部３０３は、プリンタからの応答データを受信してレスポンスデータとしてアクセスロジック部２０に引き渡す機能を提供している。その際、応答データの送信元アドレスも取得して応答データとともに引き渡す。なおプリンタはレスポンスデータをUDPを使って送信する。リクエストとは、パケットに含まれるリクエストＩＤにより対応付けられる。

図７（Ａ）、図７（Ｂ）でプリンタドライバ１０とプリンタとの間で授受されるリクエストデータ７０１とレスポンスデータ７０２のパケット構造を説明する。図７（Ａ）がプリンタドライバ１０からプリンタに向けて送出されるリクエストデータ７０１である。固定サイズのパケットヘッダと可変長のリクエストボディから成っている。パケットヘッダはレスポンスデータ７０２とフィールドの構成については共通である。ただしリクエストデータ７０１では「タイプ」部分にリクエストを意味する数値「０」が指定され、レスポンスデータ７０２のパケットヘッダの「タイプ」部分にはレスポンスを意味する数値「１」が指定される。パケットヘッダの「パケットサイズ」部分にはリクエストデータ７０１、あるいはレスポンスデータ７０２全体のサイズ（オクテット数）が格納される。「ＩＤ」部分にはリクエストデータ７０１を作成した側が指定したリクエストＩＤが、対応するレスポンスにも格納される。すなわちレスポンスデータ７０２のパケットヘッダ内の「ＩＤ」部分には対応するリクエストデータに格納されていたリクエストＩＤがそのまま書き込まれる。リクエストボディには、受け取った側に対して希望する処理内容を指定する「コマンド」部分がある。「コマンド」部分に指定する処理内容の種類には、装置の機種名要求、装置に搭載された機能リスト要求、装置内の印刷ジョブリスト要求などが定義されている。リクエストボディ部の「パラメータ」部分には「コマンド」毎に定められたパラメータが指定される。

一方、レスポンスボディには処理内容を示す「コマンド」部分があり、ここには対応するリクエストデータに格納されていた「コマンド」の内容がそのまま格納される。レスポンスボディの「リザルト」部分には処理を実行した結果を意味する値が格納される。成功、パラメータ不正、実行時エラー等の処理の結果を意味する値が定義されている。

次に図４（Ａ）から図６（Ｂ）に示すフローチャートによってアクセスロジック部２０とトランスポート部３０で実行される処理を説明する。図４（Ａ）はアクセスロジック部２０での主要な機能であるプリンタからのデータ取得処理を示すフローである。

ステップＳ１０では、送信先のプリンタを指定し、指定したプリンタへのリクエストデータを送信するリクエスト発行処理を行う。ステップＳ２０では、指定したプリンタからのレスポンスデータを、通信相手のアドレスと共に受信するレスポンス受信処理を行う。ステップＳ３０では、リクエストデータと共に指定した送信先（通信相手）名であるＦＱＤＮと、レスポンスデータと共に受信したアドレス（例えばＩＰアドレス）とをトランスポート部３０に引き渡す。それにより、通信相手の名前（ＦＱＤＮ）とアドレスとの関連付けをトランスポート部３０に行わせる。

ステップＳ１０のデータ取得処理は図４（Ｂ）に示すようにステップＳ１１からステップＳ１３までの処理から成っている。ステップＳ１１ではプリンタに送信するリクエストデータを作成するリクエストデータ作成ステップである。ステップＳ１１では、図１のリクエストＩＤ生成部２０１に生成させた、少なくともその時期においてはユニークなリクエストＩＤをリクエストパケットに埋めこんでリクエストデータを作成する。

ステップＳ１２は通信相手とリクエストデータの関連付けを行う関連づけステップである。ここでの通信相手とはプリンタの名前（ＦＱＤＮ）のことであり、リクエストデータはレスポンスを受け取るまで図１のリクエストＩＤ−リクエスト関連記憶部２０３に内容が複写されて記憶される。ステップＳ１２ではリクエストパケットをリクエストＩＤと関連づけてリクエストＩＤ−リクエスト関連記憶部２０３に保存する。

ステップＳ１３では、作成したリクエストデータ７０１をトランスポート部３０に対して通信相手であるプリンタの名前（ＦＱＤＮ）とともに渡し、送信を依頼する。送信の依頼と同時に通信相手名―リクエストＩＤ関連記憶部２０２に、プリンタの名前とリクエストＩＤとを関連づけて記憶する。リクエスト発行処理は以上で終了する。

なおリクエストデータにはリクエストＩＤそのものが含まれているため、たとえばステップＳ１２ではリクスエストＩＤとリクエストパケットとを記憶せず、ステップＳ１３で通信相手名とリクエストパケットとを関連づけて記憶しておいても良い。このようにしても特定のリクエストＩＤを持つリクエストデータを検索することができる。

続いて図４（Ａ）のステップＳ２０のレスポンス受領処理、すなわち応答処理を説明する。図４（Ｃ）はレスポンス受領処理の詳細なフローである。レスポンス受領処理はステップＳ２１からステップＳ２３までの処理から成っている。ステップＳ２１はトランスポート部３０からのレスポンスデータ７０２を受け取る処理である。アクセスロジック部２０はトランスポート部３０に対して定期的にレスポンスデータ到着を問い合わせ、レスポンスデータを受信していれば受け取る。データをまだ受信していない場合には一定周期でトランスポート部３０に対してデータ到着を問い合わせる。

データを受信できた場合には、その受信データの送信元アドレス（ＩＰアドレス）も同時に取得する。これは後述するがトランスポート部３０がＯＳ付属のプロトコルスタックから取得できる情報である。この後、ステップＳ２２に進む。

ステップＳ２２ではレスポンスデータ７０２のうちパケットヘッダからリクエストＩＤを抽出する。さらに抽出したリクエストＩＤをキーにして図１のリクエストＩＤ−リクエスト関連記憶部２０３に問い合わせリクエストＩＤに関連づけられたリクエストデータを取得する。すなわち、レスポンスパケットのリクエストＩＤと過去に送信したリクエストのリクエストＩＤとを照合する。この処理はプリンタからのレスポンスデータ７０２がこのプリンタドライバ１０から送出されたリクエストデータ７０１に対する正規のレスポンスであるか否かを判定する為の処理である。レスポンスデータに含まれていたリクエストＩＤを持つリクエストデータが記憶されているということはそのレスポンスデータが正しい送信相手から返送されてきたという傍証になる。すなわち、送信したリクエストデータのリクエストＩＤを持つレスポンスデータが正規のレスポンスの蓋然性が高いと判定できる。情報の照合によりリクエストとレスポンスとを対応付ける以上、レスポンスの偽造や誤りを完全に防止することは通常困難であるので、この蓋然性の高さをもって、正規のレスポンスと判定する。これは通常の要求／応答のシーケンスにおいても同様に行われている通りである。一方、送信したリクエストデータのリクエストＩＤを持たないレスポンスデータは正規のレスポンスではないと判定できる。

もし正規のレスポンスではないと判定された場合には、それ以上の内容の解析は行うことなくレスポンスデータは破棄される。この処理により、ネットワーク上の悪意のある第３者からの偽装パケットをある程度検出して廃棄するフィルタ機能が実現できる。次にレスポンスデータの内容を解析して表示部５０に渡す。表示部５０では表示用のデータを作成して図２の表示装置６に表示を行う。

ステップＳ２３はリクエストＩＤから通信相手名を検索する処理である。ステップＳ２２で取得したリクエストＩＤを指定して、通信相手名−リクエストＩＤ関連記憶部２０２に、指定したリクエストＩＤに関連づけられた通信相手名（ＦＱＤＮ）を返却させる。ここで得たＦＱＤＮとステップＳ２１で取得したレスポンスデータの送信元アドレスとを呼び出し元に返してレスポンス受領処理は終了する。

ステップＳ３０ではステップＳ２０で取得したプリンタのＦＱＤＮと同プリンタのアドレスとを入力としてトランスポート部３０の名前解決部３０１の名前−アドレス関連付け機能を呼び出す。名前解決部３０１は図６（Ｂ）の処理を行う。説明は後述する。この後、受信した正規のレスポンスに対応するリクエストデータ及び対応するリクエストＩＤを、リクエストＩＤ−リクエスト関連記憶部２０３から削除しておく。また、正規のレスポンスを受信できなかったリクエストに関しても、同様に、対応するリクエストデータ及び対応するリクエストＩＤを、リクエストＩＤ−リクエスト関連記憶部２０３から削除しておく。

図５、図６（Ａ）、図６（Ｂ）は、トランスポート部３０で実行される処理を示すフローである。図５の送信処理は図４（Ｂ）のステップＳ１３においてアクセスロジック部２０の処理として説明した「トランスポート部３０へ送信依頼」の結果としてトランスポート部３０で実行される処理である。図５の送信処理はステップＳ５０、ステップＳ６０〜ステップＳ６７を有する。ステップＳ５０の通信相手アドレス取得処理は図６（Ａ）に詳細なステップとして説明する。ステップＳ５０では、入力として通信相手であるプリンタの名前を受け取る。実際にリクエストを送信する前に通信相手の名前をアドレスに変換する必要がある為、通信相手名−アドレス関連記憶部３０４と外部のＤＮＳサーバ７０のいずれかあるいは両方にアクセスして有効なアドレスの取得を試みる。その詳細は図６（Ａ）で説明する。

図６（Ａ）のステップＳ５１では通信相手名−アドレス関連記憶部３０４にステップＳ５０の入力として渡された通信相手名がキーとして既に登録済みか否かを判定している。既に登録済みであれば、ステップＳ５３で、通信相手名に関連づけられているアドレスを通信相手名−アドレス関連記憶部３０４から取得して呼び出し元に返す。通信相手名−アドレス関連記憶部３０４を「キャッシュ」と呼ぶ場合もある。一方登録されていない場合には、ステップＳ５２でＤＮＳサーバ７０に対して名前解決を依頼する。依頼時にはＩＰｖ４とＩＰｖ６アドレスの両方で解決を依頼する。得られたアドレスが複数ある場合にはそれらをすべてリスト（アドレスリスト）として呼び出し元に返す。プリンタドライバ１０が或るプリンタに初めてアクセスを行う場合には、図６（Ａ）のステップＳ５１はＮｏとなりＤＮＳサーバ７０での名前解決が実行される。ここでステップＳ５３にある「キャッシュ」とはＤＮＳサーバ７０での名前解決の結果をそのままキャッシュするわけではないことに注意を要する。キャッシュすなわち通信相手名−アドレス関連記憶部３０４には、後述の図６（Ｂ）で示す通信相手アドレス登録処理で入力された情報が保持される。

ステップＳ５０で通信相手であるプリンタのアドレスが取得された後は図５のステップＳ６０以降においてリクエスト送信とレスポンス受信の処理が実行される。図５の送受信処理の概要としては、取得した通信相手のアドレスに対してリクエストパケットを送信してその後規定の応答待ち時間の後に応答があるかを確認する。取得したパケットが複数ある場合には、その内の一つを選択して、選択したアドレスに送信する。規定時間内にレスポンスがない場合には、一アドレスについて規定回数（例えば２回）再送信を繰り返しながら、ステップＳ５０で取得したアドレス全てに対して試行する。名前解決で得られた全アドレスに対してリクエストを送信してもレスポンスが受信できた時点で試行を中止する。

次に送受信処理をステップごとに順に説明していく。図５のステップＳ６０ではステップＳ５０で取得した通信相手のアドレスリストのうち、未だ着目していないアドレスの有無を判定する。すなわちステップＳ６０では、アドレスリストの先頭からアドレスを指し示すインデクスをインクリメントし、そこにアドレスがあるか判定する。未着目のアドレスがあれば、次に取得可能なアドレスがあると判定される。既にアドレスリストの最後尾に達している場合には、ステップＳ６０の処理はＮｏの判定となり、これ以上の処理が継続できないため終了する。最初のステップＳ６０の判定でＮｏとなるケースは、通信相手であるプリンタの名前がＤＮＳサーバに登録されていなかった場合とプリンタが電源オフ状態やオフライン状態などで既定時間内に応答が返せなかった場合とが考えられる。次のアドレスが存在する場合にはそのアドレスを着目アドレスとする。このとき、送信回数を数えるカウンタを初期値、たとえば０、に戻す。そしてステップＳ６１に進んで、アドレス毎に送信を試行する所定回数を超えたか否かを判定する。すなわち前記カウンタ値が所定回数を超えていた場合には、ステップＳ６０に移行して次のアドレスの取得を試みる。

ステップＳ６１でＮｏの場合にはステップＳ６２においてリクエストデータを送信する処理を行う。ステップＳ６１はトランスポート部３０のリクエスト送信部３０２で実行される処理である。ステップＳ６１では、アクセスロジック部２０から受け取ったリクエストデータをステップＳ６０で着目したアドレスに送信する。

続くステップＳ６３では所定の応答待ち時間（たとえば５秒）だけ応答を待つ。この待ち時間はプリンタがスリープ状態にあった場合に、覚醒に要する時間と覚醒後にレスポンスするために要する時間とを加味して既定されている。

ステップＳ６４ではプリンタからのレスポンスデータの受信を試みる。具体的にはＯＳ付属のプロトコルスタックが提供している受信データ取得関数を呼び出してデータが到着しているか否かを確認する。

ステップＳ６５では、ステップＳ６４の結果によって受信データを受信したかどうかを判定する。この判定でＮｏであればステップＳ６７に移行し、送信回数を１増やしてステップＳ６１に移行する。一方ステップＳ６５でＹｅｓの場合はプリンタから送信したリクエストに対応するレスポンスを受け取った可能性が高い。そのため、ステップＳ６５でＹｅｓの場合はリクエストに対応するレスポンスを受け取ったものと判定する。ステップＳ６６で受信データを、送信の要求元であるアクセスロジック部２０に渡すための情報として作成する。この情報にはたとえば受信したレスポンスデータとそのレスポンスデータを送信してきたプリンタのアドレスとが含まれている。

次に、図６（Ｂ）の通信相手アドレス登録処理について説明する。この処理は図４（Ａ）のステップＳ３０で、アクセスロジック部２０がトランスポート部３０の名前解決部３０１の名前−アドレス関連付け機能を呼び出すことで実行される処理である。図６（Ｂ）の通信相手アドレス登録処理は入力としてプリンタのＦＱＤＮとアドレスとの組が与えられる。ステップＳ７１ではそのＦＱＤＮとアドレスとを関連付けて記憶する。通信相手先名−アドレス関連記憶部３０４に記憶されたＦＱＤＮとアドレスは、アドレスのキャッシュとして参照される。そのため、無参照時間が一定時間を超えたキャッシュのレコード（ＦＱＤＮとアドレスとの対）に関しては、削除することが望ましい。アドレスが変更されている可能性があるためであり、また、記憶容量が有限なためである。また、キャッシュされたアドレスにリクエストを送信してレスポンスがない場合にも、そのレコードを削除することが望ましい。登録されるアドレスは、正規のレスポンスが返されたリクエストデータの送信先アドレスである。このほかたとえば正規のレスポンスの送信元アドレスであってもよい。

以上の手順により、送信先名称（ＦＱＤＮ）とパケットに付加した識別情報（リクエストＩＤ）とを関連づけることで、受信したレスポンスが、送信したリクエストに対応するレスポンスであることを識別できる。そのため、識別したレスポンス以外を廃棄するフィルタリング処理を実現できる。

さらに、ＩＰｖ４とＩＰｖ６のアドレスを一回的に取得することができ、名前解決の回数や所要時間を低減できる。

また、通信に成功したアドレスを送信先名称（ＦＱＤＮ）と関連づけてキャッシュしておくことで、複数のアドレスがＩＰｖ６のＤＮＳサーバに登録されている場合にも、パケット送信の試行回数を減少させることができる。これによりネットワークのトラフィックを低減させることができる。

なお本実施形態はプリンタドライバがプリンタに対して印刷データすなわちリクエストデータを送信する場合を例にとって説明したが、データ送信一般について適用することが可能である。すなわち、プリンタドライバ１０に代えて、他のアプリケーションプログラムやシステムプログラムに対して本実施形態に係る発明を適用することができる。その場合、アクセスロジック部２０とトランスポートロジック部３０とが、代替のアプリケーションあるいはシステムプログラム対して、本実施形態と同様に機能する。

また本実施形態では、アクセスロジック部２０とトランスポートロジック部３０とが、プリンタドライバに含まれるものとして説明した。しかし、アクセスロジック部２０とトランスポートロジック部３０とは、プリンタドライバの外側にあって、ドライバロジック部４０との間で関数呼び出しなどの適当なインターフェースにより呼び出されるものであってもよい。そのような構成であれば、所望のプログラムにアクセスロジック部２０とトランスポートロジック部３０とのインターフェースを記述することで、アクセスロジック部２０とトランスポートロジック部３０とを利用することができる。

またリクエストパケットすなわち送信データに含めるＩＤは、本実施形態では巡回的に生成される符号としたが、たとえば時刻や送信元アドレスと時刻の組み合わせなど、パケットを固有に識別できる符号であればよい。

また、本実施形態では、レスポンスデータと同じリクエストＩＤを持つリクエストデータが記憶されていた場合、ＩＤのみを識別情報として正規のレスポンスと判定している。しかし、更にデータの内容を照合して、たとえば図７に示されたコマンドなど、対応するリクエストとレスポンスとに共通する値を持つフィールドを照合して一致すれば正規のレスポンスと判定してもよい。すなわちこの場合にはＩＤに加えて、リクエストとレスポンスの共通フィールドを識別情報として正規のレスポンスと判定する。

なお本発明は、複数の機器（例えばホストコンピュータ、インターフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）をパソコン等の処理装置（ＣＰＵ、プロセッサ）にて実行することでも実現できる。

Claims (9)

1. 複数のアドレスが付与されたネットワーク機器とネットワークを介して通信するデータ通信装置であって、
   送信先のネットワーク機器に対応するアドレスを取得する取得手段と、
   取得された前記アドレスに対し、送信データを前記送信データの識別情報とともに送信する送信手段と、
   識別情報を含む応答データを受信する受信手段と、
   前記応答データの識別情報と前記送信データの識別情報とが同じでない場合には前記応答データを要求元に引き渡さず、前記応答データの識別情報と前記送信データの識別情報とが同じである場合には前記応答データを前記要求元に引き渡す応答処理手段と、を有し、
   前記応答処理手段は、前記応答データの識別情報と前記送信データの識別情報とが同じである場合には、前記送信データの送信先のアドレスまたは前記応答データの送信元のアドレスと、前記送信先のネットワーク機器とを対応づけて記憶手段に記憶することを特徴とするデータ通信装置。
2. 前記取得手段は、前記送信先の名前に対応するアドレスが見つけられない場合には、前記送信先の名前をＤＮＳサーバに送信し、当該送信先に複数のアドレスが付与されている場合にはそれらをまとめて取得することを特徴とする請求項１に記載のデータ通信装置。
3. 前記識別情報には、前記送信データに割り当てられるＩＤを含むことを特徴とする請求項１または２に記載のデータ通信装置。
4. 前記アドレスには、インターネットネットプロトコルバーション６のＩＰアドレスを含むことを特徴とする請求項１乃至３のいずれか一項に記載のデータ通信装置。
5. コンピュータに、複数のアドレスが付与されたネットワーク機器とネットワークを介して通信させるためのプログラムであって、
   送信先のネットワーク機器に対応するアドレスを取得する取得手段と、
   取得された前記アドレスに対し、送信データを前記送信データの識別情報とともに送信する送信手段と、
   識別情報を含む応答データを受信する受信手段と、
   前記応答データの識別情報と前記送信データの識別情報とが同じでない場合には前記応答データを要求元に引き渡さず、前記応答データの識別情報と前記送信データの識別情報とが同じである場合には前記応答データを前記要求元に引き渡す応答処理手段と、してコンピュータを機能させるためのプログラムであって、
   前記応答処理手段は、前記応答データの識別情報と前記送信データの識別情報とが同じである場合には、前記送信データの送信先のアドレスまたは前記応答データの送信元のアドレスと、前記送信先のネットワーク機器とを対応づけて記憶手段に記憶することを特徴とするプログラム。
6. 複数のアドレスが付与されたネットワーク機器とネットワークを介して通信するデータ通信装置におけるデータ通信方法であって、
   前記データ通信装置の取得手段が、送信先のネットワーク機器に対応するアドレスを取得する取得工程と、
   前記データ通信装置の送信手段が、取得された前記アドレスに対し、送信データを前記送信データの識別情報とともに送信する送信工程と、
   前記データ通信装置の受信手段が、識別情報を含む応答データを受信する受信工程と、
   前記データ通信装置の応答処理手段が、前記応答データの識別情報と前記送信データの識別情報とが同じでない場合には前記応答データを送信元に引き渡さず、前記応答データの識別情報と前記送信データの識別情報とが同じである場合には前記応答データを前記要求元に引き渡す応答処理工程と、を有し、
   前記応答処理工程では、前記応答データの識別情報と前記送信データの識別情報とが同じである場合には、前記送信データの送信先のアドレスまたは前記応答データの送信元のアドレスと、前記送信先のネットワーク機器とを対応づけて記憶手段に記憶することを特徴とするデータ通信方法。
7. 請求項４に記載のデータ通信装置と、
   印刷データを生成する手段とを有し、
   前記送信手段は、ネットワークに接続された、インターネットネットプロトコルバーション６のＩＰアドレスが付与されたプリンタに対して印刷データを送信することを特徴とする印刷制御装置。
8. 印刷データを生成する手段としてコンピュータを更に機能させ、
   前記送信手段により、ネットワークに接続された、インターネットネットプロトコルバーション６のＩＰアドレスが付与されたプリンタに対して印刷データを送信することを特徴とする請求項５に記載のプログラム。
9. 前記プログラムとは、プリンタドライバプログラムであることを特徴とする請求項５に記載のプログラム。

Images