現行のインターネットプロトコル(IPv4)のアドレスが枯渇しつつあることを受け、アドレス空間の増大、セキュリティ機能の追加、優先度に応じたデータの送信などの改良を施した次世代インターネットプロトコルとしてIPv6が実用になり始めている。IPv6プロトコルでは一つのネットワークインターフェイスに複数のアドレスが割り当て可能な仕様となっている。たとえば、割り当てられるアドレスとしてリンクローカルユニキャストアドレス(以下リンクローカルアドレスと称する)、グローバルユニキャストアドレス(以下グローバルアドレスと称する)などが知られている。さらに、グローバルアドレスとして複数のアドレスを割り当てることができるため、ひとつのホストに対してIPv4アドレスと複数のIPv6アドレスとがDNS(Domain Name System)サーバへ登録される場合がある。
通信相手を特定する為には通常「名前」と呼ばれるFQDN(Fully Qualified Domain Name)が用いられている。なおFQDNとは、DNSのドメインの階層構造に沿ってルートから表示したホスト名あるいはドメイン名である。FQDN のことを以下では単に「名前」と呼ぶことがある。DNSサーバに対して名前を指定してバイナリアドレスを問い合わせると複数のIPv6が取得されることがある。これらのアドレスには問い合わせ元のPCから全て到達可能であるとは限らない。その為、IPv6を使ったTCP通信においてはDNSを使った名前解決の結果として得られる複数のアドレスに対して順次接続試行を行い接続が成功した時点でのアドレスを相手アドレスとして使用することになる。IPv6を使ったUDP通信ではなおさらアプリケーションが通信相手に対してパケット再送などの手法を使って到達性を確認しなければならない為、これも本質的にTCP通信と同じように順次複数のアドレスに対してパケットを送信することを試みなければならない。この様に、IPv6通信は本質的に複数アドレスに伴うネットワークトラフィックの増大と接続までの試行時間の増大をもたらす。
さらに相手アドレスの対向である自アドレスとしても同様に複数アドレスが存在する。通信相手のアドレスが決まると、そのアドレスに対応する自アドレスはRFC3484( "Default Address Selection for Internet Protocol version 6(IPv6)") として既定されているアルゴリズムに則り選択されることになっている。このアドレス選択アルゴリズムは通常プロトコルスタックと呼ばれるOS(Operating System)に近いプログラム内で実行されるため、アプリケーションプログラムは選択される自アドレスに関して関与できない。
上記のような複数のIPv6アドレスが2つの通信端点それぞれに存在することによって特にUDPプロトコルを使った通信を行う場合に以下に示すような状況が発生する。通信端点A,B共に自身のIPv6アドレスを3つずつ保持しておりそれぞれ、Addr_A1,Addr_A2,Addr_A3と Addr_B1,Addr_B2,Addr_B3とする。このうち通信端点Bのアドレスのうち2つのアドレスAddr_B1,Addr_B2がDNSに登録されているとする。
図3(A)に示す様に通信端点Aが通信端点Bに対して通信を開始する場合、まずはDNSに対して通信端点Bの名前(ここでは"通信端点B"という名前であるとする)を指定して名前解決を依頼(クエリ)する。DNSサーバでは名前解決の結果として2つのアドレス(Addr_B1,Addr_B2)を通信端点Aに対して返却(レスポンス)する。
名前解決の結果を受け取った通信端点AはAddr_B1に向けてリクエストを送信したところ、通信端点Bに到達したとする。通信端点Bはリクエストに対応したレスポンスを返信するが、このとき通信端点はリクエストの送信元アドレスとしてAddr_A1を知ったのでこのアドレスに対してレスポンスを返信する。すると前述のRFC3484に規定されているアドレス選択アルゴリズムが機能し、通信端点Bの保持する3つのアドレスのうち最適なアドレスとしてAddr_B1ではなくAddr_B3が選択されることがある。このようにして通信端点BからのレスポンスはAddr_B3から通信端点AのAddr_A1に向けて送出される。通信端点Aの側に立つと、未知のアドレスからデータが送られてくるという状況になる。
通信端点Aがリクエストを送出した相手が通信端点Bのみであることが確定している場合には未知のアドレスからのデータを「通信端点Bから送られてきたレスポンスである」と判断できる場合がある。しかし、図3(B)のように通信端点Aからほぼ同時に通信端点Bと通信端点Cの2つの相手にリクエストを送出する場合を考えてみると上記の判断が不可能であることがわかる。図3(B)における通信端点A、通信端点B、通信端点Cのアドレスは各々Addr_A1,Addr_A2,Addr_A3とAddr_B1,Addr_B2,Addr_B3とAddr_C1,Addr_C2,Addr_C3であるとする。さらに、通信端点BのアドレスのうちDNSサーバに登録されているアドレスはAddr_B1,Addr_B2であり、同様に通信端点CのそれはAddr_C1,Addr_C2であるとする。通信端点Aは通信端点Bと通信端点Cの名前をDNSサーバに問い合わせ、先に説明した各端点あたり2つのアドレスをレスポンスとして受け取っているものとする。ここで通信端点Aは通信端点Bと通信端点Cにリクエストを送出し、通信端点BはAddr_B3からAddr_A1に向けてレスポンスを送出し、通信端点CはAddr_C3からAddr_A1に向けてレスポンスを送出したとする。
通信端点Aは見知らぬアドレスAddr_B3とAddr_C3からデータを受信することになる。この2つの受信データは通信端点Bと通信端点Cのいずれから送信されてきたレスポンスデータであるのか判断できない。リクエストの送信先アドレスから必ずレスポンスが送り返されてくることがあてにできるIPv4のようなプロトコルの場合は通信の両端点のポート番号も含んだアドレスの組によって通信相手が特定できるためこのような問題は起きない。このような状況ではレスポンスパケットの送信元アドレスをリクエストパケットの送信先アドレスと一致しない場合にはその受取を拒否するといアドレスに基づくパケットフィルタリングが行えなくなるというセキュリティ上の問題が発生する。
すなわち、見知らぬアドレスから送られてきたデータパケットは何らかのリクエストパケットに対する正規のレスポンスである可能性があるためフィルタリングして破棄することはできない。そのため、いったんどんなパケットも受信しなければならないということを意味する。
DNSサーバへの名前解決に伴うトラフィックの増加、処理の遅延を改善する目的で、IPv4とIPv6のアドレスが登録されているサーバへのアクセスにいずれのプロトコルを用いるかを過去の実績に基づいて決定する方法がある(例えば特許文献1参照)。特許文献1で開示されている従来の技術は主に、IPv4とIPv6が混在する状況を想定している。アクセスしようとするサーバプロセスと過去に通信が可能であったIPプロトコルをサーバプロセスと関連付けてキャッシュしておき、次回のアクセスの再にはそのIPプロトコルおよび対応するアドレスを利用しようとするものである。この従来技術ではDNSサーバへのアクセスを低減すること、及びサーバプロセスがDNSサーバに登録されているプロトコルアドレスの全てでは待ちうけていない場合に無駄なアドレスでのアクセス試行を減じることに効果を発揮する。
図2は本発明をプリンタドライバに適用した際にアプリケーションプログラムにロードされて動作するデータ通信装置としてのPCの構成を示すブロック図である。このプリンタドライバがインストールされたPCは、プリンタを制御する印刷制御装置として機能する。PCのオペレーティングシステム(OS)はRAM4、HDD5あるいは後述のディスクドライブ装置の記憶媒体のいずれかの記憶手段に格納されておりCPU3により実行される。さらに、OSはプリンタドライバの依頼により表示装置6に表示を行い、入力装置7からのユーザの入力を取り込んでプリンタドライバに通知することを担っている。さらに、OSは通信部8を制御し、通信部8で接続された周辺装置の他、周辺装置9の制御、入出力を行いプリンタドライバとのデータの入出力を行っている。制御対象の周辺装置には、PCカード、各種ディスクドライブ装置、プリンタ、ネットワークカード等がある。さらにOSはファイルシステム機能を提供しており、ファイルの記憶媒体は図2のHDD5、RAM4に限らず、通信部8を介して接続されたネットワーク上の他のPCも含めた外部記憶装置も含むものである。OSおよびプリンタドライバはPC上のシステムバス1、2を通じて互いに連結されたハードウエアモジュール群のデータを授受している。
プリンタドライバはOSが提供しているアプリケーションプログラムインターフェース(API)を通じてPC上のリソースにアクセスしたりOSの提供する機能を使用したりする。プリンタドライバはアプリケーションプログラムにロードされて印刷データを渡され、それをプリンタが理解できる言語に翻訳することが主な処理である。加えてプリンタドライバは、使用者にプリンタの装備しているステープル装置、スタッカ装置、搭載している用紙トレイなどの状況を取得して表示する機能を提供している。さらに、プリンタドライバは、プリンタ内部に蓄積されている印刷待ちのジョブリストを取得して表示する機能も提供している。
プリンタドライバは、RAM4、HDD5あるいは後述のディスクドライブ装置の記憶媒体のいずれかの記憶手段に格納されており、CPU3により実行される。さらにプリンタドライバはOSが提供するファイルシステムに記憶されているファイルを参照する。以下のプリンタドライバの構成及び動作の説明においては、印刷データの翻訳に関する機能の詳細説明は割愛する。本実施形態のプリンタドライバは使用者が指定した通信相手のネットワーク機器として、ネットワークプリンタや複写機等を想定している。これらネットワークプリンタや複写機等をまとめてプリンタと称する。以下の説明においては、これらプリンタにネットワークを介してアクセスし、プリンタの機種名、プリンタに搭載された機能リスト、プリンタ内部の印刷ジョブリストを取得して、図2の表示装置6に表示する機能に関して詳しく説明する。
図1は本発明のプリンタドライバの構成を示すブロック図である。プリンタドライバは、アプリケーションプログラム等によって作成されたデータを、ユーザが指定したプリンタが解釈実行可能なプリンタ記述言語に翻訳し、翻訳したデータを当該プリンタに送信する。送信されるデータはここでは一般的には送信データと呼ぶが、プリンタに送られる前述の翻訳したデータについては印刷データとも呼ぶ。プリンタドライバ10は表示部50、入力部60、アクセスロジック部20、トランスポート部30、ドライバロジック部40を備えている。最初にプリンタドライバの内部に存在する3つの機能ブロックの定義を行う。
ドライバロジック部40は、アクセスロジック部20に対してプリンタの名前を指定して情報の取得を指示する機能ブロックである。ドライバロジック部40は、プリンタドライバ10の印刷データの翻訳処理とPCの表示装置上に画面を表示する。また、使用者からのプリンタの選択手段、選択したプリンタの機能を取得する指示手段の制御とプリンタから取得した情報の画面への表示を担っている。さらに後述のアクセスロジック部に対してプリンタの名前を指定して所望の情報を取得するように要求を行い、結果を取得する処理も行っている。
なおアクセスロジック部20は、送信データに基づいてリクエストデータを作成し、ドメイン名やホスト名(すなわちFQDN)で指定されるリクエストの送信先を指定してトランスポート部に対しリクエスト送信依頼を行う処理を司るブロックである。リクエスト送信先としてはFQDNだけでなく、IPv4やIPv6(インターネットネットプロトコルバーション6)のバイナリアドレス、コンピュータ名等の形式で指定することができるが、アクセスロジック部20は、少なくともFQDNを指定する。
トランスポート部は依頼されたリクエストデータを依頼された送信先に送出し、それに対するレスポンスを受け取ってアクセスロジック部に引き渡す機能ブロックである。トランスポート部は、送信を依頼されたリクエストの内容およびレスポンスの内容に関して一切の知識を有しないものとする。さらにトランスポート部はFQDNで指定された送信先のバイナリアドレスを特定する目的でDNSサーバへの問い合わせを行う。
プリンタドライバ10はネットワーク上に存在するDNSサーバにアクセスをおこなう。DNSサーバに対してプリンタドライバが通信対象としているプリンタのFQDNを指定し、応答としてそのプリンタに割り当てられているアドレスを受け取る。
入力部60は図2の入力装置7を介して使用者の入力を受取りドライバロジック部に引き渡す。入力される情報として、通信相手であるプリンタのFQDNと取得開始指示とが渡される。表示部50は図2の表示装置6に対して表示すべきデータを作成して表示させる処理を司る。表示内容はプリンタから取得した機種名、搭載された機能リスト、プリンタ内の印刷ジョブリストである。
ドライバロジック部40は入力部60から渡されたプリンタのFQDNとアドレスの取得開始指示をアクセスロジック部20に引き渡す。
アクセスロジック部20は、リクエストID生成部201、通信相手名−リクエストID関連記憶部202、リクエストID−リクエスト関連記憶部203と制御部200とを備えている。アドレスの取得開始指示が与えられると、制御部200はリクエストID生成部201にリクエストIDの生成要求を出す。リクエストID生成部201は制御部200からの要求に応じてユニークなIDを生成して返す。リクエストIDは、比較的長い周期で巡回するIDを用いている。このため、あるプリンタに対して送信する際に生成されたリクエストIDと同じリクエストIDが、同一装置への別のリクエストや他のプリンタへのリクエストに同時に用いられる可能性は非常に低い。逆に言うと、リクエストIDの周期としては、同一のリクエストIDが同一システム内で同時に使用されることがない程度の長さが選択される。ひとつのリクエストIDは、最大で、(送信先のホスト名(本例ではプリンタ)に対してDNSに登録されたアドレス数)×(応答待ち時間)+(スリープからの覚醒時間)+(応答所要時間)程度の時間にわたり使用される可能性がある。この時間を最大ID利用時間とすれば、リクエストIDの周期>最大ID利用時間/(送信要求が発生する平均時間間隔)が満たされれば、リクエストIDのユニークさは保たれる。
通信相手名−リクエストID関連記憶部202は、制御部200から通信相手のFQDNとリクエストIDを渡され、それらを関連付けて記憶する。さらに通信相手名−リクエストID関連記憶部202は、リクエストIDを指定されて関連つけられているFQDNを検索して返却する機能を有している。リクエストID−リクエスト関連記憶部203は制御部からリクエストIDとリクエストデータを渡され、それらを関連付けて記憶する。さらにリクエストID−リクエスト関連記憶部203は、指定されたリクエストIDに関連つけられているリクエストデータを検索して返却する機能を有している。
制御部200は、リクエストID生成部201と、通信相手名−リクエストID関連記憶部202と、リクエストID−リクエスト関連記憶部203と、トランスポート部30とを制御し、通信相手のプリンタから必要な情報を取得する。
また制御部200は外部に存在するDNSサーバ70やプリンタ80のネットワーク上の位置(アドレス)詳細については関知していない。制御部200はトランスポート部30に対してリクエストデータと呼ばれるプリンタとの間で取り決めたプロトコルデータを作成する。プロトコルデータには通信相手を一意に特定するためのユニークなIDであるリクエストIDが埋め込まれている。送信内容であるリクエストデータとその送り先であるところの通信相手名(FQDN)が制御部200からトランスポート部30に対して引き渡されて送信依頼がなされる。
トランスポート部30は、名前解決部301、通信相手名−アドレス関連記憶部304、リクエスト送信部302、レスポンス受信部303を備えている。リクエスト送信部302は入力としてリクエストデータとその送信先であるプリンタの名前すなわちFQDNを受け取る。リクエスト送信部302はその後、名前解決部301に依頼して受け取ったFQDNをアドレスに変換させる。名前解決部301は、リクエスト送信部302から引き渡されたFQDNに関連づけられたアドレスを通信相手名−アドレス関連記憶部304により検索させ、関連するアドレスが見つかればそのアドレスをリクエスト送信部302に引き渡す。通信相手名−アドレス関連記憶部304は、FQDNからアドレスを検索して返す名前解決部301の機能の実質的実行部分として機能している。リクエスト送信部302は、こうして送り先のFQDNに対応したアドレス(通信相手アドレス)を取得する。名前解決に指定するアドレスはIPv4とIPv6のどちらも用いることができる。なお前述したように、IPv6では一つの名前(FQDN)に対して複数のアドレスが付与され得る。
リクエスト送信部302は、取得した通信相手アドレスに対して依頼されたリクエストデータをUDP(User Datagram Protocol)を使って送信する。このとき、名前解決部301から返されたアドレスが複数ある場合には各アドレスに対してリクエストデータを送信して一定時間経過後までに応答がなければ再送する処理を行う。
レスポンス受信部303は、プリンタからの応答データを受信してレスポンスデータとしてアクセスロジック部20に引き渡す機能を提供している。その際、応答データの送信元アドレスも取得して応答データとともに引き渡す。なおプリンタはレスポンスデータをUDPを使って送信する。リクエストとは、パケットに含まれるリクエストIDにより対応付けられる。
図7(A)、図7(B)でプリンタドライバ10とプリンタとの間で授受されるリクエストデータ701とレスポンスデータ702のパケット構造を説明する。図7(A)がプリンタドライバ10からプリンタに向けて送出されるリクエストデータ701である。固定サイズのパケットヘッダと可変長のリクエストボディから成っている。パケットヘッダはレスポンスデータ702とフィールドの構成については共通である。ただしリクエストデータ701では「タイプ」部分にリクエストを意味する数値「0」が指定され、レスポンスデータ702のパケットヘッダの「タイプ」部分にはレスポンスを意味する数値「1」が指定される。パケットヘッダの「パケットサイズ」部分にはリクエストデータ701、あるいはレスポンスデータ702全体のサイズ(オクテット数)が格納される。「ID」部分にはリクエストデータ701を作成した側が指定したリクエストIDが、対応するレスポンスにも格納される。すなわちレスポンスデータ702のパケットヘッダ内の「ID」部分には対応するリクエストデータに格納されていたリクエストIDがそのまま書き込まれる。リクエストボディには、受け取った側に対して希望する処理内容を指定する「コマンド」部分がある。「コマンド」部分に指定する処理内容の種類には、装置の機種名要求、装置に搭載された機能リスト要求、装置内の印刷ジョブリスト要求などが定義されている。リクエストボディ部の「パラメータ」部分には「コマンド」毎に定められたパラメータが指定される。
一方、レスポンスボディには処理内容を示す「コマンド」部分があり、ここには対応するリクエストデータに格納されていた「コマンド」の内容がそのまま格納される。レスポンスボディの「リザルト」部分には処理を実行した結果を意味する値が格納される。成功、パラメータ不正、実行時エラー等の処理の結果を意味する値が定義されている。
次に図4(A)から図6(B)に示すフローチャートによってアクセスロジック部20とトランスポート部30で実行される処理を説明する。図4(A)はアクセスロジック部20での主要な機能であるプリンタからのデータ取得処理を示すフローである。
ステップS10では、送信先のプリンタを指定し、指定したプリンタへのリクエストデータを送信するリクエスト発行処理を行う。ステップS20では、指定したプリンタからのレスポンスデータを、通信相手のアドレスと共に受信するレスポンス受信処理を行う。ステップS30では、リクエストデータと共に指定した送信先(通信相手)名であるFQDNと、レスポンスデータと共に受信したアドレス(例えばIPアドレス)とをトランスポート部30に引き渡す。それにより、通信相手の名前(FQDN)とアドレスとの関連付けをトランスポート部30に行わせる。
ステップS10のデータ取得処理は図4(B)に示すようにステップS11からステップS13までの処理から成っている。ステップS11ではプリンタに送信するリクエストデータを作成するリクエストデータ作成ステップである。ステップS11では、図1のリクエストID生成部201に生成させた、少なくともその時期においてはユニークなリクエストIDをリクエストパケットに埋めこんでリクエストデータを作成する。
ステップS12は通信相手とリクエストデータの関連付けを行う関連づけステップである。ここでの通信相手とはプリンタの名前(FQDN)のことであり、リクエストデータはレスポンスを受け取るまで図1のリクエストID−リクエスト関連記憶部203に内容が複写されて記憶される。ステップS12ではリクエストパケットをリクエストIDと関連づけてリクエストID−リクエスト関連記憶部203に保存する。
ステップS13では、作成したリクエストデータ701をトランスポート部30に対して通信相手であるプリンタの名前(FQDN)とともに渡し、送信を依頼する。送信の依頼と同時に通信相手名―リクエストID関連記憶部202に、プリンタの名前とリクエストIDとを関連づけて記憶する。リクエスト発行処理は以上で終了する。
なおリクエストデータにはリクエストIDそのものが含まれているため、たとえばステップS12ではリクスエストIDとリクエストパケットとを記憶せず、ステップS13で通信相手名とリクエストパケットとを関連づけて記憶しておいても良い。このようにしても特定のリクエストIDを持つリクエストデータを検索することができる。
続いて図4(A)のステップS20のレスポンス受領処理、すなわち応答処理を説明する。図4(C)はレスポンス受領処理の詳細なフローである。レスポンス受領処理はステップS21からステップS23までの処理から成っている。ステップS21はトランスポート部30からのレスポンスデータ702を受け取る処理である。アクセスロジック部20はトランスポート部30に対して定期的にレスポンスデータ到着を問い合わせ、レスポンスデータを受信していれば受け取る。データをまだ受信していない場合には一定周期でトランスポート部30に対してデータ到着を問い合わせる。
データを受信できた場合には、その受信データの送信元アドレス(IPアドレス)も同時に取得する。これは後述するがトランスポート部30がOS付属のプロトコルスタックから取得できる情報である。この後、ステップS22に進む。
ステップS22ではレスポンスデータ702のうちパケットヘッダからリクエストIDを抽出する。さらに抽出したリクエストIDをキーにして図1のリクエストID−リクエスト関連記憶部203に問い合わせリクエストIDに関連づけられたリクエストデータを取得する。すなわち、レスポンスパケットのリクエストIDと過去に送信したリクエストのリクエストIDとを照合する。この処理はプリンタからのレスポンスデータ702がこのプリンタドライバ10から送出されたリクエストデータ701に対する正規のレスポンスであるか否かを判定する為の処理である。レスポンスデータに含まれていたリクエストIDを持つリクエストデータが記憶されているということはそのレスポンスデータが正しい送信相手から返送されてきたという傍証になる。すなわち、送信したリクエストデータのリクエストIDを持つレスポンスデータが正規のレスポンスの蓋然性が高いと判定できる。情報の照合によりリクエストとレスポンスとを対応付ける以上、レスポンスの偽造や誤りを完全に防止することは通常困難であるので、この蓋然性の高さをもって、正規のレスポンスと判定する。これは通常の要求/応答のシーケンスにおいても同様に行われている通りである。一方、送信したリクエストデータのリクエストIDを持たないレスポンスデータは正規のレスポンスではないと判定できる。
もし正規のレスポンスではないと判定された場合には、それ以上の内容の解析は行うことなくレスポンスデータは破棄される。この処理により、ネットワーク上の悪意のある第3者からの偽装パケットをある程度検出して廃棄するフィルタ機能が実現できる。次にレスポンスデータの内容を解析して表示部50に渡す。表示部50では表示用のデータを作成して図2の表示装置6に表示を行う。
ステップS23はリクエストIDから通信相手名を検索する処理である。ステップS22で取得したリクエストIDを指定して、通信相手名−リクエストID関連記憶部202に、指定したリクエストIDに関連づけられた通信相手名(FQDN)を返却させる。ここで得たFQDNとステップS21で取得したレスポンスデータの送信元アドレスとを呼び出し元に返してレスポンス受領処理は終了する。
ステップS30ではステップS20で取得したプリンタのFQDNと同プリンタのアドレスとを入力としてトランスポート部30の名前解決部301の名前−アドレス関連付け機能を呼び出す。名前解決部301は図6(B)の処理を行う。説明は後述する。この後、受信した正規のレスポンスに対応するリクエストデータ及び対応するリクエストIDを、リクエストID−リクエスト関連記憶部203から削除しておく。また、正規のレスポンスを受信できなかったリクエストに関しても、同様に、対応するリクエストデータ及び対応するリクエストIDを、リクエストID−リクエスト関連記憶部203から削除しておく。
図5、図6(A)、図6(B)は、トランスポート部30で実行される処理を示すフローである。図5の送信処理は図4(B)のステップS13においてアクセスロジック部20の処理として説明した「トランスポート部30へ送信依頼」の結果としてトランスポート部30で実行される処理である。図5の送信処理はステップS50、ステップS60〜ステップS67を有する。ステップS50の通信相手アドレス取得処理は図6(A)に詳細なステップとして説明する。ステップS50では、入力として通信相手であるプリンタの名前を受け取る。実際にリクエストを送信する前に通信相手の名前をアドレスに変換する必要がある為、通信相手名−アドレス関連記憶部304と外部のDNSサーバ70のいずれかあるいは両方にアクセスして有効なアドレスの取得を試みる。その詳細は図6(A)で説明する。
図6(A)のステップS51では通信相手名−アドレス関連記憶部304にステップS50の入力として渡された通信相手名がキーとして既に登録済みか否かを判定している。既に登録済みであれば、ステップS53で、通信相手名に関連づけられているアドレスを通信相手名−アドレス関連記憶部304から取得して呼び出し元に返す。通信相手名−アドレス関連記憶部304を「キャッシュ」と呼ぶ場合もある。一方登録されていない場合には、ステップS52でDNSサーバ70に対して名前解決を依頼する。依頼時にはIPv4とIPv6アドレスの両方で解決を依頼する。得られたアドレスが複数ある場合にはそれらをすべてリスト(アドレスリスト)として呼び出し元に返す。プリンタドライバ10が或るプリンタに初めてアクセスを行う場合には、図6(A)のステップS51はNoとなりDNSサーバ70での名前解決が実行される。ここでステップS53にある「キャッシュ」とはDNSサーバ70での名前解決の結果をそのままキャッシュするわけではないことに注意を要する。キャッシュすなわち通信相手名−アドレス関連記憶部304には、後述の図6(B)で示す通信相手アドレス登録処理で入力された情報が保持される。
ステップS50で通信相手であるプリンタのアドレスが取得された後は図5のステップS60以降においてリクエスト送信とレスポンス受信の処理が実行される。図5の送受信処理の概要としては、取得した通信相手のアドレスに対してリクエストパケットを送信してその後規定の応答待ち時間の後に応答があるかを確認する。取得したパケットが複数ある場合には、その内の一つを選択して、選択したアドレスに送信する。規定時間内にレスポンスがない場合には、一アドレスについて規定回数(例えば2回)再送信を繰り返しながら、ステップS50で取得したアドレス全てに対して試行する。名前解決で得られた全アドレスに対してリクエストを送信してもレスポンスが受信できた時点で試行を中止する。
次に送受信処理をステップごとに順に説明していく。図5のステップS60ではステップS50で取得した通信相手のアドレスリストのうち、未だ着目していないアドレスの有無を判定する。すなわちステップS60では、アドレスリストの先頭からアドレスを指し示すインデクスをインクリメントし、そこにアドレスがあるか判定する。未着目のアドレスがあれば、次に取得可能なアドレスがあると判定される。既にアドレスリストの最後尾に達している場合には、ステップS60の処理はNoの判定となり、これ以上の処理が継続できないため終了する。最初のステップS60の判定でNoとなるケースは、通信相手であるプリンタの名前がDNSサーバに登録されていなかった場合とプリンタが電源オフ状態やオフライン状態などで既定時間内に応答が返せなかった場合とが考えられる。次のアドレスが存在する場合にはそのアドレスを着目アドレスとする。このとき、送信回数を数えるカウンタを初期値、たとえば0、に戻す。そしてステップS61に進んで、アドレス毎に送信を試行する所定回数を超えたか否かを判定する。すなわち前記カウンタ値が所定回数を超えていた場合には、ステップS60に移行して次のアドレスの取得を試みる。
ステップS61でNoの場合にはステップS62においてリクエストデータを送信する処理を行う。ステップS61はトランスポート部30のリクエスト送信部302で実行される処理である。ステップS61では、アクセスロジック部20から受け取ったリクエストデータをステップS60で着目したアドレスに送信する。
続くステップS63では所定の応答待ち時間(たとえば5秒)だけ応答を待つ。この待ち時間はプリンタがスリープ状態にあった場合に、覚醒に要する時間と覚醒後にレスポンスするために要する時間とを加味して既定されている。
ステップS64ではプリンタからのレスポンスデータの受信を試みる。具体的にはOS付属のプロトコルスタックが提供している受信データ取得関数を呼び出してデータが到着しているか否かを確認する。
ステップS65では、ステップS64の結果によって受信データを受信したかどうかを判定する。この判定でNoであればステップS67に移行し、送信回数を1増やしてステップS61に移行する。一方ステップS65でYesの場合はプリンタから送信したリクエストに対応するレスポンスを受け取った可能性が高い。そのため、ステップS65でYesの場合はリクエストに対応するレスポンスを受け取ったものと判定する。ステップS66で受信データを、送信の要求元であるアクセスロジック部20に渡すための情報として作成する。この情報にはたとえば受信したレスポンスデータとそのレスポンスデータを送信してきたプリンタのアドレスとが含まれている。
次に、図6(B)の通信相手アドレス登録処理について説明する。この処理は図4(A)のステップS30で、アクセスロジック部20がトランスポート部30の名前解決部301の名前−アドレス関連付け機能を呼び出すことで実行される処理である。図6(B)の通信相手アドレス登録処理は入力としてプリンタのFQDNとアドレスとの組が与えられる。ステップS71ではそのFQDNとアドレスとを関連付けて記憶する。通信相手先名−アドレス関連記憶部304に記憶されたFQDNとアドレスは、アドレスのキャッシュとして参照される。そのため、無参照時間が一定時間を超えたキャッシュのレコード(FQDNとアドレスとの対)に関しては、削除することが望ましい。アドレスが変更されている可能性があるためであり、また、記憶容量が有限なためである。また、キャッシュされたアドレスにリクエストを送信してレスポンスがない場合にも、そのレコードを削除することが望ましい。登録されるアドレスは、正規のレスポンスが返されたリクエストデータの送信先アドレスである。このほかたとえば正規のレスポンスの送信元アドレスであってもよい。
以上の手順により、送信先名称(FQDN)とパケットに付加した識別情報(リクエストID)とを関連づけることで、受信したレスポンスが、送信したリクエストに対応するレスポンスであることを識別できる。そのため、識別したレスポンス以外を廃棄するフィルタリング処理を実現できる。
さらに、IPv4とIPv6のアドレスを一回的に取得することができ、名前解決の回数や所要時間を低減できる。
また、通信に成功したアドレスを送信先名称(FQDN)と関連づけてキャッシュしておくことで、複数のアドレスがIPv6のDNSサーバに登録されている場合にも、パケット送信の試行回数を減少させることができる。これによりネットワークのトラフィックを低減させることができる。
なお本実施形態はプリンタドライバがプリンタに対して印刷データすなわちリクエストデータを送信する場合を例にとって説明したが、データ送信一般について適用することが可能である。すなわち、プリンタドライバ10に代えて、他のアプリケーションプログラムやシステムプログラムに対して本実施形態に係る発明を適用することができる。その場合、アクセスロジック部20とトランスポートロジック部30とが、代替のアプリケーションあるいはシステムプログラム対して、本実施形態と同様に機能する。
また本実施形態では、アクセスロジック部20とトランスポートロジック部30とが、プリンタドライバに含まれるものとして説明した。しかし、アクセスロジック部20とトランスポートロジック部30とは、プリンタドライバの外側にあって、ドライバロジック部40との間で関数呼び出しなどの適当なインターフェースにより呼び出されるものであってもよい。そのような構成であれば、所望のプログラムにアクセスロジック部20とトランスポートロジック部30とのインターフェースを記述することで、アクセスロジック部20とトランスポートロジック部30とを利用することができる。
またリクエストパケットすなわち送信データに含めるIDは、本実施形態では巡回的に生成される符号としたが、たとえば時刻や送信元アドレスと時刻の組み合わせなど、パケットを固有に識別できる符号であればよい。
また、本実施形態では、レスポンスデータと同じリクエストIDを持つリクエストデータが記憶されていた場合、IDのみを識別情報として正規のレスポンスと判定している。しかし、更にデータの内容を照合して、たとえば図7に示されたコマンドなど、対応するリクエストとレスポンスとに共通する値を持つフィールドを照合して一致すれば正規のレスポンスと判定してもよい。すなわちこの場合にはIDに加えて、リクエストとレスポンスの共通フィールドを識別情報として正規のレスポンスと判定する。
なお本発明は、複数の機器(例えばホストコンピュータ、インターフェース機器、リーダ、プリンタなど)から構成されるシステムに適用しても、一つの機器からなる装置(例えば、複写機、ファクシミリ装置など)に適用してもよい。
本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア(プログラム)をパソコン等の処理装置(CPU、プロセッサ)にて実行することでも実現できる。