JP2009232180A - 通信システム、処理要求装置、処理応答装置及びそのプログラム - Google Patents

Abstract

【課題】ＵＤＰを用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信プロトコルによる通信において、ＵＤＰで送信可能なデータ長の上限を超えるデータをやり取りする。
【解決手段】ユーザエージェントは、特殊タグが付加されたＳＬＰの属性要求メッセージＲｑ１をマルチキャストで送信する。サービスエージェントは、応答メッセージ長が１４００オクテットよりも大きければ、属性リストＡｔをｎ個に分割し、分割属性リストＡｔ１を、シーケンスナンバーＳＮ＝１、未送信の分割属性リストＡｔｉの存在を示す特殊タグのフラグ「ＯＮ」を付加して応答する。ユーザエージェントは、フラグ「ＯＦＦ」の応答を受信するまで、ＳＮ＝ｉを付した属性要求メッセージＲｑｉを送信し、その応答として、分割属性リストＡｔｉを取得する。
【選択図】図８

Description

本発明は、ＵＤＰを用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信プロトコルにより通信する通信技術に関する。

従来、ＵＤＰ（User Datagram Protocol）を用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した処理要求に対して、処理応答装置が応答する通信プロトコルとして、例えば、ＳＬＰ（Service Location Protocol）が知られている。

ＳＬＰは、ネットワーク上のサービスを検索可能なプロトコルであり、処理要求装置（ユーザエージェント）が、ネットワーク上の処理応答装置（サービスエージェント）に属性情報の取得を要求すると、処理応答装置は、自らの属性情報を処理要求装置に応答する。この際、ＵＤＰデータグラムからＵＤＰヘッダを除いたメッセージ長の上限は、イーサネット（登録商標）のＭＴＵ（Maximum Transmission Unit）から、１４００オクテット程度となる。したがって、応答メッセージ長が１４００オクテットを超える場合には、処理応答装置は、ＳＬＰの規格で定められたＯＶＥＲＦＬＯＷビットをＯＮにして、１４００オクテットに収まる一部のメッセージを応答する。ＯＶＥＲＦＬＯＷビットがＯＮの応答メッセージを受け取ると、処理要求装置は、再度、ＵＤＰに代えてＴＣＰ（Transmission Control Protocol）を用いて、属性情報の取得要求を行い、複数回のやり取りを経て、応答メッセージの全体を取得する。

しかしながら、上述の方法は、ＴＣＰを用いるために、処理要求装置へのＩＰアドレスの付与が前提であり、ＩＰアドレスが付与される前の段階では、使用することができなかった。かかる問題は、ＳＬＰの通信に限らず、ＵＤＰを用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信プロトコルを用いた通信に共通する問題であった。

特開２００６−２０２１９５号公報

上述の問題を踏まえ、本発明が解決しようとする課題は、ＵＤＰを用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信プロトコルによる通信において、ＵＤＰで送信可能なデータ長の上限を超えるデータをやり取りすることである。

本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。

［適用例１］ＵＤＰを用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信プロトコルにより、前記処理要求装置と前記処理応答装置とがネットワークを介して通信する通信システムであって、
前記処理要求装置は、
前記処理要求に対して応答すべき応答データが、前記ＵＤＰにより送信可能な所定容量を超える場合には、該応答データを分割して送信させる分割指示を前記処理要求に含める分割指示手段と、
前記分割指示を含む前記処理要求を送信する処理要求手段と
を備え、
前記処理応答装置は、
前記分割指示を含む処理要求を受信し、前記応答データが前記所定容量を超える場合に、該応答データを前記ＵＤＰにより送信可能な容量に分割する分割手段と、
該分割した各々の分割データに、前記応答データにおける該分割データの並び順を示す順序情報を付加する付加手段と、
前記順序情報を付加した前記分割データを、前記応答として、前記処理要求装置に送信する処理応答手段と
を備えた
通信システム。

かかる構成の通信システムにおいて、処理要求装置は、応答データがＵＤＰにより送信可能な所定容量を超える場合には、応答データを分割して送信させる分割指示を含めて、処理要求をマルチキャストまたはブロードキャストで送信する。一方、処理応答装置は、応答データが所定容量を超える場合には、応答データを分割した分割データに、順序情報を付加して応答する。したがって、ＵＤＰを用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信プロトコルによる通信において、ＵＤＰで送信可能なデータ長の上限を超えるデータをやり取りすることができる。また、ＵＤＰで送信可能なデータ長の上限を超えるデータであっても、ＴＣＰを用いた通信と比べてトラフィック量が小さいＵＤＰを用いて、やり取りを行えるので、ネットワーク負荷を軽減することができる。

［適用例２］通信プロトコルは、ＳＬＰである適用例１記載の通信システム。
かかる構成の通信システムにおいて、通信プロトコルをＳＬＰとしても、適用例１の効果を得ることができる。

［適用例３］適用例２記載の通信システムであって、付加手段は、各々の分割データに、更に、分割データが応答データを構成する最後の分割データであるか否かを示すフラグを付加し、処理要求装置は、更に、フラグを参照して、分割データを全て受け取ったことを判断する第１の判断手段を備える通信システム。

かかる構成の通信システムにおいて、処理応答装置は、分割データが応答データを構成する最後の分割データであるか否かを示すフラグを付加して、応答を行う。一方、処理要求装置は、当該フラグを参照して、分割データを全て受け取ったことを判断する。したがって、処理要求装置は、分割データを全て受け取ったことを容易に知ることができ、適切なタイミングで、処理応答装置とのやり取りを終了させることができる。

［適用例４］適用例２または適用例３記載の通信システムであって、付加手段は、各々の分割データに、更に、応答データのサイズを示すサイズ情報を付加し、処理要求装置は、更に、サイズ情報を参照して、分割データを全て受け取ったことを判断する第２の判断手段を備える通信システム。

かかる構成の通信システムにおいて、処理応答装置は、応答データのサイズを示すサイズ情報を付加して、応答を行う。一方、処理要求装置は、当該サイズ情報を参照して、分割データを全て受け取ったことを判断する。したがって、処理要求装置は、分割データを全て受け取ったことを容易に知ることができ、適切なタイミングで、処理応答装置とのやり取りを終了させることができる。

［適用例５］付加手段は、各々の分割データに、更に、処理応答装置の識別情報を付加する適用例２ないし適用例４のいずれか記載の通信システム。

かかる構成の通信システムにおいて、処理応答装置は、応答処理装置の識別情報を付加して、応答を行う。したがって、応答要求装置は、複数の応答処理装置から応答を受信した場合であっても、いずれの応答処理装置からの応答であるかを正確に判定することができる。

［適用例６］適用例１ないし適用例５のいずれか記載の通信システムであって、処理要求装置は、更に、処理要求に、所定のプロトコルの実行コマンドを含めるコマンド付加手段を備え、処理応答装置は、更に、処理要求に実行コマンドが含まれる場合に、実行コマンドを解釈して実行するコマンド実行手段を備え、処理応答装置は、実行コマンドの実行結果を応答データとして扱う通信システム。

かかる構成の通信システムにおいて、処理要求装置は、所定のプロトコルの実行コマンドを含めて、処理要求を送信する。一方、処理応答装置は、処理要求に実行コマンドが含まれる場合に、実行コマンドを解釈して実行し、その実行結果を応答データとして応答する。したがって、応答データ長が長くなることがあるが、そのような場合であっても、適用例１ないし適用例５のいずれかの構成により、応答データをやり取りすることができる。

［適用例７］適用例６記載の通信システムであって、処理応答装置は、実行コマンドの実行結果が所定の条件を満たしている場合に、実行コマンドの実行結果を応答データとして扱う通信システム。

かかる構成の通信システムにおいて、処理応答装置は、実行コマンドの実行結果が所定の条件を満たしている場合に、その結果を応答する。したがって、処理要求装置は、特定の処理応答装置からのみ応答を受け取るので、効率的に処理応答装置の応答を取得することができる。また、ネットワークの負荷を軽減できる。

また、本発明は、通信システムとしての構成のほか、処理応答装置、処理要求装置、コンピュータプログラム、通信方法としても実現することができる。

本発明の実施例について説明する。
Ａ．実施例：
Ａ−１．通信システムの概略構成：
本発明の実施例としての通信システム２０の概略構成を図１に示す。通信システム２０は、ユーザエージェントＵＡと、サービスエージェントＳＡ１，ＳＡ２とがローカルエリアネットワークＬＡＮを介して接続されている。ユーザエージェントＵＡは、所定のプログラムがインストールされた汎用のパーソナルコンピュータであり、サービスエージェントＳＡ１は、いわゆる複合機のプリンタ、ＳＡ２は、いわゆる単独機のプリンタである。なお、通信システム２０を構成するユーザエージェントまたはユーザエージェントの数は、本例に限定されるものではなく、任意の数を設定可能である。

Ａ−２．ユーザエージェントの概略構成：
通信システム２０を構成するユーザエージェントＵＡの概略構成を図２に示す。ユーザエージェントＵＡは、上述の通り、所定のプログラムがインストールされた汎用のパーソナルコンピュータであり、ＣＰＵ３０、ハードディスクドライブ４１、ＲＯＭ４２、ＲＡＭ４３、入力機構４５、ディスプレイ４６、インタフェース４９を備えている。

ＣＰＵ３０は、ハードディスクドライブ４１やＲＯＭ４２に記憶されたファームウェアやＯＳをＲＡＭ４３に展開して実行することで、ユーザエージェントＵＡの制御を司る。また、ＣＰＵ３０は、ハードディスクドライブ４１に記憶されたプログラムを実行することで、分割指示部３１、処理要求部３２、判断部３３、コマンド付加部３４として機能する。この機能部の詳細については、後述する。なお、コマンド付加部３４は、後述する変形例としての構成である。

入力機構４５は、キーボードとポインティングデバイス（ここではマウス）からなる。ディスプレイ４６は、液晶式のディスプレイである。インタフェース４９は、ユーザエージェントＵＡをローカルエリアネットワークＬＡＮに接続するためのインタフェースである。

Ａ−３．サービスエージェントの概略構成：
通信システム２０を構成するサービスエージェントＳＡ１の概略構成を図３に示す。サービスエージェントＳＡ１は、上述の通り、複合機のプリンタであり、ＣＰＵ５０、ＥＥＰＲＯＭ６１、ＲＯＭ６２、ＲＡＭ６３、入力機構６５、印刷機構６６、スキャナ６７、ＦＡＸ送信機構６８、インタフェース６９を備えている。なお、サービスエージェントＳＡ２は、スキャナ６７、ＦＡＸ送信機構６８を有していない点を除き、サービスエージェントＳＡ１と同様の構成であるため、その説明は省略する。

ＣＰＵ５０は、ＥＥＰＲＯＭ６１やＲＯＭ６２に記憶されたファームウェアやＯＳをＲＡＭ６３に展開して実行することで、サービスエージェントＳＡ１全体の制御を司る。また、ＣＰＵ５０は、ＥＥＰＲＯＭ６１に記憶されたプログラムを実行することで、分割部５１、付加部５２、処理応答部５３、コマンド実行部５４として機能する。この機能部の詳細については、後述する。なお、コマンド実行部５４は、後述する変形例としての構成である。

入力機構６５は、キーボードとＵＩを表示するディスプレイとからなる。印刷機構６６は、本実施例においては、インクジェット式の印刷機構である。インタフェース６９は、サービスエージェントＳＡ１をローカルエリアネットワークＬＡＮに接続するためのインタフェースである。

Ａ−４．ＵＤＰ分割送受信処理：
通信システム２０におけるＵＤＰ分割送受信処理について図４及び図５を用いて説明する。本実施例におけるＵＤＰ分割送受信処理とは、ユーザエージェントＵＡとサービスエージェントＳＡ１との間で、ＵＤＰを用いて、ＳＬＰの通信を行う際に、データを分割して送受信することで、ＵＤＰにより送信可能な容量を超えるデータのやり取りを可能にする処理である。ＵＤＰ分割送受信処理は、図４に示すユーザエージェントＵＡにおける分割要求処理と、図５に示すサービスエージェントＳＡ１における分割応答処理とにより構成される。

ユーザエージェントＵＡの分割要求処理は、図４に示すように、ユーザエージェントＵＡにおいて、ユーザが、ＳＬＰプログラムを起動させ、ディスプレイ４６に示されたＵＩと入力機構４５とを用いて、サービス検索条件を入力し、ユーザエージェントＵＡのＣＰＵ３０が、この検索指示を受け付けることで開始される（ステップＳ１００）。なお、ここでは、ローカルエリアネットワークＬＡＮ上の全てのプリンタに対して、属性の応答を求める検索指示とした。

検索指示を受け付けると、ＣＰＵ３０は、処理要求部３２の処理として、ＳＬＰの属性要求メッセージＲｑ１を作成し、ＵＤＰを用いてマルチキャストで送信する（ステップＳ１１０）。なお、本実施例では、マルチキャストで送信したが、ブロードキャストで送信してもよい。

この属性要求メッセージＲｑ１の構成を図６（ａ）に示す。図示する属性要求メッセージＲｑ１は、ＵＤＰデータグラムからＵＤＰヘッダを除いたデータ部分であり、ＳＬＰヘッダとメッセージ部分からなる。図示するように、属性要求メッセージＲｑ１のタグリストには、ベンダ拡張機能による特殊タグが付加されている。この特殊タグは、ＣＰＵ３０が分割指示部３１の処理として付加するものであり、属性要求メッセージＲｑ１に対する属性応答メッセージＲｐがＵＤＰにより送信可能な容量（ここでは１４００オクテット）を超える場合には、応答データを分割して送信させる分割指示を伝えるパラメータとしての役割を果たす。

一方、サービスエージェントＳＡ１は、図５に示すように、分割応答処理として、属性要求メッセージＲｑ１の受信を待機しており（ステップＳ２００）、属性要求メッセージＲｑ１を受信すれば（ステップＳ２００：ＹＥＳ）、ＣＰＵ５０は、属性要求メッセージＲｑ１を解釈して、これに対する属性リストＡｔを作成し、属性リストＡｔを含む属性応答メッセージＲｐのＳＬＰヘッダ以下のデータ長が１４００オクテットよりも大きいか否かを判断する（ステップＳ２１０）。

その結果、１４００オクテット以下であれば（ステップＳ２１０：ＮＯ）、属性応答メッセージＲｐは、ＵＤＰで一度に送信できるデータサイズ以下であるということであり、ＣＰＵ５０は、処理応答部５３の処理として、作成した属性リストＡｔを全て含む属性応答メッセージＲｐ１を、ＵＤＰを用いて、ユーザエージェントＵＡに対してユニキャストで送信し（ステップＳ３００）、処理を元に戻す。なお、この際、サービスエージェントＳＡ１は、属性リストＡｔの全てを送信するため、ＳＬＰヘッダのＯＶＥＲＦＬＯＷフラグは「ＯＦＦ」となっている。

一方、１４００オクテットよりも大きければ（ステップＳ２１０：ＹＥＳ）、属性応答メッセージＲｐは、ＵＤＰで一度に送信できるデータサイズを超えているということであり、ＣＰＵ５０は、続けて、受信した属性要求メッセージＲｑ１内に特殊タグが含まれているか否かを判断する（ステップＳ２２０）。

その結果、特殊タグが含まれていなければ（ステップＳ２２０：ＮＯ）、属性リストＡｔを分割して送信する必要はないということである。そこで、ＣＰＵ５０は、処理応答部５３の処理として、作成した属性リストＡｔの一部を基に、属性応答メッセージＲｐのサイズが１４００オクテットに収まる範囲で、属性応答メッセージＲｐ１を作成して、ＵＤＰを用いて、ユーザエージェントＵＡに対してユニキャストで送信し（ステップＳ２９０）、処理を元に戻す。なお、この際、サービスエージェントＳＡ１は、属性リストＡｔの一部しか送信できないため、ＳＬＰヘッダのＯＶＥＲＦＬＯＷフラグは「ＯＮ」となっている。

一方、特殊タグが含まれていれば（ステップＳ２２０：ＹＥＳ）、属性リストＡｔを分割して送信する必要があるということであり、ＣＰＵ５０は、分割部５１の処理として、属性応答メッセージＲｐが１４００オクテットに収まるように、属性リストＡｔをｎ個に分割する（ステップＳ２３０）。そして、ＣＰＵ５０は、ｎ個に分割した分割属性リストＡｔｉ（ｉ＝１〜ｎ）のうち、属性リストＡｔの先頭を構成する分割属性リストＡｔ１を基に、属性応答メッセージＲｐ１を作成し、処理応答部５３の処理として、ＵＤＰを用いて、ユーザエージェントＵＡに対してユニキャストで送信する（ステップＳ２４０）。なお、この際、サービスエージェントＳＡ１は、分割属性リストＡｔ１の全てを送信するため、ＳＬＰヘッダのＯＶＥＲＦＬＯＷフラグは「ＯＦＦ」となっている。

この属性応答メッセージＲｐ１の構成を図７（ａ）に示す。属性応答メッセージＲｐ１は、ＵＤＰデータグラムからＵＤＰヘッダを除いたデータ部分であり、ＳＬＰヘッダとメッセージ部分からなる。図示するように、属性応答メッセージＲｐ１の属性リストのうちベンダ拡張領域には、属性要求メッセージＲｑに含まれていた特殊タグ、サービスエージェントＳＡ１の識別情報、分割属性リストＡｔｉの並び順を示すシーケンスナンバーＳＮが付加されている。これらの情報は、ＣＰＵ５０が、付加部５２の処理として付加するものである。特殊タグは、分割属性リストＡｔ１に続き受け取るべき分割属性リストが他に存在するか否かを示すフラグビットを有している。ここでは、分割属性リストＡｔ１に続き受け取るべき分割属性リストが他に存在するので、フラグは、そのことを示す「ＯＮ」となっている。シーケンスナンバーＳＮは、請求項の順序情報に該当し、分割属性リストＡｔ１に対応する「１」となっている。識別情報は、本実施例では、サービスエージェントＳＡ１のＭＡＣアドレスとした。

属性応答メッセージＲｐ１を送信すると、ＣＰＵ５０は、属性要求メッセージＲｑｉの受信を待機する（ステップＳ２５０）。この属性要求メッセージＲｑｉは、ユーザエージェントＵＡが、属性要求メッセージＲｑ１を送信した後に更に送信し、属性リストＡｔを構成するｉ番目の分割属性リストＡｔｉの送信を要求するものであり、その詳細については、後述する。

そして、属性要求メッセージＲｑｉを受信すると（ステップＳ２５０：ＹＥＳ）、ＣＰＵ５０は、属性要求メッセージＲｑｉに含まれるシーケンスナンバーＳＮ（＝ｉ）を参照し、ＳＮが、属性リストＡｔの分割数であるｎに等しいか否かを判断する（ステップＳ２６０）。その結果、シーケンスナンバーＳＮがｎでなければ（ステップＳ２６０：ＮＯ）、属性要求メッセージＲｑｉは、属性リストＡｔを構成する最後の分割属性リストＡｔｎを要求するものではないということである。そこで、ＣＰＵ３０は、付加部５２の処理として、図７（ｂ）に示すように、属性要求メッセージＲｑｉに含まれるシーケンスナンバーＳＮ「ｉ」に対応するｉ番目の分割属性リストＡｔｉに、識別情報とシーケンスナンバーＳＮ「ｉ」とを付加すると共に、送信する分割属性リストＡｔｉに続きがあることを示すために、特殊タグのフラグを「ＯＮ」として、属性応答メッセージＲｐｉを作成し、処理応答部５３の処理として、ＵＤＰを用いて、ユーザエージェントＵＡに対してユニキャストで送信する（ステップＳ２８０）。そして、処理をステップＳ２５０に戻し、受信した属性要求メッセージＲｑｉのシーケンスナンバーＳＮがｎとなるまで、ステップＳ２５０，Ｓ２６０及びＳ２８０の処理を繰り返すのである。

一方、シーケンスナンバーＳＮがｎであれば（ステップＳ２６０：ＹＥＳ）、属性要求メッセージＲｑｉは、属性リストＡｔを構成する最後の分割属性リストＡｔｎを要求するものであるということである。そこで、ＣＰＵ３０は、付加部５２の処理として、図７（ｃ）に示すように、分割属性リストＡｔｎに、識別情報と、シーケンスナンバーＳＮ「ｎ」とを付加すると共に、送信する分割属性リストＡｔｎに続きがないことを示すために、特殊タグのフラグを「ＯＦＦ」として、属性応答メッセージＲｐｎを作成し、処理応答部５３の処理として、ＵＤＰを用いて、ユーザエージェントＵＡに対してユニキャストで送信する（ステップＳ２７０）。

ここで、説明をユーザエージェントＵＡに戻す。ユーザエージェントＵＡでは、図４に示すように、ステップＳ１１０で属性要求メッセージＲｑ１を送信した後、サービスエージェントＳＡ１からの属性応答メッセージＲｐｉの受信を待機している（ステップＳ１２０）。そして、属性応答メッセージＲｐｉ（最初はＲｑ１）を受信すると（ステップＳ１２０：ＹＥＳ）、ＣＰＵ３０は、判断部３３の処理として、属性応答メッセージＲｐｉに含まれる特殊タグのフラグが「ＯＮ」であるか否かを判断する（ステップＳ１３０）。

その結果、フラグが「ＯＦＦ」であれば（ステップＳ１３０：ＮＯ）、サービスエージェントＳＡ１が応答すべき属性リストには、続きがないということであり、ＣＰＵ３０は、分割要求処理を終了する。そして、ＣＰＵ３０は、複数の分割属性リストＡｔｉを受信した場合には、これらを合成して属性リストＡｔを生成する。ＣＰＵ３０は、こうして得られた属性リストＡｔの内容を、ディスプレイ４６に表示させるのである。

一方、フラグが「ＯＮ」であれば（ステップＳ１３０：ＹＥＳ）、受信した属性応答メッセージＲｐｉに含まれる分割属性リストＡｔｉには続きがあるということである。そこで、ＣＰＵ３０は、属性応答メッセージＲｐｉに含まれるシーケンスナンバーＳＮを１インクリメント（ＳＮ：ｉ→ｉ＋１）して（ステップＳ１４０）、当該シーケンスナンバーＳＮを付加したＳＬＰの属性要求メッセージＲｑ（ｉ＋１）を、処理要求部３２の処理として作成し、ＵＤＰを用いてマルチキャストで送信する（ステップＳ１５０）。

この属性要求メッセージＲｑ（ｉ＋１）の構成を図６（ｂ）に示す。属性要求メッセージＲｑ（ｉ＋１）は、ステップＳ１１０で送信した属性要求メッセージＲｑ１の構成（図６（ａ）参照）に加えて、ベンダ拡張領域に、シーケンスナンバーＳＮ（ｉ＋１）が付加されている。この付加したシーケンスナンバーＳＮにより、ユーザエージェントＵＡは、サービスエージェントＳＡ１に、分割属性リストＡｔ（ｉ＋１）を要求するのである。

こうして、属性要求メッセージＲｑ（ｉ＋１）を送信すると、ＣＰＵ３０は、処理を上記ステップＳ１２０に戻し、受信した特殊タグのフラグが「ＯＦＦ」になるまで、すなわち、分割された分割属性リストＡｔｉを全て受け取るまで、ステップＳ１２０〜Ｓ１５０の処理を繰り返すのである。

かかるユーザエージェントＵＡとサービスエージェントＳＡ１との間の処理の流れの具体例を図８に示す。まず、ユーザエージェントＵＡは、特殊タグ「ｘ−１２４８−ｐ−ｕｓｅｄｉｖ」を含めて属性要求メッセージＲｑ１をサービスエージェントＳＡ１に送信する。これに対して、サービスエージェントＳＡ１は、分割属性リストＡｔ１に、特殊タグのフラグ「ｘ−１２４８−ｐ−ｕｓｅｄｉｖ＝ＯＮ」、サービスエージェントＳＡ１の識別情報「ｐ−１２４８−ＩＤ−００００４８ＡＡＡＡＡＡＡ」、シーケンスナンバー「ｐ−１２４８−ｓｅｑ＝１」を付加して、属性応答メッセージＲｐ１を応答する。

一方、ユーザエージェントＵＡは、属性応答メッセージＲｐ１を受信すると、それに含まれる特殊タグのフラグが「ＯＮ」であることから、特殊タグ「ｘ−１２４８−ｐ−ｕｓｅｄｉｖ」、シーケンスナンバー「ｐ−１２４８−ｓｅｑ＝２」を含めた属性要求メッセージＲｑ２をサービスエージェントＳＡ１に送信する。これに対して、サービスエージェントＳＡ１は、分割属性リストＡｔ２に、特殊タグのフラグ「ｘ−１２４８−ｐ−ｕｓｅｄｉｖ＝ＯＮ」、識別情報「ｐ−１２４８−ＩＤ−００００４８ＡＡＡＡＡＡＡ」、シーケンスナンバー「ｐ−１２４８−ｓｅｑ＝２」を付加して、属性応答メッセージＲｐ２を応答する。

同様に、ユーザエージェントＵＡは、属性応答メッセージＲｐ２を受信すると、それに含まれる特殊タグのフラグが「ＯＮ」であることから、特殊タグ「ｘ−１２４８−ｐ−ｕｓｅｄｉｖ」、シーケンスナンバー「ｐ−１２４８−ｓｅｑ＝３」を含めた属性要求メッセージＲｑ２をサービスエージェントＳＡ１に送信する。これに対して、サービスエージェントＳＡ１は、分割属性リストＡｔ３に、特殊タグのフラグ「ｘ−１２４８−ｐ−ｕｓｅｄｉｖ＝ＯＦＦ」、識別情報「ｐ−１２４８−ＩＤ−００００４８ＡＡＡＡＡＡＡ」、シーケンスナンバー「ｐ−１２４８−ｓｅｑ＝３」を付加して、属性応答メッセージＲｐ３を応答する。

そして、ユーザエージェントＵＡは、属性応答メッセージＲｐ３を受信すると、それに含まれる特殊タグのフラグが「ＯＦＦ」であることから、全ての分割属性リストＡｔｉ（ここでは分割属性リストＡｔ１〜Ａｔ３）を受け取ったと判断して、分割要求処理を終了するのである。

なお、説明は省略したが、ユーザエージェントＵＡは、図４のステップ１１０において、マルチキャストで属性要求メッセージＲｑ１を送信しているので、上述したユーザエージェントＵＡとサービスエージェントＳＡ１との間での通信の他に、ユーザエージェントＵＡとサービスエージェントＳＡ２との間でも同様の通信が行われる。この場合、ユーザエージェントＵＡは、サービスエージェントＳＡ１とサービスエージェントＳＡ２とから、それぞれ属性応答メッセージＲｐｉを受け取ることとなるが、属性応答メッセージＲｐｉには、サービスエージェントＳＡ１，ＵＡ２の識別情報が含まれているので、ユーザエージェントＵＡは、サービスエージェントＳＡ１からの応答と、サービスエージェントＳＡ２からの応答とを正確に判別することができる。

また、本実施例においては、ＳＬＰの通信についてのＵＤＰ分割送受信処理について示したが、通信プロトコルは、特にＳＬＰに限定するものではなく、ＵＤＰを用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信プロトコルであればよく、メーカー独自定義のプロトコルなどであってもよい。

かかる構成の通信システム２０において、ユーザエージェントＵＡは、ユーザエージェントＵＡの属性要求メッセージＲｑに対する応答がＵＤＰにより送信可能な所定容量を超える場合には、応答内容を分割して送信させる分割指示を示す特殊タグを含めて、属性要求メッセージＲｑ１をマルチキャストまたはブロードキャストで送信する。一方、サービスエージェントＳＡ１は、属性要求メッセージＲｑ１に対する応答である属性リストＡｔが所定容量を超える場合には、属性リストＡｔを分割した分割属性リストＡｔｉに、シーケンスナンバーＳＮを付加して応答する。したがって、ＵＤＰを用いたＳＬＰの通信において、ＵＤＰで送信可能なデータ長の上限を超えるデータをやり取りすることができる。また、これにより、サービスエージェントにＩＰアドレスを付与していない環境下においても、ＳＬＰの通信を行うことができる。さらに、ＵＤＰで送信可能なデータ長の上限を超えるデータであっても、ＴＣＰを用いた通信と比べてトラフィック量が小さいＵＤＰを用いて、やり取りを行えるので、ネットワーク負荷を軽減することができる。

また、かかる構成の通信システム２０において、サービスエージェントＳＡ１は、サービスエージェントＳＡ１が送信する分割属性リストＡｔｉが属性リストＡｔを構成する最後の分割属性リストＡｔｎであるか否かを示す特殊タグのフラグを付加して、応答を行う。一方、ユーザエージェントＵＡは、当該フラグを参照して、フラグが「ＯＦＦ」の場合に分割属性リストＡｔｉを全て受け取ったことを判断する。したがって、ユーザエージェントＵＡは、分割属性リストＡｔｉを全て受け取ったことを容易に知り、適切なタイミングで、サービスエージェントＳＡ１とのやり取りを終了させることができる。

なお、ＳＬＰの標準規格においては、サービスエージェントは、受信した属性要求メッセージＲｑに不明なタグが含まれる場合には、当該タグを返信しない。すなわち、ローカルエリアネットワークＬＡＮ上に、本発明に対応しない未対応サービスエージェントが混在する環境下において、ユーザエージェントがマルチキャストで送信した、特殊タグを含む属性要求メッセージＲｑを、当該未対応サービスエージェントが受信しても、支障が生じることがない。したがって、本発明は、既存のサービスエージェントとの互換性もよい。

Ｂ．変形例：
上述した実施例の変形例について説明する。
Ｂ−１．変形例１：
実施例では、属性リストＡｔを分割送信する場合において、サービスエージェントＳＡ１は、ユーザエージェントＵＡがステップＳ１１０で送信した属性要求メッセージＲｑ１に対して、分割属性リストＡｔ１を含む属性応答メッセージＲｐ１を応答する構成としたが、このような構成に限られるものではない。例えば、最初の応答には、分割属性リストＡｔ１を含まない構成とし、最初の応答に含まれる特殊タグのフラグによって分割送信が必要であることを認識したユーザエージェントＵＡから改めて送信される属性要求メッセージＲｑｉに対して、分割属性リストＡｔｉを応答する構成としてもよい。

Ｂ−２．変形例２：
実施例においては、ユーザエージェントＵＡは、サービスエージェントＳＡ１から受信した属性応答メッセージＲｐｉに含まれる特殊タグのフラグに基づいて、メッセージに続きがあるか否かを判断する構成としたが、メッセージの受信完了判断は、このような構成に限られるものではない。例えば、ユーザエージェントＵＡのＣＰＵ３０は、受信した分割属性リストＡｔｉの累計サイズと、属性応答メッセージＲｐｉに含まれる属性リストＡｔの全長サイズ（例えば、図７（ａ）の「length of 」）とから、メッセージの受信完了判断を行ってもよい。かかる構成によっても、ユーザエージェントＵＡは、分割属性リストＡｔｉを全て受け取ったことを容易に知ることができ、適切なタイミングで、サービスエージェントＳＡ１とのやり取りを終了させることができる。

また、実施例においては、ユーザエージェントＵＡは、サービスエージェントＳＡ１から、分割属性リストＡｔｉを全て受け取ったと判断した場合に、図４に示した分割要求処理を終了する構成としたが、分割要求処理の終了タイミングは、これに限るものではない。例えば、処理開始から所定時間経過後に終了する構成としてもよい。あるいは、処理開始から所定時間経過後に、始めからリトライする構成としてもよい。また、図４のステップＳ１５０において属性応答メッセージＲｐｉを送信したにも拘わらず、所定時間以内にサービスエージェントＳＡ１からの属性応答メッセージＲｐｉを受信しない（ステップＳ１２０：ＮＯ）場合には、属性応答メッセージＲｐｉを再送する構成としてもよい。こうすれば、何らかの理由により、ＵＤＰデータグラムがローカルエリアネットワークＬＡＮ上で喪失された場合であっても、対応することができる。

Ｂ−３．変形例３：
サービスエージェントＳＡ１は、図５のステップＳ２３０において、属性リストＡｔの分割に失敗した場合には、特殊タグのフラグを「ＦＡＩＬＥＤ」とする構成を追加してもよい。この場合、フラグが「ＦＡＩＬＥＤ」である特殊タグを含む属性応答メッセージＲｐ１を受信したユーザエージェントＵＡは、分割要求処理を終了する構成としてもよい。

また、サービスエージェントＳＡ１は、分割属性リストＡｔｉを作成し、ユーザエージェントＵＡと分割セッション中である場合に、受信した属性要求メッセージＲｑｉに含まれるシーケンスナンバーＳＮが無効でものであるときは、属性要求メッセージＲｑｉがマルチキャストであれば応答せず、属性要求メッセージＲｑｉがユニキャストであればエラーを返す構成としてもよい。また、分割セッション中でない場合に、受信した属性要求メッセージＲｑ１にシーケンスナンバーＳＮが含まれるときは、属性要求メッセージＲｑｉがマルチキャストであれば応答せず、属性要求メッセージＲｑｉがユニキャストであればエラーを返す構成としてもよい。

Ｂ−４．変形例４：
実施例においては、サービスエージェントＳＡ１は、ユーザエージェントＵＡからの分割属性リストＡｔｉに応じて、分割属性リストＡｔｉを、属性リストＡｔを構成する並び順に送信する構成としたが、送信順序は、特に限定するのではなく、例えば、属性リストＡｔを構成する並び順の逆から送信してもよいし、ランダムな順番で送信してもよい。ユーザエージェントＵＡは、１〜ｎのシーケンスナンバーＳＮを付した属性要求メッセージＲｑｉを送信し、サービスエージェントＳＡ１は、当該シーケンスナンバーＳＮに一意に対応する分割属性リストＡｔｉの並び順を示す順序情報を付加して、応答すればよいのである。

また、サービスエージェントＳＡ１が付加する順序情報は、一意の並び順を示す番号に限らず、ユーザエージェントＵＡが、受信した分割属性リストＡｔｉの並び順を解釈できるものであればよい。例えば、送信対象の分割属性リストＡｔｉの送信の直前に送信した分割属性リストＡｔｉの番号や、直後に送信する分割属性リストＡｔｉの番号を示すものとしてもよい。

Ｂ−５．変形例５：
実施例においては、ユーザエージェントＵＡがマルチキャストで送信する属性要求メッセージＲｑ１に対して、全てのサービスエージェントＳＡ１，ＳＡ２が応答する構成としたが、特定のサービスエージェント、例えば、サービスエージェントＳＡ１のみから属性情報を取得する構成としてもよい。このような構成は、例えば、以下のようにして実現することができる。

まず、ユーザエージェントＵＡのＣＰＵ３０は、図４のステップＳ１１０において、所定のＳＬＰ検索条件と、所定のプロトコルの実行コマンドを含めて属性要求メッセージＲｑ１を作成し、ＵＤＰを用いてマルチキャストで送信する。この実行コマンドの付加は、コマンド付加部３４の処理として行われる。所定のプロトコルとしては、種々のものが利用可能であるが、例えば、ＳＮＭＰ（Simple Network Management Protocol）を利用することができる。

属性要求メッセージＲｑ１の内容の具体例を図９に示す。図９（ａ）は、ＳＮＭＰの実行コマンドを含まない場合のサービス検索要求の概念図である。ここでは、具体例として、ＬＡＮに接続されたＥＰＳＯＮプリンタの製品名を検索する場合について説明する。属性要求メッセージＲｑ１のＵＲＬには、検索するサービスの情報として、装置の製造者名を示す「ｐ−ｄｅｖ．１２４８」（ＥＰＳＯＮを表す）や検索するサービス種別を示す「ｐｒｉｎｔｅｒ」が格納され、タグリストには、ベンダの拡張機能を示す「ｘ−１２４８−ｐ−ｄｅｖ．」や製品名を示す「ｐｎ」などの検索対象の固有の情報と、特殊タグ「ｘ−１２４８−ｐ−ｕｓｅｄｉｖ」とが格納されている。

一方、図９（ｂ）は、ＳＮＭＰの実行コマンドを含む場合のサービス検索要求の概念図である。この場合、属性要求メッセージＲｑ１のタグリストには、ベンダの拡張機能を示す「ｘ−１２４８」や拡張機能で定義したＳＮＭＰを処理するアトリビュートである「ｐ−ｓｐｔ」、内部的にＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ−ＰＤＵを処理することを示す「ｓｎｍｐｇｅｔ」、ｓｎｍｐｇｅｔをＳＮＭＰｖ１で行うことを示す「Ｖ１」、コミュニティネームである「ｐｕｂｌｉｃ」、ＭＩＢのオブジェクトＩＤとしての「１．３．６．１．２．１．１．５．０」（ｓｙｓＮａｍｅを表す）、上記コマンドの実行結果が適合したときにこの検索要求の応答を実行するよう定められた処理実行条件としての「ｒｅｓｕｌｔ：ｎｏＥｒｒｏｒ」などの検索対象の情報と、特殊タグ「ｘ−１２４８−ｐ−ｕｓｅｄｉｖ」とが格納されている。即ち、このタグリストの内容は、ＳＮＭＰのコマンドを実行した結果が「ｎｏＥｒｒｏｒ」であるときに検索要求に対する応答を返すよう定めたものとなっている。

なお、このタグリストには、その先頭に「｛」、最後尾に「｝」及び内容の区切りに「｜」など、ＳＬＰのタグリストの記述に規定されている以外の文字を用いることにより、ＳＮＭＰの実行コマンドが格納されているか否かの判定が容易となっているのである。なお、ここでは、説明の便宜のため、ＳＮＭＰのコマンド等を「ｎｏＥｒｒｏｒ」などの文字として説明したが、実際には、タグリストの内容は、「０２０１００」（ｎｏＥｒｒｏｒを表す１６進数）のようにＳＮＭＰでの取り決めに従って記述されている。

かかる属性要求メッセージＲｑ１を受信した場合の、サービスエージェントＳＡ１の分割応答処理の流れについて、図５に示した分割応答処理と異なる点を図１０に示す。ステップＳ２００において属性要求メッセージＲｑ１を受信すると（ステップＳ２００：ＹＥＳ）、ＣＰＵ５０は、属性要求メッセージＲｑ１にＳＮＭＰコマンドが含まれているか否かを判断する（ステップＳ３１０）。

その結果、ＳＮＭＰのコマンドが含まれていれば（ステップＳ３１０：ＹＥＳ）、ＣＰＵ５０は、属性要求メッセージＲｑ１に格納されたタグリストからＳＮＭＰのコマンドを取得し、コマンド実行部５４の処理として、このコマンドを実行する（ステップＳ３２０）。そして、ＣＰＵ５０は、コマンドを実行した結果が、タグリストに記述された処理実行条件を満たすか否かを判断する（ステップＳ３３０）。本例では、上述の通り、コマンド実行結果が「ｎｏＥｒｒｏｒ」であるか否かにより処理実行条件を満たすか否かを判定する。

その結果、処理実行条件を満たしていなければ（ステップＳ３３０：ＮＯ）、ＣＰＵ５０は、属性要求メッセージＲｑ１に対する応答を行わずに、処理を元に戻す。一方、処理実行条件を満たしていれば（ステップＳ３３０：ＹＥＳ）、ＣＰＵ５０は、処理をステップＳ２１０に進める。その後の処理は、図５で説明した通りである。

また、上記ステップＳ３１０において、ＳＮＭＰコマンドが含まれていなければ（ステップＳ３１０：ＮＯ）、ＣＰＵ５０は、タグリストに指定された検索条件とＥＥＰＲＯＭ６１などに記憶されたサービスエージェントＳＡ１の情報とが一致するか否か、即ち、検索条件を満たすか否かを判定する（ステップＳ３４０）。その結果、検索条件と一致しなければ（ステップＳ３４０：ＮＯ）、ＣＰＵ５０は、属性要求メッセージＲｑ１に対する応答を行わずに、処理を元に戻す。一方、検索条件と一致すれば（ステップＳ３４０：ＹＥＳ）、ＣＰＵ５０は、処理をステップＳ２１０に進める。その後の処理は、図５で説明した通りである。

なお、本変形例においては、ユーザエージェントＵＡは、検索条件と処理実行条件とを含む属性要求メッセージＲｑ１を作成・送信したが、これらの条件のうち、いずれか一方のみを作成・送信する構成としてもよい。また、サービスエージェントＳＡ１は、ステップＳ３３０において、処理実行条件を満たすか否かの判断を行い、処理実行条件を満たす場合のみ処理をステップＳ２１０に進める構成とした。かかる構成とすることにより、ユーザエージェントＵＡは、特定のサービスエージェントからのみ、必要な情報を取得することができるので、ユーザエージェントＵＡの処理が効率的になると共に、ローカルエリアネットワークＬＡＮの負荷を低減することができるからである。ただし、このような構成に限る必要はなく、ステップＳ３３０を省略して、ＳＮＭＰコマンドを実行した場合には、必ず、処理をステップＳ２１０に進める構成としてもよい。

かかる構成の通信システム２０においては、ユーザエージェントＵＡは、検索条件や、ＳＮＭＰの実行コマンド、更には、ＳＮＭＰの実行結果に基づく処理実行条件を含んで、属性要求メッセージＲｑ１を送信する。一方、サービスエージェントＳＡ１，ＳＡ２は、検索条件や処理実行条件を満たす場合にのみ、応答を行う。したがって、ユーザエージェントＵＡは、特定のサービスエージェントの情報のみを効率的に取得することができる。また、これにより、ローカルエリアネットワークＬＡＮのトラフィック量を低減することができる。

また、かかる構成の通信システム２０においては、ユーザエージェントＵＡは、ＳＮＰＭの実行コマンドを含めて属性要求メッセージＲｑ１を送信する。一方、サービスエージェントＳＡ１，ＳＡ２は、検索条件や処理実行条件を満たす場合には、ＳＮＭＰの実行結果を属性応答メッセージとして応答する。したがって、通常のＳＬＰ通信と比べて、属性応答メッセージの容量が大きくなりがちであるが、属性応答メッセージの容量がＵＤＰの通信可能容量を超える場合であっても、通信システム２０は、実施例に示したように、ＵＤＰを用いて属性リストＡｔを分割送受信することが可能である。

以上、本発明の実施形態について説明したが、本発明はこうした実施形態に限られるものではなく、本発明の要旨を脱しない範囲において、種々なる態様で実施できることは勿論である。例えば、本発明は、ユーザエージェントとしてのパーソナルコンピュータ、サービスエージェントとしてのプリンタとしての構成を例示したが、ユーザエージェント及びサービスエージェントは、携帯電話、デジタルカメラ、ＦＡＸ、ルータなど、種々のネットワーク機器として実現することができる。また、本発明は、実施例に示した通信システムやユーザエージェントまたはサービスエージェントとしての構成に限らず、プログラム、通信方法等の形態でも実現することができる。

通信システム２０の概略構成を示す説明図である。 ユーザエージェントＵＡの概略構成を示す説明図である。 サービスエージェントＳＡ１の概略構成を示す説明図である。 ユーザエージェントＵＡにおける分割要求処理の流れを示すフローチャートである。 サービスエージェントＳＡ１における分割応答処理の流れを示すフローチャートである。 属性要求メッセージの具体例を概念的に示す説明図である。 属性応答メッセージの具体例を概念的に示す説明図である。 ユーザエージェントＵＡとサービスエージェントＳＡ１との間での通信を示す説明図である。 変形例としての属性要求メッセージの具体例を概念的に示す説明図である。 変形例としてのサービスエージェントＳＡ１における分割応答処理の流れを示すフローチャートである。

符号の説明

２０...通信システム
３０...ＣＰＵ
３１...分割指示部
３２...処理要求部
３３...判断部
３４...コマンド付加部
４１...ハードディスクドライブ
４２...ＲＯＭ
４３...ＲＡＭ
４５...入力機構
４６...ディスプレイ
４９...インタフェース
５０...ＣＰＵ
５１...分割部
５２...付加部
５３...処理応答部
５４...コマンド実行部
６１...ＥＥＰＲＯＭ
６２...ＲＯＭ
６３...ＲＡＭ
６５...入力機構
６６...印刷機構
６７...スキャナ
６８...ＦＡＸ送信機構
６９...インタフェース
ＵＡ...ユーザエージェント
ＳＡ１，ＳＡ２...サービスエージェント
ＬＡＮ...ローカルエリアネットワーク

Claims (11)

1. ＵＤＰを用いて、処理要求装置がマルチキャストまたはブロードキャストで送信した所定の処理要求に対して、処理応答装置が応答する通信プロトコルにより、前記処理要求装置と前記処理応答装置とがネットワークを介して通信する通信システムであって、
   前記処理要求装置は、
   前記処理要求に対して応答すべき応答データが、前記ＵＤＰにより送信可能な所定容量を超える場合には、該応答データを分割して送信させる分割指示を前記処理要求に含める分割指示手段と、
   前記分割指示を含む前記処理要求を送信する処理要求手段と
   を備え、
   前記処理応答装置は、
   前記分割指示を含む処理要求を受信し、前記応答データが前記所定容量を超える場合に、該応答データを前記ＵＤＰにより送信可能な容量に分割する分割手段と、
   該分割した各々の分割データに、前記応答データにおける該分割データの並び順を示す順序情報を付加する付加手段と、
   前記順序情報を付加した前記分割データを、前記応答として、前記処理要求装置に送信する処理応答手段と
   を備えた
   通信システム。
2. 前記通信プロトコルは、ＳＬＰである請求項１記載の通信システム。
3. 請求項２記載の通信システムであって、
   前記付加手段は、前記各々の分割データに、更に、該分割データが前記応答データを構成する最後の分割データであるか否かを示すフラグを付加し、
   前記処理要求装置は、更に、前記フラグを参照して、前記分割データを全て受け取ったことを判断する第１の判断手段を備える
   通信システム。
4. 請求項２または請求項３記載の通信システムであって、
   前記付加手段は、前記各々の分割データに、更に、前記応答データのサイズを示すサイズ情報を付加し、
   前記処理要求装置は、更に、前記サイズ情報を参照して、前記分割データを全て受け取ったことを判断する第２の判断手段を備える
   通信システム。
5. 前記付加手段は、前記各々の分割データに、更に、前記処理応答装置の識別情報を付加する請求項２ないし請求項４のいずれか記載の通信システム。
6. 請求項１ないし請求項５のいずれか記載の通信システムであって、
   前記処理要求装置は、更に、前記処理要求に、所定のプロトコルの実行コマンドを含めるコマンド付加手段を備え、
   前記処理応答装置は、更に、前記処理要求に前記実行コマンドが含まれる場合に、該実行コマンドを解釈して実行するコマンド実行手段を備え、
   前記処理応答装置は、前記実行コマンドの実行結果を前記応答データとして扱う
   通信システム。
7. 請求項６記載の通信システムであって、
   前記処理応答装置は、前記実行コマンドの実行結果が所定の条件を満たしている場合に、前記実行コマンドの実行結果を前記応答データとして扱う
   通信システム。
8. ネットワークを介して接続された処理要求装置から、ＵＤＰを用いて、マルチキャストまたはブロードキャストで送信された所定の処理要求に対して、応答する処理応答装置であって、
   所定のパラメータを含む前記処理要求を受信した場合であって、前記処理要求に対して応答すべき応答データが、前記ＵＤＰにより送信可能な所定容量を超えるときは、該応答データを前記ＵＤＰにより送信可能な容量に分割する分割手段と、
   該分割した各々の分割データに、前記応答データにおける該分割データの並び順を示す順序情報を付加する付加手段と、
   前記順序情報を付加した前記分割データを、前記応答として、前記処理要求装置に送信する応答手段と
   を備えた処理応答装置。
9. ネットワークを介して接続された処理応答装置に、ＵＤＰを用いて、マルチキャストまたはブロードキャストで所定の処理要求を送信する処理要求装置であって、
   前記処理要求に対して前記処理応答装置が応答すべき応答データが、前記ＵＤＰにより送信可能な所定容量を超える場合には、該応答データを分割して送信させる分割指示を前記処理要求に含める分割指示手段と、
   前記分割指示を含む前記処理要求を送信する要求手段と
   を備えた処理要求装置。
10. ネットワークを介して接続された処理要求装置から、ＵＤＰを用いて、マルチキャストまたはブロードキャストで送信された所定の処理要求に対して、応答するためのコンピュータプログラムであって、
    所定のパラメータを含む前記処理要求を受信した場合であって、前記処理要求に対して応答すべき応答データが、前記ＵＤＰにより送信可能な所定容量を超えるときは、該応答データを前記ＵＤＰにより送信可能な容量に分割する分割機能と、
    該分割した各々の分割データに、該分割データが前記応答データを構成する何番目のデータであるかを示す順序情報を付加する付加機能と、
    前記順序情報を付加した前記分割データを、前記応答として、前記処理要求装置に送信する応答機能と
    をコンピュータに実現させるプログラム。
11. ネットワークを介して接続された処理応答装置に、ＵＤＰを用いて、マルチキャストまたはブロードキャストで所定の処理要求を送信するためのコンピュータプログラムであって、
    前記処理要求に対して前記処理応答装置が応答すべき応答データが、前記ＵＤＰにより送信可能な所定容量を超える場合には、該応答データを分割して送信させる分割指示を前記処理要求に含める分割指示機能と、
    前記分割指示を含む前記処理要求を送信する要求機能と
    をコンピュータに実現させるプログラム。

Images