JP5417755B2 - 情報処理装置、情報処理方法及びプログラム - Google Patents
情報処理装置、情報処理方法及びプログラム Download PDFInfo
- Publication number
- JP5417755B2 JP5417755B2 JP2008182464A JP2008182464A JP5417755B2 JP 5417755 B2 JP5417755 B2 JP 5417755B2 JP 2008182464 A JP2008182464 A JP 2008182464A JP 2008182464 A JP2008182464 A JP 2008182464A JP 5417755 B2 JP5417755 B2 JP 5417755B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- data
- information processing
- dhcp
- response
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/00095—Systems or arrangements for the transmission of the picture signal
- H04N1/001—Systems or arrangements for the transmission of the picture signal specially adapted for transmission via digital wireline networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
- H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/00885—Power supply means, e.g. arrangements for the control of power supply to the apparatus or components thereof
- H04N1/00888—Control thereof
- H04N1/00896—Control thereof using a low-power mode, e.g. standby
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
- H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N2201/00—Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
- H04N2201/0008—Connection or combination of a still picture apparatus with another apparatus
- H04N2201/0034—Details of the connection, e.g. connector, interface
- H04N2201/0037—Topological details of the connection
- H04N2201/0039—Connection via a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N2201/00—Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
- H04N2201/0077—Types of the still picture apparatus
- H04N2201/0081—Image reader
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N2201/00—Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
- H04N2201/0077—Types of the still picture apparatus
- H04N2201/0082—Image hardcopy reproducer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N2201/00—Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
- H04N2201/0077—Types of the still picture apparatus
- H04N2201/0094—Multifunctional device, i.e. a device capable of all of reading, reproducing, copying, facsimile transception, file transception
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Facsimiles In General (AREA)
- Accessory Devices And Overall Control Thereof (AREA)
- Power Sources (AREA)
Description
例えば、ネットワークに接続された画像形成装置において、低消費電力モード時に、複数種類のパケットデータをそれぞれ予め設定した送信条件に従って、定期的にネットワークに自動送信する手段を備えることが提案されている(例えば、下記特許文献1、参照)。
また、受取ったステータス要求に応答する場合に、ネットワークインターフェースでハードウェア応答を可能とする機能を持つ回路(例えば、下記特許文献2、参照)や受信パケットに特定のデータがある場合にデータを送信する機能(例えば、下記特許文献3、参照)が提案されている。このような回路や機能は、省エネルギーモードを保ったままで、ネットワークに機器のステータス等の機器情報を知らせることを可能にする。
この問題を回避するための従来の方法は、低消費電力モードから通常モードに移行して主制御部に電源を供給し、トランザクションIDを変更できるようにして、正常なデータ送信を行えるようにしていたが、この方法は、主制御部のCPU及びメモリの消費電力が大きいので、消費電力の低減効果を減殺してしまう。
この発明は、上記従来技術の問題に鑑みてなされたものであり、主制御部への電源供給を停止する低消費電力モード時に、トランザクションIDの変更が必要なプロトコルによる定期送信を行えるようにすることを解決すべき課題とする。
さらに、低消費電力モード時に、ネットワークからの要求に応答する際に、低消費電力を維持したままで、多様なネットワークからの要求に応えることができるようにすることを解決すべき課題とする。
本発明は、主制御部が有するCPUへの電源供給を少なくとも停止する第1低消費電力モードの電源供給制御時に、所定フレーム構造の送信パケットを生成し、生成したパケットをネットワークに送信し、かつネットワークから所定フレーム構造を持つパケットを受信でき、印刷要求を処理する機能を持つ情報処理装置における情報処理方法であって、前記第1低消費電力モードから電源供給を一部復帰させる第2低消費電力モードにおいて、前記主制御部のCPUを動作させて非印刷要求に応じる制御動作を行う工程と、送信データのパケットを生成するパケット生成工程と、第1低消費電力モードの電源供給制御時に前記パケット生成工程によって生成されたDHCP REQUESTパケットを予め設定された送信時間間隔で定期的にネットワークに送信する送信制御工程を有したことを特徴とする。
また、低消費電力を維持したままで多様なネットワークからの要求に応えるメッセージを簡単な手順により、高速に送ることができる。
図1は、この実施形態に係るプリンタの制御を司るコントローラボード1と記録媒体へ印字するプロッタ2からなる機能構成を示すブロック図である。
コントローラボード1は、ASIC(Application Specific Integrated Circuit:特定用途向け集積回路)10、DDR−SDRAM(Double Data Rate -Synchronous Dynamic Random Access Memory)を含むメモリ11、ネットワークとの間で各種のパケットデータ(以下、単に「パケット」ともいう)の送受信をするネットワーク用の物理層部(physical layer、以下「PHY」という)12、PHYクロック生成部13、ASICクロック生成部14、記録媒体としてのMemory Card(登録商標)15、操作部(Operation Panel、以下「OP」という)16、ハードディスク装置(HDD)17、ボード電力制御部18、外部電力制御部19、不揮発性メモリ(RAM;Random Access Memory)36、プログラムとデータが格納されている第1のROM(Read Only Memory)(1)37、MAC(Media Access Control)アドレスが格納されている第2のROM(2)38を搭載している。
なお、上記記録媒体としてのMemory Card15は、これ以外に、例えば、セキュアデジタルカード(Secure Digital Card:SDカード、登録商標)を含む各種のメディアが使用可能である。また、上記MACアドレスとは、ユニークなハードウェアアドレスである。
電源ON時に、ROM(1)37上の第1のプログラムをCPU(Central Processing Unit)20が実行して、第2のプログラムをメモリ11上にロードする。
メモリ11上にロードした第2のプログラムは、第1のプログラムを実行後に実行される。
第2のプログラムに下記の省エネルギーモードにおけるネットワークとのパケット通信処理を実行するプログラムを記録(記憶)しておくことで、CPU20が、この記録媒体に記録した制御・処理プログラムや制御データ等をメモリ11に読込み、処理の実行時に当該プログラムを駆動することによって、CPU20(コンピュータ)を当該処理の実行手段として機能させることができる。
本実施形態では、DHCP(Dynamic Host Configuration Protocol)プロトコルによってネットワーク上の送信元或いは送信先のIPアドレス等の設定を行う。このIPアドレスの設定動作の概要について、次に説明する。
図17は、DHCPプロトコル・シーケンスの概要である。また、図18は、DHCPプロトコルに用いるUDPパケット(後述する“UDPパケット”の説明、参照)のフォーマットであり、図19は、UDPパケットに埋め込むUDPデータの構成を示す。なお、DHCPプロトコルについては、RFC(Request For Comments)1541に詳細が記載されている。
CPU20は、プリンタを稼動状態にするために行う初期設定を実行した(ステップS101)後、DHCP Discoverコマンドをブロードキャストパケットで送信する(シーケンスSq I)(ステップS102)。
送信されたDHCP Discoverコマンドを受信するDHCPサーバ(Server)が、コマンドに応えてDHCP OfferによってIPアドレスを提示する(シーケンスSq II)(ステップS103)。このとき、複数のDHCPサーバからIPアドレスを提示される可能性があるので、DHCPクライアント側は、どのDHCPサーバからのIPアドレスを受け付けるかを予め決めておく必要がある。例えば、設定対象とするDHCPサーバのIPアドレスを予め決めておけば、特定のDHCPサーバからのDHCP Offerを受け付けることができる。
この後、DHCPクライアントは、DHCP REQUESTに応えてDHCPサーバから送信されてくるDHCP ACKを受信する(シーケンスSq IV)(ステップS106)。この受信動作において、DHCP REQUESTを送信してから所定の時間が経過してもDHCP ACKが受信できない場合には、延長要求としてDHCP REQUESTを繰り返して送信する。このときには、図21に示すDHCP REQUEST(延長要求時)を発行する。なお、延長要求時には、図17のシーケンスに示した、DHCP Discover→DHCP Offerは、省略可能である。
OPは、オペレーションコードである。データサイズは1バイトで、1の時はBOOT REQUESTであり、2の時は BOOT REPLYを示す。
htypeは、ハードウェア番号である。データサイズは1バイトで、1はイーサネット(登録商標)を示す。
hlenは、ハードウェアアドレス長である。データサイズは1バイトで、イーサネット(登録商標)では6である。
hopsは、転送回数である。データサイズは1バイトで、DHCPクライアントは使用しない。
xidは、トランザクションIDである。データサイズは4バイトである。
secsは、経過時間である。データサイズは2バイトである。
flagsは、ブロードキャストフラグである。データサイズは2バイトである。0x8000はブロードキャストであることを示し、0の時はユニキャストである。
yiaddrは、要求者IPアドレスである。データサイズは4バイトである。
siaddrは、次回の初期化で使用すべきサーバのIPアドレスである。データサイズは4バイトである。 DHCP Offer、DHCP ACK、DHCP NAKでサーバが返答する。
giaddrは、リレイエージェントIPアドレスである。データサイズは4バイトである。リレイエージェントを 使用する時に使用される。
chaddrは、クライアントハードウェアアドレスである。データサイズは16バイトである。
snameは、サーバのホスト名である。データサイズは64バイトである。オプションで、ヌル文字で終わる文字列で示す。
fileは、ブートファイル名である。データサイズは128バイトである。ヌル文字で終わる文字列で示す。
optionsは、オプションである。データサイズは312バイトである。オプションについては、RFC1533に詳細が記載されている。
即ち、CPU20は、ROM(2)38に格納してあるMACアドレスをPE24(図15を参照して詳細は後述)のレジスタ部242にある要求元ハードウェアアドレス(SHA)に格納する。また、選択したDHCPサーバから受信したDHCP ACKプロトコル上のClientIPアドレスがプリンタ(本機)のIPアドレス(図19のDHCPプロトコルのデータ構成におけるciadder)となる。このIPアドレスをCPU20は、PE24のレジスタ部242にある要求元IPアドレス(SIP)に格納しておく。
このようにして、CPU20がDHCPサーバとプリンタ(本機)のIPアドレス、ハードウェアアドレスを求めることができる。
また、DHCP ACKプロトコルにはIPアドレスのリース時間が設定されているので、この時間の半分の値をPE24の定期送信間隔時間設定部249にTimer1として保存しておく(後記PE24の説明で詳述)。
ASIC10は、さらに、コントローラボード1の内外の各部への電源(図示を省略)からの給電を制御するパワーマネジメント部(以下「PM」という)32、タイマ(Timer)33を搭載している。
ASIC10の内部には、CPU20、メモリ11及びパワーオフ領域(Power OFF Area)35という、PM32によって電源から電力の供給、停止を制御できる回路要素や領域がある。なお、上記以外のコントローラボード1上の回路要素には常に電力が供給される。
パワーオフ領域35は、PCI I/F27、Memory Card I/F28、OPE I/F29、HDD I/F30、I/O I/F31からなり、ネットワーク動作に直接関係しない回路部の領域である。
この実施形態では、基本的には、各電源供給モード間の移行動作の遷移を示す図2(A)に示すように、プリンタ全体が動作可能な状態となるように電源を供給する通常動作モードと、低消費電力モード(以下「省エネモード」という)として、ボード電力制御部18と外部電力制御部19をそれぞれ制御して、CPU20、メモリ11及びパワーオフ領域(Power OFF Area)35への電力供給を停止し、同時に、コントローラボード1とPCIバス3を介して接続されるプロッタ2等へも電力供給を停止する動作を行う。
通常動作モードの場合、PM32は、CPU20とメモリ11に電源からの電力を供給する。さらに、パワーオフ領域35の各部(PCI I/F27、Memory Card I/F28、OPE I/F29、HDD I/F30、I/O I/F31)への電力の供給を開始し、ボード電力制御部18、外部電力制御部19によってコントローラボード1内外の各部へも電力を供給する。この状態で、ASIC10はこのプリンタ全体の制御を開始し、通常の動作が可能になる。
プリンタ(自局)宛のパケットの受信が無いことは、PF23のバッファ(後述する図13のバッファ235)からのエンプティフラグで認識できる。
上記メモリ11の消費電力の制御は、省エネモードに移行すると、PM32がMEMI/F21を介してメモリ11をセルフリフレッシュモードに移行させ、メモリ11は省エネルギーモードに移行前の状態の情報を保存し、省エネモードに移行する。
また、通常動作モード又はコントローラモードに移行する場合、PM32がMEMI/F21を介してメモリ11を通常動作モードに移行させ、メモリ11に対して内部バス34を介してアクセスが可能になる。
省エネルギーモードから通常動作モードに復帰する場合、メモリ11は、省エネルギーモードに移行する前の状態の情報に復帰させる。
この実施形態では、省エネルギーモードに移行したときでも、常時給電が行われるPE24で自発的に所定のパケットデータを生成する処理を行い、PHY12を介してネットワークにパケットを送信する。具体的には、省エネルギーモードに移行したときから、電力の供給が停止されているCPU20を動作させることなく、PE24でDHCP REQUESTパケットを生成し、送信する処理を行う。また、DHCPプロトコルに従い、DHCP REQUESTの送信先からの応答パケットをPF23によって受取ることを可能にする。
さらに、この実施形態では、低消費電力モード時に受信したパケットが自局宛ではない場合、パケットフィルタ部PF23でそれらのパケットを破棄するが、自局宛のパケットの場合には、PE24で所定のパケットのリクエストに応えるために予め設定しておいたデータを送信元が受取ることができる所定フレーム構造のパケットとして生成し、応答することを可能にする。
よって、図2(B)における第1低消費電力モードである省エネモードからの遷移では、印刷を要求するパケットに対しては、通常動作モードに復帰させる(図2(B)中の(1)の遷移)が、非印刷要求のパケットに対しては、第2低消費電力モードであるコントローラモードへ移行する(図2(B)中の(3)の遷移)動作となる。
なお、コントローラモードにおいても、省エネモードへの移行(図2(B)中の(4)の遷移)及び通常モードへの移行(図2(B)中の(5)の遷移)は、図2(A)の基本動作と同様の条件で行われる。
ここで、このプリンタがネットワークと交信することができる所定フレーム構造のパケットの例として、イーサネット(登録商標)フレームとパケットの種類について説明する。
“イーサネット(登録商標)フレーム”
図3は、イーサネット(登録商標)フレームの構造及びフォーマットを説明する図で、(A)にはフレーム構造を示し、(B)にはフレーム内の各フィールドのデータ内容の一例を示す表である。
図3(A)に示すように、イーサネット(登録商標)フレームは、プリアンブル、宛先MACアドレス、送信元MACアドレス、タイプ、データ、及びFCS(Frame Check Sequence)からなる。
プリアンブルは、図3(B)に示すように、データ長が64ビット(8バイト)であるフレームの開始を示す情報であり、「10」を交互に入力して最後の2ビットが「11」になる入力値「1010...11」が入力される。
宛先MACアドレスと送信元MACアドレスは、それぞれパケットの宛先の装置(例えば、LAN接続されたプリンタ等の機器)のアドレスとパケットの送り主の装置のアドレスであり、ともにデータ長は48ビット(6バイト)である。上記MAC(Media Access Control)は、IEEE802−1990で規定されている。
タイプは、「0x0800」の時はIPv4(Internet Protocol Version 4)プロトコルを、「0x0806」の時はARP(Address Resolution Protocol)プロトコルを、「0x86DD」の時はIPv6プロトコルを、「0x809B」の時はAppleTalkのプロトコルを、「0x8037」の時はIPX(NetWare)のプロトコルを、「0x8191」の時はNetBIOS/NetBEUI(NetBIOS Extended User Interface)のプロトコル(上記各プロトコルは登録商標である)をそれぞれ指定する。
データは、46〜1500バイト長まで指定可能である。
FCSは、チェックサムでCRC(Cyclic Redundancy Check)−32の多項式で生成されたものである。
図4(A)はイーサネット(登録商標)パケットフォーマットである。図4(B)は、イーサネット(登録商標)フレーム(図3)におけるIPパケットのフォーマットを示す図である。
図4(B)に示すIPパケットのフレームは、イーサネット(登録商標)フレーム(図3)におけるイーサネット(登録商標)ヘッダのタイプに、同図(B)に破線で示すように、「0x0800」を入れる。
IPパケットを構成する場合、図4(B)に示すように、上記イーサネット(登録商標)フレームのデータに、IPヘッダとデータを含める。
図5に示すように、ヘッダ部(IPヘッダ)とデータ部とからなるIPパケットのヘッダ部は、バージョン(Version)フィールド、ヘッダ長(IHL)フィールド、サービスタイプ(Type Of Service)フィールド、パケット長(Total Length)フィールド、識別子(Identification)フィールド、フラグ(Flags)フィールド、フラグメントオフセット(Flagment Offset)フィールド、生存時間(Time To Live)フィールド、プロトコル番号(Protocol)フィールド、ヘッダチェックサム(Header Checksum)フィールド、送信元IPアドレス(Source Address)フィールド、宛先IPアドレス(Destination Address)フィールドからなる。
さらに、オプションが付く場合があり、オプション(Options)とパディング(Padding)を含めたフィールドのデータ長が32ビットの倍数になるようにパディングする。ただ、オプションは、通常使用されない。
ヘッダ長フィールドは、データ長が4ビットであり、IPv4プロトコルの場合は20バイトである。
生存時間フィールドは、ネットワーク上でのパケットの生存時間の値が格納され、ルータを通過するたびにその値が1つずつ減らされ、「0」になったらパケットは破棄される。その詳細はRFC(Request For Comments)2200に記載されているので、説明を省略する。
サービスタイプはRFC791、プロトコル番号の詳細については、RFC1700に記載されているので、説明を省略する。
識別子フィールドに格納される値は、フラグメントを復元する際の識別子として使用される。
フラグフィールドは、パケットの分割に関する制御を示す値が格納される。
図4(B)、(C)は、イーサネット(登録商標)フレーム(図3)におけるIPパケットとUDP(User Datagram Protocol)パケットのフォーマットを示す図である。また、図6は、UDPパケット内の各フィールドのデータ内容を示す説明図である。
図4(A)に示すUDP(User Datagram Protocol)パケットのフレームは、イーサネット(登録商標)フレーム(図3)におけるイーサネット(登録商標)ヘッダのタイプに、同図(B)に波線で示すように、「0x0800」を入れる。
IPパケットを構成する場合、図4(B)に示すように、上記イーサネット(登録商標)フレームのデータに、IPヘッダとデータを含める。
UDPパケットを構成する場合、IPヘッダ内にはプロトコルのデータとして、UDPを指定するデータを格納し、IPパケットのデータに、UDPヘッダとデータを含める。
UDPパケットは、送信元ポート番号(16ビット)フィールド、宛先ポート番号(16ビット)フィールド、セグメント長(16ビット)フィールド、チェックサム(16ビット)フィールド及びデータからなる。
上記送信元ポート番号フィールドと宛先ポート番号フィールドに格納される送信元ポート番号と宛先ポート番号のポート番号は、アプリケーションの識別に使用される。また、ウェルノウンポート番号として標準で決められている番号(RFC1700で公開済)がある。UDPの詳細は、RFC768に記載されているので、説明を省略する。
図7(A)はイーサネット(登録商標)パケットフォーマットである。図7(B)、(C)は、イーサネット(登録商標)フレーム(図3)におけるIPパケットとTCP(Transmission Control Protocol)パケットのフォーマットを示す図である。また、図8は、TCPパケット内の各フィールドのデータ内容を示す説明図である。
図7(A)に示すTCPパケットのフレームは、イーサネット(登録商標)フレーム(図3)におけるイーサネット(登録商標)ヘッダのタイプに、同図(B)に波線で示すように、「0x0800」を入れる。
IPパケットを構成する場合、図6(B)に示すように、上記イーサネット(登録商標)フレームのデータに、IPヘッダとデータを含める。
TCPパケットを構成する場合、図7(C)に示すように、上記IPパケットのデータに、TCPヘッダとデータを含める。TCPヘッダ内にはコードビットとして、0ビット目に「FIN」、1ビット目に「SYN」、2ビット目に「RST」、3ビット目に「PSH」、4ビット目に「ACK」、5ビット目に「URG」を格納する。また、同図(C)に波線で示すように、IPヘッダのプロトコルには、TCPプロトコルを示すデータの「6」を入れる。
さらに、オプションとパディングがある場合があり、その後にデータがある。
上記送信元ポート番号フィールドと宛先ポート番号フィールドに格納される送信元ポート番号と宛先ポート番号のポート番号は、アプリケーションの識別に使用される。また、ウェルノウンポート番号として標準で決められている番号(RFC1700で公開済)がある。TCPの詳細はRFC793に記載されているので、説明を省略する。
図9(A)はイーサネット(登録商標)パケットフォーマットである。図9(B)、(C)は、イーサネット(登録商標)フレーム(図3)におけるIPパケットとICMP(Internet Control Message Protocol)パケットのフォーマットを示す図である。また、図10は、ICMPエコーリクエストとICMPエコーリプライのパケットの各フィールドのデータ内容を示す説明図である。
ICMPパケットのフレームは、図9(A)、(B)に示すように、イーサネット(登録商標)フレーム(図3)におけるイーサネット(登録商標)ヘッダのタイプに「0x0800」を入れ、イーサネット(登録商標)フレームのデータに、IPヘッダとデータを含める。この点は、基本的に上記TCPパケットやUDPパケットと同じである。
ただ、ICMPパケットを構成する場合、IPヘッダ内にはプロトコルのデータとして、図9(C)に示すように、ICMPを指定するデータ「1」を格納し、IPパケットのデータに、ICMPヘッダとデータを含める。また、ICMPヘッダのタイプには、ICMPエコーリクエスト(エコー要求)パケットの場合は「8」であり、ICMPエコーリプライ(エコー応答)パケットの場合は「0」を入れる。また、ICMPヘッダ内には、ICMPエコーリクエストパケットとICMPエコーリプライパケットにおけるコードビットとして、常に「0」が格納される。さらに、データは任意の長さであるが、通常は64バイトのデータ長である。
ICMPエコーリクエストとICMPエコーリプライのパケットは、メッセージタイプフィールド、コードフィールド、チェックサムフィールド、識別子フィールド、シーケンス番号フィールドとデータからなる。
ICMPエコーパケットは、公知技術なのでその詳細な説明は省略するが、メッセージタイプフィールドには、上述したICMPエコーリクエストパケットの場合は「8」を、ICMPエコーリプライパケットの場合は「0」を格納する領域である。コードフィールドには、上述したように、ICMPエコーリクエストパケットとICMPエコーリプライパケットの場合は常に「0」を格納する領域である。
図11は、イーサネット(登録商標)フレーム(図3)におけるARPパケットのフォーマットを示す図である。
図11(B)に示すARPパケットのフレームは、イーサネット(登録商標)フレーム(図3)におけるイーサネット(登録商標)ヘッダのタイプに、同図(B)に波線で示すように、「0x0806」を入れる。
ARPパケットを構成する場合、図11(B)に示すように、上記イーサネット(登録商標)フレームのデータに、オペレーションコードフィールドとARPパケットを含め、オペレーションコードフィールドに「1」が格納されている場合はARPリクエストパケットを指定し、「2」が格納されている場合はARPレスポンスパケットを指定する。
図12(A)に示すように、ARPパケットは、ハードウェアタイプフィールド、プロトコルタイプフィールド、MACアドレス長(HLEN)フィールド、プロトコルアドレス長(PLEN)フィールド、オペレーションコードフィールド、送信元MACアドレスフィールド、送信元IPアドレスフィールド、宛先MACアドレスフィールド、宛先IPアドレスフィールドからなる。
プロトコルタイプフィールドは、16ビットのデータ長であり、IPアドレスを使用し、IPv4プロトコルを示す場合は「2048」が格納される。
MACアドレス長フィールドは、48ビットのデータ長であり、MACアドレスを示す6バイトのデータが格納される。IPv4プロトコルを示す場合、「6」が格納される。
プロトコルアドレス長フィールドは、32ビットのデータ長であり、IPv4プロトコルを示す場合、「4」が格納される。
送信元MACアドレスフィールド、送信元IPアドレスフィールド、宛先MACアドレスフィールド、宛先IPアドレスフィールドは、それぞれ48,32,48,32の各データ長であり、それぞれ送信元MACアドレス、送信元IPアドレス、宛先MACアドレス、宛先IPアドレスが格納される。
次に、省エネルギーモードにおいて動作が可能なネットワークパケットエンジン処理部(PE)24について説明する。
ここで実施形態1として例示するPE24は、省エネルギーモードでも、自発的に所定のパケットデータを生成し、ネットワークにパケットを送信する処理を行うもので、具体的には、省エネルギーモードに移行したときから(即ち、電力の供給が停止されているCPU20を動作させずに)、DHCP REQUESTパケットを生成し、このパケットを予め設定した送信時間間隔で定期的に送信する処理を行えるようにする。また、送信したDHCP REQUESTパケットに対して所定時間内に何の応答もない場合には、省エネルギーモードを維持したまま当該パケットの再送を行えるようにする。
PE24は、ネットワーク送信制御部241、レジスタ部242、Ether(イーサネット(登録商標))フレームヘッダ生成部243、IPパケット生成部247、定期送信間隔時間設定部249からなる。
ネットワーク送信制御部241は、定期送信間隔時間設定部249のTimer(1)249tに設定した時間間隔でIPパケットとしてのDHCP REQUESTが生成できるように定期送信時間間隔を制御する。
再送制御部2411は、このために備わり、前記所定時間をTimer(2)2411tに設定し、ここに設定された時間を越えて、何の応答もない場合に再送処理を行う。再送制御部2411は、繰返し回数241nを限度に再送処理を行う。なお、ネットワーク送信制御部241の動作の詳細は、後述する図22及び図23に示す制御フローを参照して説明する。
識別データ生成部2473は、DHCP REQUESTパケットで使用するTransctionIDを生成するトランザクション(Transaction)ID生成部2473t、UDPパケットのポート番号を生成するポート番号生成部2473n、IPパケットの識別子を生成する識別子生成部2473iからなる。なお、ポート番号生成部2473nは、送信先ポート番号として67、宛先ポート番号として68をそれぞれ生成する。
UDPヘッダ生成部2472では、図6の送信元ポート番号、宛先ポート番号、セグメント長及びチェックサムよりなるUDPヘッダを生成する。宛先ポート番号及び送信元ポート番号は、識別データ生成部2473で生成したデータを埋め込む。セグメント長は、UDPデータの長さを設定する。なお、UDPデータは、DHCP REQUESTパケットなので、DHCP REQUESTパケットの長さを設定すればよい。CheckSUM(チェックサム)は、ヘッダ、UDPデータの1の補数を16ビットで示す。チェックサムの計算は、IPのチェックサム計算と同様であり、この計算は、例えば、オーム社発行の書籍「マスタリングTCP/IP 応用編」で記載されている1の補数演算方法を使用することにより実施し得る。
IPパケットのヘッダの生成に用いるデータとして、予め、プリンタの自局IPアドレスをレジスタ部242のSIPに、プリンタの自局のハードウェアアドレスをレジスタ部242のSHAに設定しておく。また、レジスタ部242には、DHCPサーバのIPアドレスをDIPに、ハードウェアアドレスをDHAに設定しておく。なお、レジスタ部242におけるこれらの設定については、IPアドレス設定の処理フローを示す図20、特にステップS107の説明を参照されたい。
また、識別子は、識別データ生成部2473の識別子生成部2473iで生成した識別子を設定する。この識別子は、IPパケットを送信する度に新たに生成する。
また、フラグには、分割不可、後続フラグメント無しを設定して、フラグメントオフセットは0に設定する。生存時間は最大値の255を設定する。プロトコルにはUDPを示す値である17を設定する。ヘッダチェックサムは、IPヘッダとデータのチェックサムを計算する。送信元IPアドレスと宛先IPアドレスは、レジスタ部242に設定してあるSIP、DIPをそれぞれ設定する。また、ヘッダのオプションは生成しない。
イーサネット(登録商標)フレームヘッダ生成部243は、レジスタ部242に設定してあるDHAからあて先MACアドレス、SHAから送信元MACアドレス、TYPEからタイプを取出してイーサフレームの所定のフィールドに設定してイーサネット(登録商標)フレームのヘッダを生成する。
イーサネット(登録商標)パケットのFCSは、MAC22で自動生成されるので、パケット生成部では生成する必要はない。
以上のようにして、省エネルギーモード時にPE24で生成されたIPパケット(DHCP REQUEST)を含む各種のイーサネット(登録商標)パケットは、セレクタ25、MAC22及びPHY12を経由してネットワークに送信される。
上記で実施形態1として例示したPE24は、省エネルギーモードにおいて、自発的にDHCP REQUESTパケットを生成し、生成したパケットを予め設定した送信時間間隔で定期的に送信する処理を行うので、送信したDHCP REQUESTパケットへの応答として送られてくるパケットをパケットフィルタ部(PF)23で受取らなければならない。
このため、PF23は、DHCPプロトコルに従って発行したDHCP REQUESTの送信先からの応答として受取るDHCP ACK又はDHCP NAKパケットを検出する機能を用意する。
なお、PF23によるDHCP ACK又はDHCP NAKパケットの検出結果に従って、省エネルギーモードを維持してPE24によるDHCP REQUESTパケットの定期送信を継続するか、或いは省エネルギーモードから通常モードへ移行させ、主制御部のCPU20によって行うDHCPサーバのIPアドレス等の設定処理(図20のフロー、参照)を行う。この省エネルギーモード時のPE24及びPF23の動作については、フロー図(図22,23)を参照して後記で詳述する。
PF23は、アドレスフィルタ231、パターンフィルタ233、バッファ235を構成要素とする。
アドレスフィルタ231には、ユニキャストアドレスとマルチキャストアドレスが登録可能である。また、このプリンタ自身やプリンタ内のアクセス可能なデバイス(例えば、プロッタ2など)のアドレスが設定可能である。
アドレスフィルタ231は、MAC22から入力したパケットのタイプを参照し、そのタイプからパケットの種類を判断し、設定されたアドレスをチェックすることで、アクセス可能な機器やデバイスに対するパケットのみを通過させ、パターンフィルタ233へ送り、その他のパケットは破棄する選別を行う。
また、ブロードキャストパケットは、アドレスフィルタ231の設定に関係無く、通過させてパターンフィルタ233へ送る。
自局宛アドレスのパケットとは、アドレスフィルタ231を通過させるパケットである。従って、自局宛アドレスには、登録したユニキャストアドレス(このプリンタ自身やプリンタ内のデバイスのIPアドレス)登録したマルチキャストアドレス及びブロードキャストアドレスが含まれる。
マスク領域は、パケットの値に関係なく一致条件となり、この領域もバイト単位で設定できる。マスク領域のデータ長と非マスク領域のデータ長の合計がパターンフィルタ長になる。例えば、パターンフィルタ長は、256バイトをとる。
パターンフィルタ233には、パターンオフセットとしてオフセット値が設定でき、その1つは、パターンオフセット1であり、イーサネット(登録商標)フレームの開始からのオフセット長になる。パターンフィルタ233によるフィルタリングをイーサネット(登録商標)フレームのタイプから開始する場合は、宛先MACアドレス長と送信元MACアドレスを加算した値が、パターンオフセット1の長さになる。
もう1つのパターンオフセットであるパターンオフセット2は、パターンフィルタ233の先頭からのオフセットを示す。パターンオフセットからの1バイトはビットマスク値によって、ビットごとにフィルタリングが可能である。ビットマスク値で「1」を設定したビットはマスク領域である。
図15に示すパターンフィルタ233は、DHCP ACK用PF233a、DHCP NAK用PF233n、自局宛PF233s、の各パターンフィルタを備える。パターンフィルタ233には、アドレスフィルタ231を通過したパケットが入力され、処理結果として、DHCP(ACK)要求、非DHCP(DHCK NAK)要求又は時局宛要求を出力する。なお、パターンフィルタ233には自局宛のパケットしかこないので、DHCP ACK、またはDHCP NAK以外のパケットを自局宛パケットとして検出できる。即ち、DHCP ACK用PF233aで検出されるDHCP(ACK)要求ではなく、またDHCP NAK用PF233で検出される非DHCP(DHCK NAK)要求ではない場合(或いは上記と処理順序を逆にした場合でもよい)に自局宛要求のパケットであるとみなし、自局宛要求を出力する処理方法により実施することができる。
図16は、パターンフィルタ233におけるDHCP ACKパケットのフィルタリング処理を説明する図である。図16(a)は、UDPパケットのネットワークフレームのフォーマット(図4及び図18、参照)を示し、同図(b)には、PF23のパターンフィルタ233に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。なお、DHCP ACKパケットは、DHCPプロトコルにおけるUDPデータの構成を基本とするので、図19をもとに説明した先の記載を参照する。
DHCP ACKパケットの長さが、256バイト以上あるので、この実施形態のパターンフィルタ233におけるDHCP ACK用PF233aでは、第1及び第2の2つのパターンフィルタを使用する。
イーサネット(登録商標)ヘッダのタイプの次は、IPヘッダとの比較値を設定する。IPヘッダのバージョン(Ver)にはIPv4の4を、ヘッダ長には「5」を、プロトコル番号にはUDPプロトコル番号を、宛先IPアドレスにはこのプリンタのIPアドレス(自局アドレス)をそれぞれ設定し、その他のIPヘッダはマスク領域(図中に斜線を施した部分)として設定する。
さらに、UDPデータ領域については、DHCP ACKに対応するので、DHCP ACKパケットのOP、htype、Hlen、hops、xid、flags、yiaddr、chaddrまでを非マスク領域として使用する。OPに0x02、htypeに0x01、hlenに0x06、hopsに0x00、xidにはPE24のTransactionID生成部2473tで生成するTransactionID、yiaddrにはClient IP Addressなのでレジスタ部242のSIP、chaddrにはClient MAC Addressなのでレジスタ部242のSHAを設定する。DHCP ACKプロトコルのsecs,ciaddr,giaddrの各領域は、マスク領域に設定する。
非マスク領域として、MagicCode(0x63825363)、DHCP ACK(0x350105)を設定する。残りの部分はマスク領域とする。
このようにして、第1及び第2のパターンフィルタにそれぞれ分けたパケットデータ領域のパターンフィルタ条件の設定を行う。第1、第2のパターンフィルタ両方の処理で設定したパターンフィルタ条件と受信したパケットデータが一致した場合にのみ、DHCK ACKプロトコルであることが検出されるようにする。よって、第1及び第2のパターンフィルタそれぞれの処理結果のANDをとることにより、DHCP ACKであることを検出し、DHCP ACK要求を発生することができる。
DHCP NAKパケットの場合、パケットの長さが256バイト以上あるので、DHCP NAK用PF233nでも、第1及び第2の2つのパターンフィルタを使用する。
第1のパターンフィルタは、上記したDHCP ACK用PF233aのパターンフィルタと同じパターンフィルタ条件の設定でよい。
また、DHCP NAK用PF233nの第2のパターンフィルタでは、パターンオフセット1として、イーサネット(登録商標)ヘッダ長(宛先MACアドレス長、送信元MACアドレス、タイプの長さ)、IPヘッダ長、UDPヘッダ長とUDPデータ領域におけるDHCP ACKパケットの先頭(OP)からfile迄の長さを加算した値である236を設定する。
非マスク領域として、MagicCode(0x63825363)、DHCP NAK(0x350106)を設定する。残りの部分はマスク領域とする。
このようにして、第1及び第2のパターンフィルタにそれぞれ分けたパケットデータ領域のパターンフィルタ条件の設定を行う。第1、第2のパターンフィルタ両方の処理で設定したパターンフィルタ条件と受信したパケットデータが一致した場合にのみ、DHCP NAKプロトコルであることが検出されるようにする。よって、第1及び第2のパターンフィルタそれぞれの処理結果のANDをとることにより、DHCP NAKであることを検出し、DHCP NAK要求を発生することができる。
ここで、省エネルギーモードにおける上記したネットワークパケットエンジン処理部(PE)24とパケットフィルタ部(PF)23の動作を図22に示す制御フローに基づいて説明する。
図22に示す制御フローは、省エネルギーモードの間、PE24によって自発的にDHCP REQUESTの定期送信を行い、送信したDHCP REQUESTに対する応答として送信先から送られてくるDHCP ACK又はDHCP NAKをPF23によって検出し、検出結果に応じて該送信先との通信条件を保つための処理及び動作を行う。ただ、省エネルギーモードでは、CPU20は動作しないので、省エネルギーモードへの移行に先立ち、CPU20は、PE24及びPF23の動作に必要な設定を行った後、省エネルギーモードへ移行させる。
また、省エネルギーモード時に送信したDHCP REQUESTに対するDHCP ACK応答がある場合に、省エネルギーモードを維持したまま、DHCPプロトコルの通信条件を保持する動作を行う。
さらに、省エネルギーモード時に送信したDHCP REQUESTに対するDHCP NAK応答或いは時間内に何の応答もない場合に、通常モードに復帰させ、CPU20による通信条件を確認する動作を行う。
即ち、図22の処理フローの始めに、CPU20は、DHCPプロトコルを定めたRFC2131の規定に従って、IPアドレスのリース期間の半分の値をPE24の定期送信間隔時間設定部249のTimer(1)249tに定期送信間隔時間として設定する(ステップS201)。
また、同規定に従いPE24のネットワーク送信制御部241のDHCP REQUESTパケットを再送するための繰り返し回数(N)241nを4に設定し(ステップS202)、再送制御部2411のTimer (2) 2411tの初期値を4秒に設定する(ステップS203)。
次にCPU20は、TCP/IPネットワークの次のパケット転送で使用するIPの識別子をPE24の識別子生成部2473iに設定する(ステップS205)。
さらにCPU20は、次のDHCP REQUESTパケットの転送で使用するトランザクションIDをPE24のTransactionID生成部2473tに設定する(ステップS206)。
また、DHCP NAKパケットのフィルタリング処理の処理条件についても、TransactionIDには、TransactionID生成部2473tからの値を使用して設定する。この設定に従って、上記でパターンフィルタ233について説明したように、第1及び第2のパターンフィルタを使用してDHCP NAKパケットを検出することを可能にする。
同時に、CPU20は、SEL25の設定をPE24からの出力を選択する方に切り替えて、MAC22に送り、DHCP REQUESTパケットをネットワークに送信するための準備をする(ステップS210)。
DHCP REQUESTパケットを発行する手順として、まず、TransactionID生成部2473tで新たに生成したトランザクションIDをDHCP ACKのフィルタリング処理を行うPF23のパターンフィルタ233に設定して、送信するDHCP REQUESTパケットに対するDHCP ACKパケットを検出できるように設定する(ステップS213)。
また、ネットワーク送信制御部241のTimer(2)2411tを起動する(ステップS214)。これは、Timer(2)2411tに設定された所定時間以内に送信するDHCP REQUESTパケットに対するDHCP ACKパケットが受信できたか否かを確認するために必要な動作である。
DHCP REQUESTパケット送信要求を受けたIPパケット生成部247は、DHCP REQUESTパケットを生成する一連の処理を行う。即ち、DHCPパケット生成部2476でTransactionID生成部2473tによって生成されたトランザクションIDを使用して、DHCP REQUEST(図21、参照)に従うUDPデータの部分を生成し(ステップS216)、また、UDPヘッダ生成部2472でUDPヘッダを生成する(ステップS217)。なお、ここまでに生成されたUDPデータとUDPヘッダがIPのデータになる。
さらに、IPヘッダ生成部2471で識別子生成部2473iより生成した識別子を使用してIPヘッダを生成する(ステップS218)。ここまでに生成されたIPデータともとIPヘッダがイーサネット(登録商標)フレームのデータ部分となる。
さらに、イーサネット(登録商標)フレームヘッダ生成部243では、ここで生成されるイーサネット(登録商標)フレームのヘッダとイーサネット(登録商標)フレームのデータ部分を結合して、イーサネット(登録商標)フレームを構成するDHCP REQUESTパケットを生成する(ステップS219)。
PE24は、生成したDHCP REQUESTパケットをSEL25へ出力すると、このパケットは、MAC22及びPHY12を介してネットワークに出力される(ステップS220)。
手順としては、まずPF23がDHCP ACKパケットを検出したか否かを確認する(ステップS221)。DHCP ACKパケットが検出できない場合に(ステップS221-NO)、PF23がDHCP NAKパケットを検出したか否かを確認する(ステップS222)。
DHCP NAKパケットも検出できない場合に(ステップS222-NO)、Timer(2)2411tが切れたか否かを確認する(ステップS223)。ここで、Timer(2)2411tが切れていない場合に(ステップS223-NO)、DHCP ACKパケットを検出したか否かを確認するステップS221に戻す。
移行の手続きとして、次のDHCP REQUESTパケットの転送で使用するために、PE24のTransactionID生成部2473tに設定されているトランザクションIDを更新する(ステップS231)。トランザクションIDの更新方法は、現在のトランザクションIDに1を加えた値を新しいトランザクションIDにする方法により実施することができる。
同時に、TCP/IPネットワークの次のパケット転送で使用するために、PE24の識別子生成部2473iに設定されているIPの識別子を更新する(ステップS232)。識別子の更新方法は、現在の識別子に1を加えた値を新しい識別子にする方法により実施することができる。
この後、DHCP REQUESTパケットの次の送信周期を開始すべく、ステップS211に戻し、Timer(1)249tを再起動する。DHCP ACKパケットが検出されている間、ここまでの手順でDHCP REQUESTパケットの送信が繰り返される。
そこで、PF23は、DHCP NAKを検出したときに、DHCP NAK要求をPM32に通知する。DHCP NAK要求を受取るPM32は、消費電力モードを省エネルギーモードから通常モードに移行する(ステップS241)。
また、通常モードに移行するときの手続きとして、PE24は、識別子生成部2473iの識別子とTransactionID生成部2473tのトランザクションIDを通常モードへの移行により稼動状態になったCPU20に通知し、同様にPF23は、DHCP NAKを検出したことを通知する(ステップS242)。この通知を行った後、この制御フローを終了する。
DHCP REQUESTパケットを再送するときの手続きとして、今回の再送に先立ち繰返し回数Nを1減算し、即ち、N=N−1を求め(ステップS224)、求めたNが0であるか、即ち、指定回数N再送を繰り返してN=0となっているか否かをチェックする(ステップS225)。
ここで、N=0でなければ(ステップS225-NO)、設定した繰返し回数Nに達していないので、DHCP REQUESTパケットを再送する。
DHCP REQUESTパケットの再送の手順は、TCP/IPネットワークの次のパケット転送で使用するために、PE24の識別子生成部2473iに設定されているIPの識別子を更新する(ステップS226)。
このとき、ステップS227で行うTimer(2)2411tの初期化は、RFC2131の規定に従って、前回の2倍の値、即ち、前回の値が4秒ならば、8秒に設定する、という方法により実施することができる。
そこで、PF23は、応答パケットの検出ができなかった場合に、これを自局宛要求としてPM32に通知する。自局宛要求を受取るPM32は、消費電力モードを省エネルギーモードから通常モードに移行する(ステップS241)。
また、通常モードに移行するときの手続きとして、PE24は、識別子生成部2473iの識別子とTransactionID生成部2473tのトランザクションIDを通常モードへの移行により稼動状態になったCPU20に通知し、同様にPF23は、応答パケットの検出ができなかったことを通知する(ステップS242)。この通知を行った後、この制御フローを終了する。
上記した図22の制御フローにおいて、DHCP ACKパケット及びDHCP NAKパケットのどちらも検出できない状態にあって(ステップ222-NO)、Timer(2)2411tが切れ(ステップS223-YES)、さらに設定した繰返し回数Nに達していない場合に(ステップS225-NO)、DHCP REQUESTパケットを再送する。
このとき、DHCP REQUESTパケットの再送の手順として、TCP/IPネットワークへの再送パケットの転送に使用するために、PE24の識別子生成部2473iに設定されているIPの識別子を更新する(ステップS226)としているが、PE24のTransactionID生成部2473tに設定されているトランザクションIDについては、更新していない。
ただ、同一のトランザクションIDを用いて先に送信したDHCP REQUESTパケットパケットが送信先に届いて、送信先では正常に処理された場合、次に行う再送に同一のトランザクションIDを用いると、送信先では、このトランザクションIDは、無視されてしまうので、通信が維持できなくなる。
図23は、この改変例の制御フロー図である。
図23に示す制御フローと図22に示した制御フローの相違は、DHCP REQUESTパケットの再送動作に移行する際の手順において、PE24のTransactionID生成部2473tに設定されているトランザクションIDを更新するステップS327を付加した点にある。つまり、ステップS327は、DHCP ACKパケット及びDHCP NAKパケットのどちらも検出できない状態にあって(ステップ322-NO)、Timer(2)2411tが切れ(ステップS323-YES)、さらに設定した繰返し回数Nに達していない場合に(ステップS325-NO)、DHCP REQUESTパケットを再送する手順に移行し、その移行手順において、再送するDHCP REQUESTパケットに埋め込むトランザクションIDを更新する。
なお、図23に示す制御フローは、上記ステップS327を付加した点以外に図22に示した制御フローの各ステップと変わりがない。よって、先に説明した図22の制御フローの説明を参照することとし、ここでは記載を省略する。
また、上記ようにパケットデータを再送するとき或いは所定のパケット(DHCP ACK)を受信したときに識別データを更新するので、低消費電力を維持したまま、TCP/IPの通信が可能となる。
また、上記の低消費電力を維持した交信動作をDHCPプロトコル通信で実現できる。
また、DHCPプロトコルのDHCP REQUESTパケット及びDHCP ACKパケットの通信ができるので、低消費電力を維持したまま、IPアドレスの延長要求が可能となる。
また、低消費電力モードに移行する際にCPU20が通常モードの識別データを通知するので、通常モード時と低消費電力モード時に同じ識別データ使用しないようにすることで、低消費電力中もTCP/IPプロトコル通信が可能となる。
また、低消費電力モードから通常モードに移行する時、低消費電力モードで使用していた識別子をCPU20に通知するので、低消費電力モードから通常モードに移行してもTCP/IPプロトコル通信が正常に動作する。
また、所定のパケット(DHCP ACK)が受信できない場合は、消費電力モードを通常モードに移行して、所定のパケットが受信できないことをCPU20に通知できるので、DHCPプロトコルのやり取りをDHCP DISCOVERから始めることが可能になり、DHCPサーバからIPアドレスを受け取ることができる。
また、プリンタ等の画像形成装置においても、低消費電力を維持したままDHCPプロトコル通信が行え、低消費電力のまま、IPアドレス使用の延長が可能となる。
上記実施形態1では、自発的にDHCPプロトコルに従い、DHCP REQUESTをネットワークへ送信することが可能な形態のPE24及びDHCP REQUESTに対する応答パケットを検出するPF23について実施形態を示した。次に示す実施形態は、さらに、PF23が省エネルギーモードにおいて所定フレーム構造のパケットを受取ることができ、受取ったパケットが自局宛のパケットの場合には、PE24で所定のパケットのリクエストに応えるために予め設定しておいたデータを送信元が受取ることができる所定フレーム構造のパケットとして生成し、応答することを可能にする。
なお、PF23で選択されたパケットを受取るPE24は、省エネモードの電源供給状態を維持したまま、自局宛のリクエストパケットに応答するパケットを処理する。また、PE24で応答できないパケットの処理は、省エネモードから、CPU20が動作する電源供給モードに移行させた状態で行われる。
PF23は、アドレスフィルタ231、パターンフィルタ233、バッファ235を構成要素とする。
アドレスフィルタ231には、ユニキャストアドレスとマルチキャストアドレスが登録可能である。また、このプリンタ機器自身や機器内のアクセス可能なデバイス(例えば、プロッタ2など)のアドレスが設定可能である。
アドレスフィルタ231は、MAC22から入力したパケットのタイプを参照し、そのタイプからパケットの種類を判断し、設定されたアドレスをチェックすることで、アクセス可能な機器やデバイスに対するパケットのみを通過させ、パターンフィルタ233へ送り、その他のパケットは破棄する選別を行う。
また、ブロードキャストパケットは、アドレスフィルタ231の設定に関係無く、通過させてパターンフィルタ233へ送る。
自局宛アドレスのパケットとは、アドレスフィルタ231を通過させるパケットである。従って、自局宛アドレスには、登録したユニキャストアドレス(機器自身や機器内のデバイスのIPアドレス) 登録したマルチキャストアドレス 及びブロードキャストアドレスが含まれる。
ここでは、パターンフィルタ233において、非マスク領域に設定するデータは、バイト単位で設定できるようにし、入力パケットをこの設定データと比較し、一致した場合にのみ、当該パケットを通過させる。
また、所定長のパターンフィルタを所望の対象領域に設定するために、このパターンフィルタ233には、パターンオフセットを設定できる。このパターンオフセットは、パターンオフセット1とパターンオフセット2のオフセット値で管理する。
パターンオフセット1は、イーサネット(登録商標)フレームの開始からのオフセット長である。このパターンフィルタ233によるフィルタリングをイーサネット(登録商標)フレームのタイプ(後記する図13、参照)から開始する場合は、パターンオフセット1の長さは、宛先MACアドレス長と送信元MACアドレス長を加算した値になる。
また、パターンオフセット2は、パターンフィルタ231の先頭からのオフセットを示す。パターンオフセットからの1バイトは、ビットマスク値によって、ビット毎にフィルタリングが可能である。ビットマスク値で「1」を設定したビットは、マスク領域である。
パターンフィルタ233では、アドレスフィルタ231から受信したパケットが非印刷要求のパケットか印刷要求のパケットかを判断し、非印刷要求のパケットの場合はPM32にその旨を通知し、印刷要求のパケットの場合はPM32にその旨を通知し、上述のフィルタリング後のパケットをバッファ235へ出力する。また、アドレスフィルタ231から受信したパケットがARPリクエストパケットの場合は、SEL25にPE_ON信号を送り、PE24へARPリクエストパケットを出力する。
以下には、非印刷要求のうちPE24で応答可能なリクエストを設定したパケットを通過させるフィルタリング処理について、異なるパケットの種類を例示し、説明する。
図25は、PF23におけるTCPパケットのフィルタリング処理を説明する図である。
図25(a)はTCPパケットのネットワークフレームのフォーマット(図7、参照)を示し、図25(b)には、PF23のパターンフィルタ233に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。
TCPパケットのフィルタリング処理条件は、図25(b)示すように、PF23のパターンフィルタ233には、パターンオフセット1として、宛先MACアドレス長と送信元MACアドレス長を加算した値を設定し、TCPパケットの先頭の16ビットのタイプを参照するので、ここを非マスク領域として設定する。TCPパケットの場合、タイプには、パターンフィルタ233の先頭の16ビットにIPプロトコルを示す「0x0800」が設定されている。
さらに、TCPヘッダとの比較値を設定し、そのTCPヘッダの宛先ポート番号に使用するアプリケーションのポート番号を設定し、TCPヘッダのコードビットとの比較値を設定する。
TCPパケットでは、コードビットはTCPヘッダの先頭から14バイト目にあるので、図25(b)に示すように、パターンオフセット2を13バイトに設定する。
パターンフィルタ233の14バイト目に「0x02」を設定すると、図25(c)に示すTCPパケットのコードビットのSYN(接続要求)と比較することができる。
さらに、ビットマスク値を「0xC2」に設定すると、コードビットのSYNが1のTCPパケットを通過させることができる。
さらに、図25(b)に示す、ビットマスク後の部分もマスク領域(図中に斜線を施した部分)に設定する。
なお、TCPヘッダの宛先ポート番号を、http(Hypertext Transfer Protocol)のアプリケーションの場合には、80に設定し、印刷プロトコルであるLPDの場合には、515に設定する。
SYN以外のビット、例えば、ACKをフィルタリングする場合は、ビットマスク値を「0xD0」に変更すればよい。
このようにして、パターンフィルタ233は、上記したコードビットのSYN(接続要求)を通過条件とする設定のように、非印刷要求のうちPE24で応答可能なリクエストのパケットをフィルタリング処理できる設定とし、設定条件に合うパケットを通過させる場合、SEL25へのPE_ON信号をアクティブにするとともに、通過させるパケットをPE24に出力する。
なお、パターンフィルタ233に印刷プロトコルであるLPDアプリケーションの宛先ポート番号「515」を設定すると、それに対応するTCPを受信した場合、印刷要求信号をアクティブにして、PM32に通知する。
図26は、PF23におけるUDPパケットのフィルタリング処理を説明する図である。
図26(a)はUDPパケットのネットワークフレームのフォーマット(図4、参照)を示し、図26(b)には、PF23のパターンフィルタ233に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。
UDPパケットのフィルタリング処理条件は、図26(b)示すように、PF23のパターンフィルタ233には、パターンオフセット1として、宛先MACアドレス長と送信元MACアドレス長を加算した値を設定し、UDPパケットの先頭の16ビットのタイプを参照するので、ここを非マスク領域として設定する。UDPパケットの場合、タイプには、パターンフィルタ233の先頭の16ビットにIPプロトコルを示す「0x0800」が設定されている。
さらに、UDPヘッダとの比較値を設定し、そのUDPヘッダの宛先ポート番号に使用するアプリケーションのポート番号を設定し、その他のUDPのヘッダ領域はマスク領域(図中に斜線を施した部分)とする。
機器の状態を外部に知らせるために公開されるMIB(Management Information Base)情報をアクセスしに来たときに、応答するためには、SNMP(Simple Network Management Protocol)プロトコルやhttp(Hypertext Transfer Protocol)を使用する必要がある(後述するPE24の説明、参照)。SNMPやhttpは、UDPを利用することができる。UDPのパターンフィルタ233における上記UDPヘッダの宛先ポート番号を入れる領域に、MIB情報にアクセスするアプリケーションのポート番号を設定することで、このリクエストのパケットをフィルタリングすることが可能になる。
このようにして、パターンフィルタ233は、上記したMIB情報にアクセスするアプリケーションのポート番号を通過条件とする設定のように、非印刷要求のうちPE24で応答可能なリクエストのパケットをフィルタリング処理できる設定とし、設定条件に合うパケットを通過させる場合、SEL25へのPE_ON信号をアクティブにするとともに、通過させるパケットをPE24に出力する。
図27は、PF23におけるARPパケットのフィルタリング処理を説明する図である。
図27(a)はARPパケットのネットワークフレームのフォーマット(図11、参照)を示し、図27(b)には、PF23のパターンフィルタ233に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。
ARPパケットのフィルタリング処理条件は、図27(b)示すように、PF23のパターンフィルタ233には、パターンオフセット1として、「0」を設定して、ARPパケットのフレームの開始から比較できるようにする。ARPパケットのイーサネット(登録商標)ヘッダの先頭の宛先MACアドレスを参照するので、ここを非マスク領域として設定する。ARPプロトコルは、ブロードキャストなので、パターンフィルタ233のARPパケットの宛先MACアドレスにあたる全てのビットに「1」を設定する。
さらに、イーサネット(登録商標)ヘッダの送信元MACアドレスは、マスク領域(図中に斜線を施した部分)として設定する。
その後に、ハードウェアタイプを「1」、プロトコルフィールドを「IP」、MACアドレス長を「6」、プロトコルアドレス長はIPv4なので「4」、オペレーションコードにはARP要求を示す「1」を設定する。
送信元ハードウェアアドレス(SHA)、送信元IPアドレス(SIP)、宛先ハードウェアアドレス領域(DHA)には、それぞれマスク領域(図中に斜線を施した部分)を設定する。
宛先IPアドレス(DIP)にはこのプリンタのIPアドレスを設定し、残りの部分はマスク領域(図中に斜線を施した部分)とする。
パターンフィルタ233に、非印刷プロトコルであるhttpアプリケーションの宛先ポート番号「80」、SNMPプロトコルを設定すると、それに対応するARPリクエストパケットを受信した場合、非印刷要求信号をアクティブにして、PM32に通知する。
パターンフィルタ41にARPパケットの設定をすると、ARPリクエストパケットの受信時にSEL25へのPE_ON信号をアクティブにするとともに、通過させるパケットをPE24に出力する。
図28は、PF23におけるICMPパケットのフィルタリング処理を説明する図である。
図28(a)はICMPパケットのネットワークフレームのフォーマット(図9、参照)を示し、図28(b),(d)には、それぞれICMPパケット内の各フィールドのデータ内容を示し、図28(d)には、PF23のパターンフィルタ233に処理条件として設定する、マスク領域と非マスク領域及び非マスク領域の処理対象として参照するデータを示す。なお、図28(b),(d)は、ICMPエコーリクエストパケットのデータを示している。
ICMPパケットのフィルタリング処理条件は、図28(d)示すように、PF23のパターンフィルタ233には、パターンオフセット1として、宛先MACアドレス長と送信元MACアドレス長を加算した値を設定し、TCPパケットの先頭の16ビットのタイプを参照するので、ここを非マスク領域として設定する。ICMPパケットの場合、タイプには、パターンフィルタ233の先頭の16ビットにIPプロトコルを示す「0x0800」が設定されている。
さらに、プロトコル番号にはICMPプロトコル番号を、宛先IPアドレスには自局アドレスとしてこのプリンタのIPアドレスを設定し、ICMPのタイプにはICMPエコーリクエストパケットを示す「8」を設定し、その他のIPヘッダはマスク領域(図中に斜線を施した部分)として設定する。
ただし、IPヘッダのパケット長の比較値lenを92バイト以下に設定する。この92バイトは、ICMPデータのサイズが64バイト、IPヘッダ長が20バイトの場合の設定である。
なお、PF23は、ICMPパケットデータのサイズが64バイトを超える場合は、非印刷要求パケットを受信したことをPM32に通知して、バッファ42に蓄積する。この場合はコントローラモードに遷移して処理を行うことになる。また、ICMPパケットデータのサイズは通常64バイトなので、ハードウェアを簡略化するために、ICMPパケットデータが64の時のみPINGパケットであることを認識するように回路設計をしても、実用上問題がない。
登録されたマルチキャストアドレスの場合、登録された個数分のフィルタを用意して、宛先IPアドレスに登録したマルチキャストアドレスを設定すればよい。また、宛先IPアドレスの設定以外は上記の設定と同じである。
図1に示すPE24のもう1つの実施形態について説明する。
以下には、プリンタがネットワークから受信したパケットのうち、上記した実施形態2のPF23で所定の設定条件に従い通過させた、MIB情報にアクセスするためのUDPパケット、ARPパケット等へ応答するパケットを生成する手段、及び後述するSSDP(Simple Service Discovery Protocol)のアドバタイズとしてUDPパケットを生成する手段としての機能を持つPE24の構成及び動作を説明する。
本実施形態のPE24は、省エネモードの電源供給状態を維持したまま、リクエストに応答するリプライパケットを生成する処理を行う。また、UDPパケットを生成する処理を行う。なお、PE24で応答できないパケットは、省エネモードから、CPU20が動作する電源供給モードに移行させた状態で処理される。
PE24は、ネットワーク送信制御部241、レジスタ部242、Ether(イーサ)フレームヘッダ生成部243、ARPリプライパケット生成部244、PINGリプライパケット生成部245、IPパケット生成部247、ARPリプライパケット生成部244の出力とPINGリプライパケット生成部245の出力とIPパケット生成部247の出力を選択する第1セレクタ246からなる。
ネットワーク送信制御部241は、レジスタ部242、Etherフレームヘッダ生成部243、ARPリプライパケット生成部244、PINGリプライパケット生成部245、IPパケット生成部247、ARPリプライパケット生成部244の出力とPINGリプライパケット生成部245の出力とIPパケット生成部247の出力を選択する第1セレクタ246を制御する。
“ARP応答”
図29のARPリプライパケット生成部244で行うARP応答について説明する。
ARPとは、IPアドレスにより特定される通信相手のMACアドレスを知るためのプロトコルであり、調査対象の装置に対してARPリクエストを送って、その装置からARPリプライを受取る。PE24は、PF23からフィルタリングされたARPリクエストパケットを受取り、ARP応答としてネットワークに送信するARPリプライパケットを生成する。
ARP応答時には、第1セレクタ246では、ARPリプライパケット生成部244の出力を選択する。
図30にPE24におけるARPリプライパケット生成部244を示す。ARPリプライパケット生成部244は、パケット解析部2441、パケット生成部2442、レジスタ部242からなる。なお、レジスタ部242は、後述するPINGリプライパケット生成部245と共通に使用される要素である。
パケット解析部2441は、PF23からのARPリクエストパケットを入力する。
ARPリクエストパケットは、図30のパケット解析部2441ブロック内にフレームを示すように、宛先MACアドレスフィールド、SHA(要求元ハードウェアアドレス)、ARP、ハードウェアタイプフィールド、プロトコルフィールド、MACアドレス長フィールド、プロトコルアドレス長フィールド、ARPリクエストフィールド、SHA、SIP(要求元IPアドレス)、DHA(宛先ハードウェアアドレス)、DIP(宛先IPアドレス)からなる。
また、レジスタ部242のSHAに、このプリンタのハードウェアアドレスを設定し、SIPに、このプリンタのIPアドレスを設定しておく。このレジスタ部242のSHA及びSIPの設定は、CPU20の動作によって行われ、省エネモード中はできないので、予めCPU20が動作しているときに行っておく。
イーサネット(登録商標)ヘッダ2442eは、DHA、SHA、タイプの各フィールドから構成され、レジスタ部242のDHAから読み出した値をDHAへ、レジスタ部242のSHAから読み出した値をSHAへそれぞれ設定する。また、タイプフィールドにはARPパケットを示す「0x0806」を設定する。
さらに、イーサフレームのデータ部には、アープリプライパケット2442aを設定する。
また、OPフィールドには、ARPリプライを示す2を設定し、SHAフィールドには、レジスタ部242のSHAの値を、SIPフィールドには、レジスタ部242のSIPの値を、DHAフィールドには、レジスタ部242のDHAの値を、DIPフィールドには、レジスタ部242のDIPの値をそれぞれ設定する。
パケット生成部2442で生成されたARPレスポンスパケットをネットワークへ送信するには、PF23から出力されるPE_ON信号がアクティブになると、SEL25がPE24から出力されたARPレスポンスパケットをMAC22へ送信する。なお、PE_ON信号が非アクティブ時は、内部バス34からのデータがMAC22に入力される。
以上のように、パケット生成部2442では、ARPリクエストの送信元が受取ることができるフレーム構造のパケットとしてARPレスポンスパケットが、主制御部のCPU20、メモリ11を使用せずに、生成される。生成されたARPレスポンスパケットは、SEL25、MAC22、PHY12を経由してネットワークへ送信される。
図29のPINGリプライパケット生成部245で行うPING応答について説明する。
PINGとは、ICMPプロトコルによって調査対象の装置に対してICMPエコーリクエストパケットを送って、その装置からの返信の有無や応答時間などのデータに基づいてネットワークを診断するプログラムである。PE24は、PF23からフィルタリングされたICMPエコーリクエストパケットを受取り、PING応答としてネットワークに送信するPINGリプライパケットを生成する。
PING応答時には、第1セレクタ246では、PINGリプライパケット生成部245の出力を選択する。
図31にPE24におけるPINGリプライパケット生成部245を示す。PINGリプライパケット生成部245は、パケット解析部2451、パケット生成部2452、レジスタ部242からなる。なお、レジスタ部242は、前述のARPリプライパケット生成部244と共通に使用される要素である。
ICMPエコーリクエストパケットは、図31のパケット解析部2451ブロック内にフレームを示すように、宛先MACアドレス、SHA(要求元ハードウェアアドレス)、プロトコルタイプ、バージョン・ヘッダ長、サービスタイプ、パケット長、識別子、フラグ・フラグメントオフセット、TTL(生存期間)、プロトコル番号、ヘッダチェックサム、SIP(要求元IPアドレス)、宛先IPアドレス(DIP)、メッセージタイプ、コードフィールド、チェックサム、識別子、シーケンス番号、ICMPデータの各フィールドからなる。
IPデータのメッセージタイプには、ICMPエコーリクエストパケットを示す「8」が格納されている。
また、レジスタ部242のSHAに、このプリンタのハードウェアアドレスを設定し、SIPに、このプリンタのIPアドレスを設定しておく。このレジスタ部242のSHA及びSIPの設定は、CPU20の動作によって行われ、省エネモード中はできないので、予めCPU20が動作しているときに行っておく。
また、ICMPエコーリクエストパケットのプロトコルタイプフィールドのIPを示す0x800を、パケット生成部2452のICMPエコーリプライパケットのイーサネット(登録商標)ヘッダ2452eのプロトコルタイプフィールドにコピーする。
上記チェックサムの計算は、例えば、オーム社発行の書籍「マスタリングTCP/IP 応用編」で記載されている1の補数演算方法を使用することにより実施しうる。
さらに、ICMPエコーリプライパケットのIPヘッダ2452pのSIPフィールドには、レジスタ部242のSIPのデータを設定し、同DIPフィールドには、レジスタ部242のDIPのデータを設定する。
また、ICMPヘッダ2452iのコードフィールドは「0」を設定し、IPデータのチェックサムを計算して、チェックサム(Check SUM)フィールドに設定する。
上記チェックサムの計算は公知技術(例えば、オーム社発行の書籍「マスタリングTCP/IP 応用編」で記載されている1の補数演算方法)を使用すればよい。
以上のように、パケット生成部2452では、ICMPエコーリクエストの送信元が受取ることができるフレーム構造のパケットとしてICMPエコーリプライパケットが、主制御部のCPU20、メモリ11を使用せずに、生成される。生成されたICMPエコーリプライパケットは、SEL25、MAC22、PHY12を経由してネットワークへ送信される。
図29のIPパケット生成部247で行うUDP応答について説明する。UDP応答に使用するUDPパケットのフォーマットとして先に示した図18を以下の説明で参照する。
ここで説明するUDP応答の一つは、UDPを用いるSNMPやhttpの各プロトコルによってアクセスできるMIB情報を得るために、ネットワークから送信されてくるUDPリクエストに応えて、MIB情報をUDPデータとしてネットワークに送信する動作である。
PE24は、PF23からフィルタリングされたMIB情報をアクセスできるUDPリクエストパケットを受取り、UDP応答としてネットワークにMIB情報をUDPデータとして設定したUDPパケットを生成する。
ただし、IPパケット生成部247の出力と、ARPリプライパケット生成部244の出力、PINGリプライパケット生成部245の出力との競合をさけるために、各パケット生成部の出力のタイミングが重なった場合、ネットワーク送信制御部241では、予め定めた優先順位に従い出力動作を行うようにする。
優先順位の例は、ARPリプライパケット生成部244の出力、PINGリプライパケット生成部245の出力、IPパケット生成部247の出力の順とする。
なお、IPパケット生成部247の出力は、第1セレクタ246に入力され、UDP応答時に選択され、ネットワークに送信される。
データ記憶部2475に格納する、非印刷要求パケットに応じて送信されるMIB情報等のデータの設定は、CPU20の動作によって行われ、省エネモード中はできないので、省エネモードに移行する前にCPU20が動作しているときに予め更新しておく。予め更新しておけば、通常時の情報を省エネモード時にアクセス可能となる。
SSDPは、ネットワーク上の機器を検出するプロトコルであり、機器情報をUDPパケットで送信処理を行う。機器情報についても、データ記憶部2475に用意する。このデータも、省エネモードに移行する前のCPU20が動作しているときに予め最も新しいデータを用意しておく。
このとき、第2セレクタ2474により選択される応答用データを取出すタイミングは、第1選択間隔時間生成部2478及び第2選択間隔時間生成部2479によって、単位サイクル内のデータの間隔と繰り返しサイクルの間隔を決めることができる。
例えば、全データを対象とし、データ1、データ2、データ3、データ4の順で選択する場合、第1選択間隔時間生成部2478で生成した第1選択間隔時間で、データ1、データ2、データ3、データ4の順で1サイクルの選択をする。また、データ4を選択後、第2選択間隔時間生成部2479で生成した第2選択間隔時間経過後に、次のサイクルに入り、再度、データ1を選択する。このサイクルでも、第1選択間隔時間が経過すれば、再度データ2から順にデータ3、データ4を選択する、という動作を繰返す。
宛先ポート番号(DPN)、送信元ポート番号(SPN)は、識別データ生成部2473で生成する。宛先ポート番号(DPN)は、データ1からデータ4共に、同じ値を生成しても良い。例えば、SSDPのプロトコルの場合は、「1900」が宛先番号で、SNMPの場合、「162」のポート番号というように、使用するプロトコルによって定められた番号を設定する。送信元ポート番号(SPN)は、データ1、2、3、4毎に、固有な値を設定しても良い。例えば、データ1のポート番号は「5000」、データ2のポート番号は「4999」、データ3のポート番号は「4998」、データ4のポート番号は「4997」と設定する。
セグメント長(len)は、UDPデータの長さを設定する。チェックサム(SUM)は、ヘッダ、UDPデータの1の補数を16ビットで示す。
予め、このプリンタの自局IPアドレスをレジスタ部242のSIPに、また、このプリンタの自局のハードウェアアドレスをレジスタ部242のSHAに設定しておく。
また、UDPデータがSSDPプロトコルの場合には、マルチキャストアドレスを使用するので、マルチキャストアドレスに応じたIPアドレスをレジスタ部242のDIPに、マルチキャストアドレスに対応したハードウェアアドレスをレジスタ部242のDHAに設定しておく。これらのアドレスは、公知技術(例えば、オーム社発行の書籍「マスタリングTCP/IP 応用編」P.301に記載されている設定方法)を採用すればよい。
レジスタ部242のTYPEには、IPフォーマットを示す「0x800」を設定しておく。
識別子(ID)は、識別データ生成部2473で生成した識別子を設定する。この識別子は、ICMP(PING)リプライパケット生成時の識別子としても使用される。識別子は、IPパケットを送信する度に新たに生成する。
フラグには、分割不可、後続フラグメント無し、を設定して、フラグメントオフセットは0に設定する。生存時間(TTL)は、最大値の255を設定する。プロトコルには、UDPを示す値である「17」を設定する。ヘッダチェックサム(SUM)は、IPヘッダとIPデータのチェックサムを計算する。送信元IPアドレス(SIP)、宛先IPアドレス(DIP)は、レジスタ部242に設定してあるSIP、DIPを設定する。
また、ヘッダのオプションは生成しない。
イーサネット(登録商標)パケットのFCSは、後段のMAC22で自動生成されるので、パケットPE24では生成する必要はない。
また、SSDPのアドバタイズ情報を定期的に送信する場合、PE24がアドバタイズ情報を作成し送信処理を行い、主制御部のCPUとメモリを動作させないので、主制御部のCPUとメモリの消費電力を削減できる。
また、PE24は、低消費電力モード時に非印刷要求に応答する受信したパケットのサイズが所定サイズ以下の場合に応答し、また、応答時の返信情報を予め定めたサイズの複数の応答用データで対応するようにしたので、PE24のハードウェアコストを小さくでき、消費電力を削減し、コストを低減できる。
さらに、PE24は、受信したパケットの情報の一部を組み込んで応答用のパケットを作成して、応答処理を行うので、ハードウェアコストを小さくでき、消費電力を削減し、コストを低減できる。
Claims (23)
- CPUを有する主制御部と、少なくとも前記主制御部のCPUへの電源供給を停止する第1低消費電力モードの制御動作を含む低消費電力の電源供給制御をする電源制御部と、
ネットワークとパケットを交信する通信部と、前記通信部を経て送信する所定フレーム構造のパケットを生成するパケット生成部と、前記通信部で受信したパケットから所定フレーム構造を持つ受取るべきパケットを検出するパケットフィルタ部と、前記パケット生成部によって生成されたパケットを所定のタイミングで送信する送信制御部を有し、印刷要求を処理する機能を持つ情報処理装置であって、
前記電源制御部は、前記第1低消費電力モード時に前記通信部、前記パケットフィルタ部及び前記パケット生成部を動作させるための電源供給の制御を行い、さらに前記第1低消費電力モードから電源供給を一部復帰させる第2低消費電力モードにおいて、前記主制御部のCPUを動作させて非印刷要求に応じる制御動作を行い、
前記送信制御部は、前記第1低消費電力モード時に前記パケット生成部によって生成されたDHCP REQUESTパケットを予め設定された送信時間間隔で定期的に送信することを特徴とする情報処理装置。 - 請求項1に記載された情報処理装置において、
前記パケット生成部は、ネットワークからの応答を求める前記DHCP REQUESTパケットを自発的に生成するとともに、前記パケットフィルタ部は、前記応答を求める前記DHCP REQUESTパケットに対する応答パケットを検出し、
前記送信制御部は、前記応答を求める前記DHCP REQUESTパケットを送信した後、前記DHCP REQUESTパケットに対する応答パケットが所定時間内に前記パケットフィルタ部によって検出されないときに、該応答を求める前記DHCP REQUESTパケットを再送する動作を所定回数にわたり行うようにしたことを特徴とする情報処理装置。 - 請求項2に記載された情報処理装置において、
前記パケットフィルタ部は、受信する前記応答パケットとして、DHCPプロトコルデータによるパケットを検出するようにしたことを特徴とする情報処理装置。 - 請求項2又は3に記載された情報処理装置において、
前記パケット生成部は、送信データを記憶する送信データ記憶手段と、前記送信データを送信ごとに識別するための識別データを生成する識別データ生成手段と、前記識別データ生成手段で生成した識別データと前記送信データ記憶手段からの送信データを組合せてパケットを生成する手段を備え、
前記識別データ生成手段は、前記応答を求める前記DHCP REQUESTパケットを再送する際、並びに前記パケットフィルタ部を介して前記応答パケットを受信した際に識別データを更新するようにしたことを特徴とする情報処理装置。 - 請求項4に記載された情報処理装置において、
前記識別データ生成手段は、DHCPプロトコルで使用するトランザクションIDを識別データとして用いるようにしたことを特徴とする情報処理装置。 - 請求項4又は5に記載された情報処理装置において、
前記主制御部のCPUは、前記第1低消費電力モードへ移行する際に前記識別データ生成手段へ前記第1低消費電力モード時に使用する識別データを通知するようにしたことを特徴とする情報処理装置。 - 請求項4乃至6のいずれかに記載された情報処理装置において、
前記識別データ生成手段は、前記第1低消費電力モードから他のモードに移行する際に前記第1低消費電力モードで使用していた識別データを前記主制御部のCPUに通知するようにしたことを特徴とする情報処理装置。 - 請求項2乃至7のいずれかに記載された情報処理装置において、
前記パケットフィルタ部は、前記応答パケットを受信できないときに、前記電源制御部に前記第1低消費電力モードから通常電力モードへの移行を指示するとともに、前記応答パケットを受信できないことを前記主制御部のCPUに通知するようにしたことを特徴とする情報処理装置。 - 請求項1に記載された情報処理装置において、
前記パケットフィルタ部は、前記第1低消費電力モードで応答を求めるリクエストパケットを検出し、検出結果を前記パケット生成部に通知する手段を備え、
前記パケット生成部は、前記パケットフィルタ部から前記リクエストパケットの検知結果の通知を受けて、当該リクエストパケットに応答するパケットを生成するための手段として、複数の応答用データを記憶する応答用データ記憶手段と、前記応答用データ記憶手段から送信データを選択する送信データ選択手段をさらに備えたことを特徴とする情報処理装置。 - 請求項9に記載された情報処理装置において、
前記パケット生成部は、第1の選択間隔時間を設定する第1選択間隔時間設定部を備え、
前記送信データ選択手段は、複数の応答用データから、前記第1選択間隔時間設定部で設定した第1の選択間隔時間で、一つずつデータを選択することを特徴とする情報処理装置。 - 請求項9又は10に記載された情報処理装置において、
前記パケット生成部は、第2の選択間隔時間を設定する第2選択間隔時間設定部を備え、
前記送信データ選択手段は、前記第1選択間隔時間設定部で設定した第1の選択間隔時間で、一つずつデータを選択する動作を全送信データに対して行った後、前記第2選択間隔時間設定部で設定した第2の選択間隔時間が経過した後、再度、前記第1選択間隔時間設定部で設定した第1の選択間隔時間で、一つずつデータを選択する動作を繰返すことを特徴とする情報処理装置。 - 請求項9乃至11のいずれかに記載された情報処理装置において、
前記パケット生成部は、送信データを記憶する送信データ記憶手段と、前記送信データを送信ごとに識別するための識別データを生成する識別データ生成手段と、前記識別データ生成手段で生成した識別データと前記送信データ記憶手段からの送信データを組合せてパケットを生成する手段を備え、
前記識別データ生成手段は、複数の識別データを生成することを特徴とする情報処理装置。 - 請求項12に記載された情報処理装置において、
前記パケット生成部において生成するパケットがIPフレーム構造のパケットであることを特徴とする情報処理装置。 - 請求項13に記載された情報処理装置において、
前記識別データ生成手段で生成する複数の識別データがIPフレーム構造のパケットにおける識別子であることを特徴とする情報処理装置。 - 請求項13又は14に記載された情報処理装置において、
複数の応答用データがUDPフレーム構造のパケットにおけるUDPデータであることを特徴とする情報処理装置。 - 請求項15に記載された情報処理装置において、
前記識別データ生成手段において生成する複数の識別データがUDPフレーム構造のパケットにおけるポート番号であることを特徴とする情報処理装置。 - 請求項1乃至14のいずれかに記載された情報処理装置と印刷要求に応じた画像を形成する手段を具備する画像形成装置。
- コンピュータを請求項1乃至16のいずれかに記載された情報処理装置における前記主制御部、前記電源制御部、前記通信部、前記パケット生成部、前記パケットフィルタ部、前記送信制御部の各部として機能させるためのプログラム。
- 請求項18に記載されたプログラムを記録したコンピュータ読取可能な記録媒体。
- 主制御部が有するCPUへの電源供給を少なくとも停止する第1低消費電力モードの電源供給制御時に、所定フレーム構造の送信パケットを生成し、生成したパケットをネットワークに送信し、かつネットワークから所定フレーム構造を持つパケットを受信でき、印刷要求を処理する機能を持つ情報処理装置における情報処理方法であって、
前記第1低消費電力モードから電源供給を一部復帰させる第2低消費電力モードにおいて、前記主制御部のCPUを動作させて非印刷要求に応じる制御動作を行う工程と、
送信データのパケットを生成するパケット生成工程と、
第1低消費電力モードの電源供給制御時に前記パケット生成工程によって生成されたDHCP REQUESTパケットを予め設定された送信時間間隔で定期的にネットワークに送信する送信制御工程を有したことを特徴とする情報処理方法。 - 請求項20に記載された情報処理方法において、
前記パケット生成工程は、ネットワークからの応答を求める前記DHCP REQUESTパケットを自発的に生成する工程であり、
前記送信制御工程は、前記パケット生成工程で応答を求める前記DHCP REQUESTパケットを送信した後、前記DHCP REQUESTパケットに対する応答パケットが受信されないときに、該応答を求める前記DHCP REQUESTパケットを再送する動作を指定回数にわたり行うようにした工程であることを特徴とする情報処理方法。 - 請求項21に記載された情報処理方法において、
送信ごとに送信データを識別するための識別データを生成する識別データ生成工程を有し、前記パケット生成工程は、前記識別データ生成工程で生成した識別データと送信データを組合せてパケットを生成する工程であり、
前記識別データ生成工程は、前記応答を求める前記DHCP REQUESTパケットを再送する際、並びにパケットフィルタ部を介して前記応答パケットを受信した際に識別データの更新を行う工程であることを特徴とする情報処理方法。 - 請求項20に記載された情報処理方法において、
受信したパケットから所定フレーム構造を持つ受取るべきリクエストパケットを通過させるパケットフィルタリング工程と、
パケットフィルタリング工程で通過させるパケットが第1低消費電力モードの電源供給制御時に応答可能なリクエストパケットであることを、設定されたデータ内容に基づき認識する応答リクエスト認識工程をさらに有し、
前記パケット生成工程は、応答リクエスト認識工程の認識結果を受けて、複数の応答用データから選択したデータに識別データを組み合わせて、所定フレーム構造のパケットを生成する工程をさらに有したことを特徴とする情報処理方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008182464A JP5417755B2 (ja) | 2007-10-23 | 2008-07-14 | 情報処理装置、情報処理方法及びプログラム |
US12/428,192 US8368929B2 (en) | 2007-10-23 | 2009-04-22 | Information processing apparatus, method, and program |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007275479 | 2007-10-23 | ||
JP2007275479 | 2007-10-23 | ||
JP2008182464A JP5417755B2 (ja) | 2007-10-23 | 2008-07-14 | 情報処理装置、情報処理方法及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2009119849A JP2009119849A (ja) | 2009-06-04 |
JP5417755B2 true JP5417755B2 (ja) | 2014-02-19 |
Family
ID=40812535
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008182464A Expired - Fee Related JP5417755B2 (ja) | 2007-10-23 | 2008-07-14 | 情報処理装置、情報処理方法及びプログラム |
Country Status (2)
Country | Link |
---|---|
US (1) | US8368929B2 (ja) |
JP (1) | JP5417755B2 (ja) |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5699426B2 (ja) * | 2009-08-13 | 2015-04-08 | 富士ゼロックス株式会社 | 省電力制御装置及びプログラム |
JP2011071760A (ja) * | 2009-09-25 | 2011-04-07 | Canon Inc | 情報処理装置、情報処理装置のジョブ処理方法、及びプログラム |
JP5791223B2 (ja) * | 2009-09-25 | 2015-10-07 | キヤノン株式会社 | 印刷装置、ネットワークインターフェースユニット、印刷装置の制御方法およびプログラム |
JP2011087043A (ja) * | 2009-10-14 | 2011-04-28 | Nec Access Technica Ltd | ルータ装置、通信システム、ルータ装置の動作切り替え方法およびプログラム |
JP5218462B2 (ja) * | 2010-03-26 | 2013-06-26 | ブラザー工業株式会社 | 通信装置 |
JP2012148446A (ja) * | 2011-01-18 | 2012-08-09 | Murata Machinery Ltd | ネットワーク装置 |
JP2012156602A (ja) | 2011-01-21 | 2012-08-16 | Ricoh Co Ltd | 情報処理装置、通信制御方法、及び通信制御システム |
JP5735853B2 (ja) * | 2011-05-09 | 2015-06-17 | キヤノン株式会社 | 通信装置及びその制御方法とプログラム |
JP5817287B2 (ja) * | 2011-07-25 | 2015-11-18 | 株式会社リコー | 情報処理装置と情報処理方法とプログラム |
JP2013166307A (ja) | 2012-02-15 | 2013-08-29 | Ricoh Co Ltd | 電子機器、画像処理装置及び機器制御方法 |
JP5967979B2 (ja) * | 2012-03-05 | 2016-08-10 | キヤノン株式会社 | 情報処理装置、情報処理システムの制御方法、情報処理装置の制御方法およびプログラム |
JP6261156B2 (ja) * | 2012-03-06 | 2018-01-17 | キヤノン株式会社 | 画像形成装置 |
JP5882261B2 (ja) * | 2013-07-10 | 2016-03-09 | 京セラドキュメントソリューションズ株式会社 | 画像形成装置 |
JP6478503B2 (ja) * | 2014-07-14 | 2019-03-06 | キヤノン株式会社 | 画像処理装置及びその制御方法、プログラム、並びに画像処理システム |
JP6249028B2 (ja) * | 2016-03-07 | 2017-12-20 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
US10505719B2 (en) * | 2016-04-28 | 2019-12-10 | International Business Machines Corporation | Method and system for rateless and pollution-attack-resilient network coding |
WO2018140401A2 (en) * | 2017-01-27 | 2018-08-02 | Intel IP Corporation | Buffer status report enhancements for tcp flow |
JP7167439B2 (ja) * | 2017-12-28 | 2022-11-09 | 株式会社リコー | 情報処理装置、脆弱性検知方法およびプログラム |
JP7238561B2 (ja) * | 2019-04-11 | 2023-03-14 | 京セラドキュメントソリューションズ株式会社 | 情報処理装置及びパケットパターン生成プログラム |
JP7103300B2 (ja) * | 2019-05-08 | 2022-07-20 | 株式会社デンソー | 車載通信システム、中継装置、及び通信方法 |
CN113434459B (zh) * | 2021-06-30 | 2022-09-02 | 电子科技大学 | 基于生成对抗网络的片上网络任务映射方法 |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6498791B2 (en) * | 1998-04-03 | 2002-12-24 | Vertical Networks, Inc. | Systems and methods for multiple mode voice and data communications using intelligently bridged TDM and packet buses and methods for performing telephony and data functions using the same |
JP2000141831A (ja) * | 1998-11-09 | 2000-05-23 | Ricoh Co Ltd | I/o装置および画像形成装置 |
JP3773688B2 (ja) * | 1999-03-10 | 2006-05-10 | 株式会社リコー | ネットワークに接続可能な機器 |
JP3983453B2 (ja) * | 1999-04-27 | 2007-09-26 | 株式会社リコー | 画像情報処理装置および画像情報処理システム |
JP2001353929A (ja) * | 2000-06-12 | 2001-12-25 | Ricoh Co Ltd | 印刷装置 |
AU2001289010A1 (en) * | 2000-09-12 | 2002-03-26 | Netmotion Wireless, Inc. | Method and apparatus for providing mobile and other intermittent connectivity ina computing environment |
JP3625280B2 (ja) * | 2001-11-02 | 2005-03-02 | 松下電器産業株式会社 | 通信方法、通信装置及び通信システム |
JP2003303080A (ja) * | 2002-04-10 | 2003-10-24 | Ricoh Co Ltd | ネットワークインターフェイス回路及びデータ出力システム |
JP4271520B2 (ja) * | 2003-07-22 | 2009-06-03 | 株式会社リコー | 画像形成装置 |
JP4018686B2 (ja) * | 2003-12-10 | 2007-12-05 | キヤノン株式会社 | 情報処理装置および方法並びにプログラム |
JP2005267100A (ja) | 2004-03-17 | 2005-09-29 | Ricoh Co Ltd | ネットワーク制御装置、画像形成装置、画像形成システム、コンピュータプログラム及び記録媒体 |
JP4483650B2 (ja) * | 2005-03-25 | 2010-06-16 | 富士ゼロックス株式会社 | ネットワーク処理装置 |
JP2006279821A (ja) * | 2005-03-30 | 2006-10-12 | Canon Inc | 画像処理装置およびスリープ状態復帰方法およびプログラム |
JP2007052544A (ja) * | 2005-08-16 | 2007-03-01 | Fuji Xerox Co Ltd | 情報処理装置、電力モード切替方法及び電力モード切替プログラム |
JP2007058743A (ja) * | 2005-08-26 | 2007-03-08 | Canon Inc | ネットワークデバイスおよびネットワークデバイスの省電力制御方法 |
US20080195688A1 (en) * | 2007-02-14 | 2008-08-14 | Hideyuki Watanabe | Information processing apparatus, information processing method, and computer program product |
JP2008305209A (ja) | 2007-06-07 | 2008-12-18 | Ricoh Co Ltd | 情報処理装置と情報処理方法とプログラムとコンピュータ読み取り可能な記録媒体 |
-
2008
- 2008-07-14 JP JP2008182464A patent/JP5417755B2/ja not_active Expired - Fee Related
-
2009
- 2009-04-22 US US12/428,192 patent/US8368929B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US8368929B2 (en) | 2013-02-05 |
US20100007914A1 (en) | 2010-01-14 |
JP2009119849A (ja) | 2009-06-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5417755B2 (ja) | 情報処理装置、情報処理方法及びプログラム | |
JP5121442B2 (ja) | 情報処理装置、情報処理方法およびプログラム | |
US20080195688A1 (en) | Information processing apparatus, information processing method, and computer program product | |
Shang et al. | Challenges in IoT networking via TCP/IP architecture | |
JP5037376B2 (ja) | 情報処理装置、電力モード制御方法、電力モード制御プログラム、及び記録媒体 | |
KR101798016B1 (ko) | 데이터 처리 방법 및 장치 | |
EP2362587B1 (en) | Method and apparatus for realizing ARP request broadcasting limitation | |
US8054839B2 (en) | Apparatus and method of processing stateful address auto-configuration protocol in IPv6 network | |
JP2007299368A (ja) | ネットワークに接続されたデバイスの監視装置および監視方法 | |
JP2008028914A (ja) | 通信負荷低減装置、通信負荷低減方法、及びプログラム | |
EP2888863B1 (en) | Method and apparatus for configuring dhcp client | |
US8601271B2 (en) | Method and system for power management using ICMPV6 options | |
US8438390B2 (en) | Method and system for using neighbor discovery unspecified solicitation to obtain link local address | |
JP3812285B2 (ja) | ネットワークシステム及びネットワーク機器 | |
JP4876810B2 (ja) | 情報処理装置および節電プログラム | |
US8085771B2 (en) | Information processing apparatus, image processing apparatus, control method, and storage medium | |
US20130083347A1 (en) | Method and system for physically securing a host device | |
US10871927B2 (en) | Image forming apparatus | |
US8516141B2 (en) | Method and system for modifying and/or changing a MAC ID utilizing an IPv6 network connection | |
US20120287928A1 (en) | Communication apparatus and method of controlling same, and storage medium | |
JP7031566B2 (ja) | 画像形成装置 | |
JP2006197051A (ja) | ネットワーク通信制御装置およびネットワーク通信制御方法 | |
JP2012212464A (ja) | 情報処理装置、電力モード制御方法、電力モード制御プログラム、及び記録媒体 | |
JP7197986B2 (ja) | 情報処理装置、情報処理方法 | |
JP4796413B2 (ja) | ネットワーク機器 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110408 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121024 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20121030 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121227 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130517 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130702 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20131022 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131104 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 5417755 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
LAPS | Cancellation because of no payment of annual fees |