JP2006018376A

JP2006018376A - ネットワーク通信方式

Info

Publication number: JP2006018376A
Application number: JP2004192901A
Authority: JP
Inventors: Hidenori Yokokura; 秀則横倉
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2004-06-30
Filing date: 2004-06-30
Publication date: 2006-01-19

Abstract

【課題】メモリを多く搭載していないデバイスにおいても、動的にサイズが増減し、かつ大きなサイズになる可能性のあるＳＯＡＰ／ＸＭＬデータを効率的に送信することを可能とする。
【解決手段】最初にＳＯＡＰメッセージを送信するデバイスが、１回の接続で送信可能な最大データ容量を受信側のサーバ側へ提示する。受信側サーバは、送信側デバイスから提示されたデータ容量内で受信可能な最大値を返信する。デバイス側は受信側サーバが指定したデータ容量に基づいて分割されたＳＯＡＰメッセージを生成・送信する。分割メッセージは結合に必要な分割識別情報し、受信側サーバは、この分割識別情報を参照し、メッセージの結合処理を行う。
【選択図】図１

Description

本発明は、ネットワーク環境に接続されるＭＦＰ（ＭｕｌｔｉＦｕｎｃｔｉｏｎＰｅｒｉｐｈｅｒａｌ）などの印刷デバイス装置に関する。

近年、ネットワークを通じてＭＦＰ等のデバイス装置に印刷できるばかりでなく、デバイス装置の管理や連携を行うシステムソリューションの開発が展開されてきている。また、こうした中で、Ｗｅｂ技術であるＳＯＡＰ／ＸＭＬを利用して、インターネット経由まで拡充され、カウンタ情報収集やエラー情報収集をホストサーバに集約し、デバイスを管理するシステムが開発されている。こうしたインターネットを利用したシステム開発は、今後ますます普及することが予想される。また、一方で、Ｗｅｂ技術として、送信データを分割して送信することが可能であり、メモリバッファが少ないデバイス等でも対応できるしくみがチャンク機能として規定されている。
特開２００４−４０６３０号公報

しかしながら、ＳＯＡＰ／ＸＭＬで送信するデータは、より複雑な処理が求められつつあるがために、通信データサイズは拡大する方向にもかかわらず、通信を行う機器とサーバ間でその処理能力や記憶装置の容量は異なるため、単一のＳＯＡＰ／ＸＭＬスキーマで、送信する際のバッファが不足し、送信が困難になったり、ＳＯＡＰ／ＸＭＬの設計時に通信データを抑えるために情報量を抑えたりする必要があった。ただし、従来の技術であるＨＴＴＰプロトコルのチャンク機能を用いれば分割送信ができるので、送信バッファの抑制は可能であるが、ＳＯＡＰ／ＸＭＬの特性上、スキーマを動的に生成するため、送信バッファ以外に、アプリケーションレベルでのバッファ確保を行うが、それができなくなる可能性があった。また、ＳＯＡＰ／ＸＭＬであるために、パケットを分割するとしても、ＳＯＡＰエンベロープのタグで閉じられていないと、ＸＭＬパーサでエラーが発生してしまう問題点があった。

最初にＳＯＡＰメッセージを送信するデバイスがサーバ側へ１回の接続で送信可能な最大データ容量を提示する。受信側のサーバは、送信側デバイスから提示されたデータ容量内で受信可能な最大値をサーバ側で返信する（既に最適なデータ容量が得られている場合は省略）。サーバ側は受信側デバイスが指定したデータ容量に基づいて分割されたＳＯＡＰメッセージを生成・送信する。分割メッセージは結合に必要な分割識別情報（分割総数、結合順序、結合ＩＤなど）を格納した要素を有する。受信側サーバは、この分割識別情報を参照し、メッセージの結合処理を行う。

最初にＳＯＡＰメッセージを送信するデバイスがサーバ側へ１回の接続で送信可能な最大データ容量を提示する。受信側のサーバは、送信側デバイスから提示されたデータ容量内で受信可能な最大値をサーバ側で返信する（既に最適なデータ容量が得られている場合は省略）。サーバ側は受信側デバイスが指定したデータ容量に基づいて分割されたＳＯＡＰメッセージを生成・送信する。分割メッセージは結合に必要な分割識別情報（分割総数、結合順序、結合ＩＤなど）を格納した要素を有する。受信側サーバは、この分割識別情報を参照し、メッセージの結合処理を行う。以上のことから、メモリを多く搭載していないデバイスにおいても、動的にサイズが増減し、かつ大きなサイズになる可能性のあるＳＯＡＰ／ＸＭＬデータを効率的に送信することが可能となる。

以下、図面を参照にして本発明の実施の形態を説明する。

図１は、本発明の一実施形態に係わるネットワークシステムの全体構成を示す図である。１−１は、デバイス装置であり、インターネットを経由して、１−７のホストサーバ装置に、カウンタ情報やエラー情報等のデバイス情報を定期、または不定期に送信するものである。１−２は、ＰＣであり、１−４のイントラネットＬＡＮに接続されている。ネットワークを通じて、１−１のデバイス装置と通信することが可能であり、印刷ジョブを１−１のデバイス装置に送出することにより、ネットワーク印刷を行うことができる。１−３、１−６はゲートウェイ装置であり、１−５のインターネットへ接続するためのファイアーウォールの役目を果たす。１−８は、１−１のデバイス装置と同様であり、ネットワーク印刷や、ホストサーバへのデータ装置を行うことができる。１−９は、１−４と同様のイントラネットＬＡＮであり、ホストサーバ装置のあるＬＡＮである。

なお、ＰＣ、印刷デバイス装置は、同図に示す台数と異なる台数が接続されていもよい。

図２は、本発明の一実施形態に係わるネットワーク印刷デバイス装置の内部構成を示した図である。本内部構成では、１ＣＰＵにおいてネットワーク制御部とデバイス（プリンタ）制御部が動作する形態で実現されている。この印刷デバイス装置は、２−３に格納されているプログラムを実行するＣＰＵ２−１を備え、システムバス２−７に接続される各デバイスを総括的に制御する。また、２−２はＲＡＭで、ＣＰＵ１−１の主メモリ、ワークエリア等として機能する。このＲＡＭにカウンタ情報やシステム情報を保存する。そして、システム情報を保存するバックアップＲＡＭも構成される。２−４は、デバイスコントローラ（ＤＶＣ）で、２−６のプリンタ（ＤＶ）などを制御する。２−５はネットワークインタフェースカード（ＮＩＣ）で、ＬＡＮ２−７を介して、他のネットワーク機器あるいは他のＰＣと双方向にデータをやりとりする。

また、本実施例においては、ＬＡＮ３−１２は図１におけるＬＡＮ１−４、ＬＡＮ１−９、図２におけるＬＡＮ２−７と同じものである。

なお、カウンタ情報やシステム情報は、ハードディスク等のその他の記憶装置に保存してもよい。

図３は、本発明の一実施形態に係わるネットワークホストサーバ装置の内部構成を示した図である。本内部構成では、１ＣＰＵにおいてネットワーク制御部とデバイス（プリンタ）制御部が動作する形態で実現されている。この印刷デバイス装置は、３−３に格納されているプログラムを実行するＣＰＵ３−１を備え、システムバス３−１１に接続される各デバイスを総括的に制御する。また、３−２はＲＡＭで、ＣＰＵ３−１の主メモリ、ワークエリア等として機能する。このＲＡＭにデバイスごとの管理情報を保存する。そして、システム情報はバックアップＲＡＭにも構成される。３−４は、キーボードコントローラ（ＫＢＣ）で、３−８のキーボード（ＫＢ）からの指示入力を制御する。３−５は、ＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）３−９の表示を制御する。３−８のキーボードおよび３−９のＣＲＴディスプレイを用いてユーザは、各デバイスに対する指示を要求することができる。３−６は、ＩＯコントローラ（ＩＯＣ）で、３−１０のシリアルやパラレルなどを制御する。３−７はネットワークインタフェースカード（ＮＩＣ）で、ＬＡＮ３−１２を介して、他のネットワーク機器あるいは他のＰＣと双方向にデータをやりとりする。

なお、デバイスごとの管理情報や指示情報は、ハードディスク等のその他の記憶装置に保存してもよい。また、液晶パネルのタッチパネル等を用いて、仮想キーボードとし、キーボードの代わりとしても良い。

図４は、本実施例におけるＨＴＴＰ上のＳＯＡＰを用いてクライアントから印刷装置に送信されるｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅと称されるパケットデータの一例である。このデータはＸＭＬ形式で記述されている。ｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅパケットは、デバイスの分割再送を実施する際にホストサーバに通知するコマンドであり、クライアント情報（＜ｃｌｉｅｎｔ＞タグ）が記述されている。＜ｃｌｉｅｎｔ＞タグには、クライアントを識別する＜ｉｄ＞、クライアント送信サイズ＜ｓｉｚｅ＞が含まれる。ここでは、ｉｄを１００として、ホストサーバと通信している。また、最大送信パケットサイズとして、２０４８Ｋｂｙｔｅを指定している。これは、ＳＯＡＰエンベロープのサイズを示す。

なお、ｅｍ＿ｎｅｇｏｔｉａｔｉｏｎＳｉｚｅを意味するのパケットであれば、このタグの構成には限定されない。

図５は、図４のｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅパケットに対する応答パケットデータの一例である。本データも図４と同様にＸＭＬ形式で記述され、本実施例においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅ応答パケットには、ｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅコマンド対する結果情報＜として、サイズコード（＜ｓｉｚｅ＞タグ）がある。クライアントであるデバイスが、＜ｓｉｚｅ＞２０４８＜／ｓｉｚｅ＞と要求したのに対して、＜ｓｉｚｅ＞２０４８＜／ｓｉｚｅ＞と返答しているので、次のパケットから１パケット最大２０４８Ｋｂｙｔｅまで分割送信することができるようになる。また、ここで例えば、サーバ側の最大サイズが１０２４だったとすれば、＜ｓｉｚｅ＞１０２４＜／ｓｉｚｅ＞と指定すれば、パケット最大１０２４Ｋｂｙｔｅまで分割送信することができるようになる。

なお、ｅｍ＿ｎｅｇｏｔｉａｔｉｏｎＳｉｚｅの応答を意味するのパケットであれば、このタグの構成には限定されない。

図６は、本実施例におけるＨＴＴＰ上のＳＯＡＰを用いてデバイスからホストサーバに送信されるｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔと称されるパケットデータの一例である。このデータはＸＭＬ形式で記述されている。ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔパケットは、デバイスのカウンタ情報をホストサーバに定期的に通知するコマンドであり、クライアント情報（＜ｃｌｉｅｎｔ＞タグ）やアラート情報リスト（＜ｃｌｉｃｋＣｏｕｎｔＬｉｓｔ＞タグ）等の情報が記述されている。＜ｃｌｉｅｎｔ＞タグには、クライアントを識別する＜ｉｄ＞、クライアントのタイプを識別する＜ｔｙｐｅ＞、アプリケーションのバージョンを識別する＜ａｐｐＶｅｒｓｉｏｎ＞が含まれる。また、ｃｌｉｃｋＣｏｕｎｔＬｉｓｔには、デバイスを識別する＜ｄｅｖｉｃｅ＞、時刻を示す＜ｔｉｍｅＳｔａｍｐ＞、データの識別子＜ｄａｔａＩｄｅｎｔｉｔｙ＞、データ分割数＜ｄａｔａＤｉｖｉｓｉｏｎ＞、終了パケットを示す＜ｅｎｄＦｌａｇ＞とカウンター情報＜ｃｌｉｃｋＣｏｕｎｔｓ＞から構成される。また、＜ｄｅｖｉｃｅ＞には、ＭＡＣアドレスの下位４バイトを識別する＜ｍａｃ＞、ＩＰアドレスを識別する＜ｉｐ＞、シリアル番号＜ｓｅｒｉａｌＮｕｍｂｅｒ＞、製品名＜ｐｒｏｄｕｃｅＮａｍｅ＞、形式＜ｔｙｐｅ＞が記述される。

なお、ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔの要求を意味するのパケットであれば、このタグの構成には限定されない。

図７は、図６のｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔパケットに対する応答パケットデータの一例である。本データも図６と同様にＸＭＬ形式で記述され、本実施例においてはＨＴＴＰ上のＳＯＡＰを用いて送受信される。ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔ要求パケットには、結果情報（＜ｒｅｓｕｌｔ＞タグ）において、ＯＫまたはＮＧを返信する。

なお、ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔの応答を意味するのパケットであれば、このタグの構成には限定されない。

図８は、デバイス装置から分割送信する場合における一般的なホストサーバの動作を示すフローチャートである。

以下、図８を用いて、本実施例の印刷装置の動作を説明する。

ホストサーバへ例えば、図４に示したようなｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅパケットがホストサーバに送信されると、ホストサーバ装置において、ｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅに記述されたＸＭＬデータを解析し（Ｓ８−１）、Ｓ８−２では、そこで記述されているデバイス装置の最大バッファサイズを許容し、分割再送を行うかどうかを判別する。最大バッファサイズを許容し、分割再送を行うかどうかを判別した結果、許容するのであれば、Ｓ８−３へ進み、そうでなければ、Ｓ８−７へ進む。Ｓ７−３では、相手機であるデバイス装置の最大サイズを含んだ図５で示したようなｅｍ＿ｎｅｇｏｔｉａｔｅＳｚｉｅ応答パケットを生成し、デバイスに送信する。そして、デバイスから分割送信が必要な図６で示したようなｐｏｓｔＣｌｉｃｋＣｏｕｎｔ要求を受信する。そして、受信タイムアウトやパケットデコードエラーの受信エラーかどうかをＳ８−４において判別する。受信エラーかどうかの判別の結果、受信エラーであれば、エラー通知をデバイス装置に送信して、Ｓ８−６へ進み、そうでなければ、Ｓ８−８へ進む。Ｓ８−８では、自機であるホストサーバの許容できる最大パケットサイズを示したタグを含めたパケットを生成し、デバイス装置に送信する。Ｓ８−８では、図６で示すようなｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔの＜ｅｎｄＦｌａｇ＞タグが１であるかどうか判別する。＜ｅｎｄＦｌａｇ＞タグが１であれば、ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔを送信してＳ８−９へ、そうでなければ、ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔを送信してＳ８−４へ進む。Ｓ８−９では、データの結合を行って終了する。

なお、ここでは、デバイス装置とホストサーバとの通信例を示したが、送信側のリソース状態により、本分割送信をするが、デバイス装置間で本案を適用することができる。また、本例では、ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔを例としたが、パケットデータが比較的大くなりうるＳＯＡＰ関数であれば特に言及されるものではない。

図９は、分割送信する場合における一般的なデバイス装置の動作を示すフローチャートである。

以下、図９を用いて、本実施例の印刷装置の動作を説明する。

ホストサーバへ例えば、図６に示したようなｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔ等のデバイス情報を送信する時間がきたとする。Ｓ９−１でパケット送信を実行しようとし、Ｓ９−２で、送信しようとするパケットは、データ分割すべきかどうかを判別する。判別の結果、データ分割可能なＳＯＡＰ関数であれば、Ｓ９−３へ進み、そうでなければ、Ｓ９−１２へ進む。Ｓ９−３では、ｎｅｇｏｔｉａｔｅＳｉｚｅのＳＯＡＰ関数を図４に示したような＜ｓｉｚｅ＞タグに１パケットの最大送信データ量を記述して、ホストサーバへ送信する。Ｓ９−４では、ｎｅｇｏｔｉａｔｅＳｉｚｅ応答を受信する。その中のタグ＜ｓｉｚｅ＞にある数値を確認し、デバイスが指定したサイズと一致しているかどうかにより、送るべきデータ量が受諾されたかどうか判別（Ｓ９−５）する。サイズ受託がされたならば、Ｓ９−６へ進み、そうでなければ、Ｓ９−１３へ進む。Ｓ９−６では、自機デバイスのサイズを最大として、パケットを生成する。Ｓ９−７では、パケットを送信（ここでは、ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔ）する。Ｓ９−８では、そのパケットのレスポンスを受信する。Ｓ９−９では、次に送るべきデータが分割したデータを最後となるかどうかを判別する。最後であれば、Ｓ９−１０へ進み、そうでなければ、Ｓ９−５へ戻る。Ｓ９−１０では、ｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔにおいて、＜ｅｎｄＦｌａｇ＞１＜ｅｎｄＦｌａｇ＞として、サーバに送信する。Ｓ９−１１は、ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔの応答を受信する。Ｓ９−１２では、通常のパケット生成をして、Ｓ９−１３へ進む。Ｓ９−１３では、サーバである相手機が指定したサイズでパケットを生成する。Ｓ９−１３では、データ送信を終了する。

なお、ｅｍ＿ｎｅｇｏｔｉａｔｅＳｚｉｅでお互いの最大サイズを交換せずに、＜ｅｎｄＦｌａｇ＞を付加して送信するだけでも、デバイス装置のパケットを分割する目的は達成される。

本発明の一実施形態に係わるネットワークシステムの全体構成を示す図。本発明の一実施形態に係わるネットワーク印刷デバイス装置の内部構成を示した図。本発明の一実施形態に係わるネットワークホストサーバ装置の内部構成を示した図。本実施例におけるＨＴＴＰ上のＳＯＡＰを用いてクライアントから印刷装置に送信されるｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅと称されるパケットデータの一例。図４のｅｍ＿ｎｅｇｏｔｉａｔｅＳｉｚｅパケットに対する応答パケットデータの一例。本実施例におけるＨＴＴＰ上のＳＯＡＰを用いてデバイスからホストサーバに送信されるｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔと称されるパケットデータの一例。図６のｅｍ＿ｐｏｓｔＧｌｏｂａｌＣｌｉｃｋＣｏｕｎｔパケットに対する応答パケットデータの一例。デバイス装置から分割送信する場合における一般的なホストサーバの動作を示すフローチャート。分割送信する場合における一般的なデバイス装置の動作を示すフローチャート。

符号の説明

２−５、３−７ネットワーク
１―４、１−９、２−７、３−１２ネットワーク通信制御部

Claims

種々のネットワークデバイスと種々のコンピュータが接続されたネットワークシステムにおいて、
ＳＯＡＰ／ＸＭＬメッセージを送受信する手段と、
送信側デバイスが、送信側のＸＭＬに対する最大送信サイズに応じて、ＳＯＡＰ／ＸＭＬメッセージを分割・送信する手段と、
送信側デバイスが、送信するＳＯＡＰ／ＸＭＬメッセージに最終メッセージかどうかを識別する識別子をスキーマとして付加する手段と、
受信側サーバまたは、受信側デバイスが、分割されたＳＯＡＰ／ＸＭＬメッセージを受信する手段と、
受信側サーバまたは、受信側デバイスが、最終メッセージであることを示す識別子が付加されているＳＯＡＰ／ＸＭＬメッセージを受信した際に、一連のＳＯＡＰ／ＸＭＬデータを、１つのＸＭＬデータとして結合することを特徴とするネットワーク通信方式。
上記請求項１のネットワーク通信方式であって、
送信側デバイスが、ＳＯＡＰ／ＸＭＬメッセージを分割・送信する前に、
送信側の最大送信サイズを通知するためのＳＯＡＰ／ＸＭＬメッセージを送信する手段と、
受信側サーバまたは、受信側デバイスは、前記最大送信サイズを通知するためのＳＯＡＰ／ＸＭＬメッセージを受信する手段と、
受信側サーバまたは、受信側デバイスが、前記最大送信サイズを許容できる場合、許容できることを示すＳＯＡＰ／ＸＭＬメッセージで応答し、記最大送信サイズを許容できない場合、自装置が許容する最大受信サイズを、送信側デバイスに通知する手段と、
送信側・受信側のＳＯＡＰ／ＸＭＬメッセージ交換により、分割されたＳＯＡＰ／ＸＭＬメッセージの最大送信サイズを決定することを特徴とするネットワーク通信方式。