(57)【要約】  【課題】ＨＴＴＰサーバ又はＨＴＴＰクライアントがソケットからＨＴＴＰヘッダを受信する際に、ＨＴＴＰメインタスクとソケットタスクの間で発生するタスクディスパッチの回数を大幅に削減し、ＨＴＴＰヘッダの受信処理の高速化、及びＨＴＴＰメッセージボディの高速データ転送を目的とする。  【解決手段】ＨＴＴＰヘッダのデータを４バイトずつ受信する第１の受信ステップ２０１と、その受信データの４バイト目を検査し、次の１または４バイトを受信するかを判定する第１の検査判定ステップ２０４と、次の１バイトを受信する第２の受信ステップ２０６と、受信した次の１バイトを検査し、その次の４バイトを受信するか、前記４バイト目より前のバイトを検査するかを判定する第２の検査判定ステップ２０９と、前記１バイトの前のバイトも含めて所定の終了パターンと比較し、ＨＴＴＰヘッダの終了を判断する第１のヘッダ受信完了判断ステップ２０７とを備えた。【選択図】図２
2006079182.tif 000002
【特許請求の範囲】
【請求項１】
ＨＴＴＰヘッダのデータを４バイトずつ受信する第１の受信ステップと、
前記第１の受信ステップで受信したデータの４番目のバイトの値を検査し、次の１または２バイトを受信するか、次の４バイトを受信するかを判定する第１の検査判定ステップと、
前記第１の検査判定ステップの結果に基づいて、前記次の１または２バイトを受信する第２の受信ステップと、
前記第２の受信ステップで受信した前記次の１または２バイトを検査し、その１または２バイトの次の４バイトを受信するか、前記４番目のバイトよりも前のバイトを検査するかを判定する第２の検査判定ステップと、
前記１または２バイト、および前記１または２バイトよりも前のバイトの全体について、ＨＴＴＰヘッダの終了を示す所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記１または２バイトでＨＴＴＰヘッダが終了したと判断する第１のヘッダ受信完了判断ステップとを備えた、ＨＴＴＰヘッダの受信方法。
【請求項２】
さらに、前記第１の受信ステップと前記第１の検査判定ステップとの間に、ＨＴＴＰヘッダが終了したと判断する第２のヘッダ受信完了判断ステップを備え、
前記第２のヘッダ受信完了判断ステップは、前記第１の受信ステップで受信した前記４バイトを前記所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記４番目のバイトでＨＴＴＰヘッダが終了したと判断し、前記所定の終了パターンと一致しなかった場合には、前記第１の検査判定ステップに移る、請求項１に記載のＨＴＴＰヘッダの受信方法。
【請求項３】
前記第１の受信ステップは、ＨＴＴＰヘッダの先頭のデータから４バイトずつ受信し、
前記第１の検査判定ステップは、前記４番目のバイトの値が、ＣＲコードまたはＬＦコードであるかを判定し、
前記第２の受信ステップは、前記４番目のバイトの値がＣＲコードまたはＬＦコードであった場合には、ＨＴＴＰヘッダの次の１バイトのデータを受信し、
前記第１のヘッダ受信完了判断ステップは、前記第２の受信ステップで受信した前記次の１バイト、および前記次の１バイトよりも前の３バイトの合計４バイトについて、ＣＲＬＦＣＲＬＦコードパターンと比較し、一致している場合にはＨＴＴＰヘッダが終了したと判断し、
前記第２の検査判定ステップは、前記第１のヘッダ受信完了判断ステップでＨＴＴＰヘッダが終了していないと判断した場合に、前記次の１バイトおよびその前の１バイトの合計２バイトについて、ＣＲＬＦコードパターンおよびＬＦＣＲコードパターンと比較し、いずれのコードパターンにも一致しなかった場合には、前記第１の受信ステップに次の４バイトを受信させ、いずれかのコードパターンに一致した場合には、前記第２の受信ステップに次の１バイトを受信させる、請求項２に記載のＨＴＴＰヘッダの受信方法。
【請求項４】
前記第１の受信ステップは、ＨＴＴＰヘッダの先頭のデータから４バイトずつ受信し、
前記第１の検査判定ステップは、前記４番目のバイトの値が、ＣＲコードまたはＬＦコードであるかを判定し、
前記第２の受信ステップは、前記４番目のバイトの値がＣＲコードであった場合には、ＨＴＴＰヘッダの次の１バイトのデータを受信し、前記４番目のバイトの値がＬＦコードであった場合には、ＨＴＴＰヘッダの次の２バイトのデータを受信し、
前記第１のヘッダ受信完了判断ステップは、前記第２の受信ステップで１バイト受信した場合のその１バイトおよびその１バイトよりも前の３バイトの合計４バイトについて、または、前記第２の受信ステップで２バイト受信した場合のその２バイトおよびその２バイトよりも前の２バイトの合計４バイトについて、ＣＲＬＦＣＲＬＦコードパターンと比較し、一致している場合にはＨＴＴＰヘッダが終了したと判断し、
前記第２の検査判定ステップは、前記第１のヘッダ受信完了判断ステップでＨＴＴＰヘッダが終了していないと判断した場合において、前記第２の受信ステップで１バイト受信したその１バイトがＣＲコード、または２バイト受信した２バイト目がＣＲコードの場合には、前記第２の受信ステップにさらに次の１バイトを受信させ、前記第２の受信ステップで１バイト受信したその１バイトがＬＦコード、または２バイト受信した２バイトがＣＲＬＦコードパターンに一致する場合には、前記第２の受信ステップにさらに次の２バイトを受信させる、請求項２に記載のＨＴＴＰヘッダの受信方法。
【請求項５】
前記第１の受信ステップは、ＨＴＴＰヘッダの先頭のデータから４バイトずつ受信し、
前記第１の検査判定ステップは、前記４番目のバイトの値が、ＣＲコードまたはＬＦコードであるかを判定し、
前記第２の受信ステップは、前記４番目のバイトの値がＣＲコードであった場合には、ＨＴＴＰヘッダの次の１バイトのデータを受信し、
前記第２の検査判定ステップは、前記第１の受信ステップで受信した４バイトのうちの３番目と４番目の２バイト、前記第２の受信ステップで１バイト受信した場合のその１バイトおよびその１バイトの前の１バイトの合計２バイト、前記第２の受信ステップで２バイト受信した場合のその２バイト、のそれぞれについて、ＣＲＬＦコードパターンと比較して一致した場合には、前記第１のヘッダ受信完了判断ステップにＨＴＴＰヘッダの終了を判断させ、
前記第１のヘッダ受信完了判断ステップは、前記第２の検査判定ステップでＣＲＬＦコードパターンに一致した前記２バイトおよびその２バイトの前の２バイトの合計４バイトについて、ＣＲＬＦＣＲＬＦコードパターンと比較し、一致している場合にはＨＴＴＰヘッダが終了したと判断し、一致していない場合には、前記第２の受信ステップにさらに次の２バイトを受信させる、請求項１に記載のＨＴＴＰヘッダの受信方法。
【請求項６】
ＨＴＴＰヘッダのデータを４バイトずつ受信する第１の受信手段と、
前記第１の受信手段で受信したデータの４番目のバイトの値を検査し、次の１または２バイトを受信するか、次の４バイトを受信するかを判定する第１の検査判定手段と、
前記第１の検査判定手段の結果に基づいて、前記次の１または２バイトを受信する第２の受信手段と、
前記第２の受信手段で受信した前記次の１または２バイトを検査し、その１または２バイトの次の４バイトを受信するか、前記４番目のバイトよりも前のバイトを検査するかを判定する第２の検査判定手段と、
前記１または２バイト、および前記１または２バイトよりも前のバイトの全体について、ＨＴＴＰヘッダの終了を示す所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記１または２バイトでＨＴＴＰヘッダが終了したと判断する第１のヘッダ受信完了判断手段とを備えた、ＨＴＴＰサーバ。
【請求項７】
ＨＴＴＰヘッダのデータを４バイトずつ受信する第１の受信手段と、
前記第１の受信手段で受信したデータの４番目のバイトの値を検査し、次の１または２バイトを受信するか、次の４バイトを受信するかを判定する第１の検査判定手段と、
前記第１の検査判定手段の結果に基づいて、前記次の１または２バイトを受信する第２の受信手段と、
前記第２の受信手段で受信した前記次の１または２バイトを検査し、その１または２バイトの次の４バイトを受信するか、前記４番目のバイトよりも前のバイトを検査するかを判定する第２の検査判定手段と、
前記１または２バイト、および前記１または２バイトよりも前のバイトの全体について、ＨＴＴＰヘッダの終了を示す所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記１または２バイトでＨＴＴＰヘッダが終了したと判断する第１のヘッダ受信完了判断手段とを備えた、ＨＴＴＰクライアント。
【請求項８】
請求項１に記載のＨＴＴＰヘッダの受信方法の、ＨＴＴＰヘッダのデータを４バイトずつ受信する前記第１の受信ステップと、前記第１の受信ステップで受信したデータの４番目のバイトの値を検査し、次の１または２バイトを受信するか、次の４バイトを受信するかを判定する前記第１の検査判定ステップと、前記第１の検査判定ステップの結果に基づいて、前記次の１または２バイトを受信する前記第２の受信ステップと、前記第２の受信ステップで受信した前記次の１または２バイトを検査し、その１または２バイトの次の４バイトを受信するか、前記４番目のバイトよりも前のバイトを検査するかを判定する前記第２の検査判定ステップと、前記１または２バイト、および前記１または２バイトよりも前のバイトの全体について、ＨＴＴＰヘッダの終了を示す所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記１または２バイトでＨＴＴＰヘッダが終了したと判断する前記第１のヘッダ受信完了判断ステップとをコンピュータに実行させるためのプログラム。
【請求項９】
請求項８に記載のプログラムを担持した記録媒体であって、コンピュータで利用可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＨＴＴＰサーバ／クライアント機能を有する装置やシステムにおける、ＨＴＴＰヘッダの受信方法、ＨＴＴＰサーバ、およびＨＴＴＰクライアントに関するものである。
【背景技術】
【０００２】
一般的に、マルチタスクＯＳの場合、ＨＴＴＰサーバはＨＴＴＰサーバメインタスクとソケットタスクを備え、ＨＴＴＰクライアントはＨＴＴＰクライアントメインタスクとソケットタスクを備えている。そして、到着したＨＴＴＰメッセージは、ＨＴＴＰサーバメインタスクまたはＨＴＴＰクライアントメインタスクが、ソケットタスクから受信し処理する。
【０００３】
また、従来、ＨＴＴＰサーバ／クライアント機能を有する装置やシステムは、パソコン等のコンピュータが主であり、テキストデータや画像／音声等のバイナリデータを主な転送対象としていた。この転送におけるＨＴＴＰヘッダの一般的な受信処理では、ソケットタスクから制御コード列“ＣＲＬＦＣＲＬＦ”を受信するまで、１バイト単位での受信が繰り返される。
【０００４】
さらにまた、特許文献１に記載されているような、１バイト単位での受信繰り返しと並行して、ＨＴＴＰヘッダの構造解析を行うＨＴＴＰサーバおよびＨＴＴＰクライアントも存在している。
【０００５】
なお、制御コード列“ＣＲＬＦＣＲＬＦ”のＣＲＬＦは改行コードを指し、１６進表記では、ＣＲは０ｘ０Ｄ、ＬＦは０ｘ０Ａである。
【特許文献１】特開２００４−１４５５８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、マルチタスクＯＳの場合、ＨＴＴＰヘッダを受信する時、ＨＴＴＰサーバではＨＴＴＰサーバメインタスクとソケットタスク、ＨＴＴＰクライアントではＨＴＴＰクライアントメインタスクとソケットタスク、それぞれでタスクディスパッチが発生し、このタスクディスパッチ自体に時間を要し、タスクディスパッチの多少がＨＴＴＰヘッダの受信処理時間の長さに直接影響を及ぼすという問題があった。
【０００７】
従来のＨＴＴＰサーバ−ＨＴＴＰクライアント間のデータ転送では、テキストデータや画像／音声等のバイナリデータの転送時間をさほど問題とせず、時間を要しても全データを転送できれば良かった。最近では、ネットワーク機能を搭載したＡＶ機器が出現してきた。しかし、ＡＶ機器がＨＴＴＰサーバ／クライアント機能を搭載していても、従来の非ネットワーク接続の時と同様に映像等を再生できることが要求された場合に、ＨＴＴＰヘッダを１バイト単位で受信してタスクディスパッチが発生するために、ネットワーク経由での映像等の再生において、映像が瞬間的に停止する、再生スピードが遅い等の悪影響を及ぼす場合があった。
【０００８】
また、特許文献１では、１バイト単位でのＨＴＴＰヘッダ受信処理と構文解析を並行して行うため、受信処理の高速化を実現できない。
【０００９】
本発明は、上記従来の課題を解決するために、ＨＴＴＰヘッダの受信処理を高速に行い、ネットワーク経由での映像等の再生に悪影響を及ぼさないＨＴＴＰヘッダの受信方法、ＨＴＴＰサーバ、およびＨＴＴＰクライアントを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決するために、第１の本発明は、
ＨＴＴＰヘッダのデータを４バイトずつ受信する第１の受信ステップと、
前記第１の受信ステップで受信したデータの４番目のバイトの値を検査し、次の１または２バイトを受信するか、次の４バイトを受信するかを判定する第１の検査判定ステップと、
前記第１の検査判定ステップの結果に基づいて、前記次の１または２バイトを受信する第２の受信ステップと、
前記第２の受信ステップで受信した前記次の１または２バイトを検査し、その１または２バイトの次の４バイトを受信するか、前記４番目のバイトよりも前のバイトを検査するかを判定する第２の検査判定ステップと、
前記１または２バイト、および前記１または２バイトよりも前のバイトの全体について、ＨＴＴＰヘッダの終了を示す所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記１または２バイトでＨＴＴＰヘッダが終了したと判断する第１のヘッダ受信完了判断ステップとを備えた、ＨＴＴＰヘッダの受信方法である。
【００１１】
第２の本発明は、
さらに、前記第１の受信ステップと前記第１の検査判定ステップとの間に、ＨＴＴＰヘッダが終了したと判断する第２のヘッダ受信完了判断ステップを備え、
前記第２のヘッダ受信完了判断ステップは、前記第１の受信ステップで受信した前記４バイトを前記所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記４番目のバイトでＨＴＴＰヘッダが終了したと判断し、前記所定の終了パターンと一致しなかった場合には、前記第１の検査判定ステップに移る、第１の本発明のＨＴＴＰヘッダの受信方法である。
【００１２】
第３の本発明は、
前記第１の受信ステップは、ＨＴＴＰヘッダの先頭のデータから４バイトずつ受信し、
前記第１の検査判定ステップは、前記４番目のバイトの値が、ＣＲコードまたはＬＦコードであるかを判定し、
前記第２の受信ステップは、前記４番目のバイトの値がＣＲコードまたはＬＦコードであった場合には、ＨＴＴＰヘッダの次の１バイトのデータを受信し、
前記第１のヘッダ受信完了判断ステップは、前記第２の受信ステップで受信した前記次の１バイト、および前記次の１バイトよりも前の３バイトの合計４バイトについて、ＣＲＬＦＣＲＬＦコードパターンと比較し、一致している場合にはＨＴＴＰヘッダが終了したと判断し、
前記第２の検査判定ステップは、前記第１のヘッダ受信完了判断ステップでＨＴＴＰヘッダが終了していないと判断した場合に、前記次の１バイトおよびその前の１バイトの合計２バイトについて、ＣＲＬＦコードパターンおよびＬＦＣＲコードパターンと比較し、いずれのコードパターンにも一致しなかった場合には、前記第１の受信ステップに次の４バイトを受信させ、いずれかのコードパターンに一致した場合には、前記第２の受信ステップに次の１バイトを受信させる、第２の本発明のＨＴＴＰヘッダの受信方法である。
【００１３】
第４の本発明は、
前記第１の受信ステップは、ＨＴＴＰヘッダの先頭のデータから４バイトずつ受信し、
前記第１の検査判定ステップは、前記４番目のバイトの値が、ＣＲコードまたはＬＦコードであるかを判定し、
前記第２の受信ステップは、前記４番目のバイトの値がＣＲコードであった場合には、ＨＴＴＰヘッダの次の１バイトのデータを受信し、前記４番目のバイトの値がＬＦコードであった場合には、ＨＴＴＰヘッダの次の２バイトのデータを受信し、
前記第１のヘッダ受信完了判断ステップは、前記第２の受信ステップで１バイト受信した場合のその１バイトおよびその１バイトよりも前の３バイトの合計４バイトについて、または、前記第２の受信ステップで２バイト受信した場合のその２バイトおよびその２バイトよりも前の２バイトの合計４バイトについて、ＣＲＬＦＣＲＬＦコードパターンと比較し、一致している場合にはＨＴＴＰヘッダが終了したと判断し、
前記第２の検査判定ステップは、前記第１のヘッダ受信完了判断ステップでＨＴＴＰヘッダが終了していないと判断した場合において、前記第２の受信ステップで１バイト受信したその１バイトがＣＲコード、または２バイト受信した２バイト目がＣＲコードの場合には、前記第２の受信ステップにさらに次の１バイトを受信させ、前記第２の受信ステップで１バイト受信したその１バイトがＬＦコード、または２バイト受信した２バイトがＣＲＬＦコードパターンに一致する場合には、前記第２の受信ステップにさらに次の２バイトを受信させる、第２の本発明のＨＴＴＰヘッダの受信方法である。
【００１４】
第５の本発明は、
前記第１の受信ステップは、ＨＴＴＰヘッダの先頭のデータから４バイトずつ受信し、
前記第１の検査判定ステップは、前記４番目のバイトの値が、ＣＲコードまたはＬＦコードであるかを判定し、
前記第２の受信ステップは、前記４番目のバイトの値がＣＲコードであった場合には、ＨＴＴＰヘッダの次の１バイトのデータを受信し、
前記第２の検査判定ステップは、前記第１の受信ステップで受信した４バイトのうちの３番目と４番目の２バイト、前記第２の受信ステップで１バイト受信した場合のその１バイトおよびその１バイトの前の１バイトの合計２バイト、前記第２の受信ステップで２バイト受信した場合のその２バイト、のそれぞれについて、ＣＲＬＦコードパターンと比較して一致した場合には、前記第１のヘッダ受信完了判断ステップにＨＴＴＰヘッダの終了を判断させ、
前記第１のヘッダ受信完了判断ステップは、前記第２の検査判定ステップでＣＲＬＦコードパターンに一致した前記２バイトおよびその２バイトの前の２バイトの合計４バイトについて、ＣＲＬＦＣＲＬＦコードパターンと比較し、一致している場合にはＨＴＴＰヘッダが終了したと判断し、一致していない場合には、前記第２の受信ステップにさらに次の２バイトを受信させる、第１の本発明のＨＴＴＰヘッダの受信方法である。
【００１５】
第６の本発明は、
ＨＴＴＰヘッダのデータを４バイトずつ受信する第１の受信手段と、
前記第１の受信手段で受信したデータの４番目のバイトの値を検査し、次の１または２バイトを受信するか、次の４バイトを受信するかを判定する第１の検査判定手段と、
前記第１の検査判定手段の結果に基づいて、前記次の１または２バイトを受信する第２の受信手段と、
前記第２の受信手段で受信した前記次の１または２バイトを検査し、その１または２バイトの次の４バイトを受信するか、前記４番目のバイトよりも前のバイトを検査するかを判定する第２の検査判定手段と、
前記１または２バイト、および前記１または２バイトよりも前のバイトの全体について、ＨＴＴＰヘッダの終了を示す所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記１または２バイトでＨＴＴＰヘッダが終了したと判断する第１のヘッダ受信完了判断手段とを備えた、ＨＴＴＰサーバである。
【００１６】
第７の本発明は、
ＨＴＴＰヘッダのデータを４バイトずつ受信する第１の受信手段と、
前記第１の受信手段で受信したデータの４番目のバイトの値を検査し、次の１または２バイトを受信するか、次の４バイトを受信するかを判定する第１の検査判定手段と、
前記第１の検査判定手段の結果に基づいて、前記次の１または２バイトを受信する第２の受信手段と、
前記第２の受信手段で受信した前記次の１または２バイトを検査し、その１または２バイトの次の４バイトを受信するか、前記４番目のバイトよりも前のバイトを検査するかを判定する第２の検査判定手段と、
前記１または２バイト、および前記１または２バイトよりも前のバイトの全体について、ＨＴＴＰヘッダの終了を示す所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記１または２バイトでＨＴＴＰヘッダが終了したと判断する第１のヘッダ受信完了判断手段とを備えた、ＨＴＴＰクライアントである。
【００１７】
第８の本発明は、
第１の本発明のＨＴＴＰヘッダの受信方法の、ＨＴＴＰヘッダのデータを４バイトずつ受信する前記第１の受信ステップと、前記第１の受信ステップで受信したデータの４番目のバイトの値を検査し、次の１または２バイトを受信するか、次の４バイトを受信するかを判定する前記第１の検査判定ステップと、前記第１の検査判定ステップの結果に基づいて、前記次の１または２バイトを受信する前記第２の受信ステップと、前記第２の受信ステップで受信した前記次の１または２バイトを検査し、その１または２バイトの次の４バイトを受信するか、前記４番目のバイトよりも前のバイトを検査するかを判定する前記第２の検査判定ステップと、前記１または２バイト、および前記１または２バイトよりも前のバイトの全体について、ＨＴＴＰヘッダの終了を示す所定の終了パターンと比較し、前記所定の終了パターンと一致した場合には、前記１または２バイトでＨＴＴＰヘッダが終了したと判断する前記第１のヘッダ受信完了判断ステップとをコンピュータに実行させるためのプログラムである。
【００１８】
第９の本発明は、
第８の本発明のプログラムを担持した記録媒体であって、コンピュータで利用可能な記録媒体である。
【発明の効果】
【００１９】
本発明により、ＨＴＴＰヘッダの受信処理を高速に行い、ネットワーク経由での映像等の再生に悪影響を及ぼさないＨＴＴＰヘッダの受信方法、ＨＴＴＰサーバ、およびＨＴＴＰクライアントを提供することができる。
【発明を実施するための最良の形態】
【００２０】
以下に、本発明の実施の形態について、図面を参照しながら説明する。
【００２１】
（実施の形態１）
図１は、本発明の実施の形態１のＨＴＴＰヘッダの受信方法における受信パターンを説明する図である。
【００２２】
まず、図１を用いて、本実施の形態１のＨＴＴＰヘッダの受信方法の原理について説明する。
【００２３】
パターン１からパターン４において、左がＨＴＴＰヘッダの先頭であり、４バイトの制御コード列“ＣＲＬＦＣＲＬＦ”の後にＨＴＴＰメッセージボディが続く。
【００２４】
本実施の形態１では、ＨＴＴＰヘッダの先頭から４バイト単位でＨＴＴＰヘッダを受信していくが、その場合、４バイト単位の受信データに対する制御コード列“ＣＲＬＦＣＲＬＦ”の位置は、ＨＴＴＰヘッダ長に応じて図１のパターン１からパターン４のいずれかの位置となる。
【００２５】
本実施の形態１では、ＨＴＴＰヘッダの先頭から４バイト単位でＨＴＴＰヘッダを受信していき、１バイト単位の受信と組み合わせることにより、制御コード列“ＣＲＬＦＣＲＬＦ”を抽出する。
【００２６】
パターン１は、制御コード列“ＣＲＬＦＣＲＬＦ”の４バイト全てが、４バイト単位の受信で得られるパターンである。
【００２７】
パターン２は、制御コード列“ＣＲＬＦＣＲＬＦ”の１バイト目は４バイト単位の受信で得られ、２バイト目から４バイト目は１バイト単位の受信で取得するパターンである。
【００２８】
パターン３は、制御コード列“ＣＲＬＦＣＲＬＦ”の１バイト目と２バイト目は４バイト単位の受信で得られ、３バイト目と４バイト目は１バイト単位の受信で取得するパターンである。
【００２９】
パターン４は、制御コード列“ＣＲＬＦＣＲＬＦ”の１バイト目から３バイト目は４バイト単位の受信で得られ、４バイト目は１バイト単位の受信で取得するパターンである。
【００３０】
次に、図２〜図４を用いて、本実施の形態１のＨＴＴＰヘッダの受信方法について説明する。
【００３１】
図２は、本実施の形態１のＨＴＴＰサーバ（又はＨＴＴＰクライアント）のＨＴＴＰサーバメインタスク（又はＨＴＴＰクライアントメインタスク）における、ＨＴＴＰヘッダの受信処理を示すフローチャートである。ステップ２０１の４バイト受信処理、及び、ステップ２０６の１バイト受信処理において、タスクディスパッチが発生し、ソケットタスクでの処理が実行される。
【００３２】
図３は、ＨＴＴＰサーバ（又はＨＴＴＰクライアント）のソケットタスクにおける４バイト受信処理を示すフローチャートである。ソケットタスクは、タスクディスパッチで起床し（ステップ３０１）、ＨＴＴＰヘッダを４バイト受信し（ステップ３０２）、タスクディスパッチでスリープする（ステップ３０３）。
【００３３】
図４は、ＨＴＴＰサーバ（又はＨＴＴＰクライアント）のソケットタスクにおける１バイト受信処理を示すフローチャートである。ソケットタスクは、タスクディスパッチで起床し（ステップ４０１）、ＨＴＴＰヘッダを１バイト受信し（ステップ４０２）、タスクディスパッチでスリープする（ステップ４０３）。
【００３４】
以下、図２を用いて、ＨＴＴＰヘッダの受信処理について具体的に説明する。
【００３５】
まず、ＨＴＴＰサーバ（又はＨＴＴＰクライアント）は、ＨＴＴＰヘッダを４バイト受信する（ステップ２０１）。
【００３６】
受信した４バイトの値を制御コード列“ＣＲＬＦＣＲＬＦ”と比較する（ステップ２０２）。これらを比較した結果（ステップ２０３）、受信した４バイトの値が制御コード列“ＣＲＬＦＣＲＬＦ”と一致した時はＨＴＴＰヘッダ受信を完了する。
【００３７】
ステップ２０３において、受信した４バイトの値が制御コード列“ＣＲＬＦＣＲＬＦ”と一致しなかった時は、４バイト目の値を制御コード“ＣＲ”及び制御コード“ＬＦ”と比較する（ステップ２０４）。
【００３８】
これらを比較した結果（ステップ２０５）、４バイト目の値が制御コード“ＣＲ”又は制御コード“ＬＦ”のいずれかに一致した時は、ＨＴＴＰヘッダの次の１バイトを受信する（ステップ２０６）。
【００３９】
ステップ２０５において、４バイト目の値が制御コード“ＣＲ”及び制御コード“ＬＦ”のいずれにも一致しなかった時は、ステップ２０１へ戻り、ＨＴＴＰヘッダの次の４バイトを受信する。
【００４０】
ステップ２０６においてＨＴＴＰヘッダの次の１バイトを受信した後、その１バイトを既に受信済のＨＴＴＰヘッダの直前の３バイトに結合した４バイトの値を、制御コード列“ＣＲＬＦＣＲＬＦ”と比較する（ステップ２０７）。これらを比較した結果（ステップ２０８）、その４バイトの値が制御コード列“ＣＲＬＦＣＲＬＦ”と一致した時はＨＴＴＰヘッダ受信を完了する。
【００４１】
ステップ２０８において、その４バイトの値が制御コード列“ＣＲＬＦＣＲＬＦ”と一致しなかった時は、ステップ２０６において今回受信した１バイトの値を制御コード“ＣＲ”及び制御コード“ＬＦ”と比較する（ステップ２０９）。
【００４２】
これらを比較した結果（ステップ２１０）、今回受信した１バイトの値が制御コード“ＣＲ”及び制御コード“ＬＦ”のいずれにも一致しなかった時は、ステップ２０１へ戻り、ＨＴＴＰヘッダの次の４バイトを受信する。
【００４３】
ステップ２１０において、今回受信した１バイトの値が制御コード“ＣＲ”又は制御コード“ＬＦ”のいずれかに一致した時は、既に受信済のＨＴＴＰヘッダの直前の１バイトと今回受信した１バイトを結合した２バイトの値を、制御コード列“ＣＲＬＦ”及び制御コード列“ＬＦＣＲ”と比較する（ステップ２１１）。
【００４４】
これらを比較した結果（ステップ２１２）、その２バイトの値が制御コード列“ＣＲＬＦ”又は制御コード列“ＬＦＣＲ”のいずれかに一致した時は、ステップ２０６へ戻り、さらにＨＴＴＰヘッダの次の１バイトを受信する。
【００４５】
一方、ステップ２１２において、その２バイトの値が制御コード列“ＣＲＬＦ”及び制御コード列“ＬＦＣＲ”のいずれにも一致しなかった時は、ステップ２０１へ戻り、ＨＴＴＰヘッダの次の４バイトを受信する。
【００４６】
なお、ステップ２０１が、本発明の第１の受信ステップの一例である。また、ステップ２０４が、本発明の第１の検査判定ステップの一例である。また、ステップ２０６が、本発明の第２の受信ステップの一例である。また、ステップ２０９および２１１を合わせた処理が、本発明の第２の検査判定ステップの一例である。また、ステップ２０７が、本発明の第１のヘッダ受信完了判断ステップの一例である。また、ステップ２０２が、本発明の第２のヘッダ受信完了判断ステップの一例である。また、制御コード列“ＣＲＬＦＣＲＬＦ”が、本発明の所定の終了パターンの一例である。
【００４７】
図５は、本発明の実施の形態１に関するＨＴＴＰサーバの内部構成図である。図５ではＨＴＴＰサーバのみ示しているが、ＨＴＴＰクライアントも同じ内部構成となる。
【００４８】
ＨＴＴＰサーバ５２は、制御部５３、ソケット５４、ヘッダ受信部５５、比較部５６、データ受信部５７、送信部５８、及びデータ蓄積部５９を備えている。
【００４９】
制御部５３は、ＨＴＴＰサーバ５２全体の動作を制御する。
【００５０】
ソケット５４は、ネットワーク５１を介してデータ送受信を行う。
【００５１】
ヘッダ受信部５５は、ソケット５４からＨＴＴＰヘッダの４バイト又は１バイトを受信する。
【００５２】
比較部５６は、ヘッダ受信部５５がソケット５４から受信しているＨＴＴＰヘッダの値を調べ、制御コード列“ＣＲＬＦＣＲＬＦ”を受信したか否かを判断する。
【００５３】
データ受信部５７は、ソケット５４からＨＴＴＰヘッダ以外のデータを受信する。
【００５４】
送信部５８は、ネットワーク５１へ送信するデータをソケット５４へ送信する。
【００５５】
データ蓄積部５９は、ＨＴＴＰサーバ５２が保持する情報を蓄積する。データ蓄積部５９として、具体的にはＨＤＤが一般的である。
【００５６】
なお、ヘッダ受信部５５が、本発明の、第１の受信手段および第２の受信手段の一例である。また、比較部５６が、本発明の、第１の検査判定手段、第２の検査判定手段および第１のヘッダ受信完了判断手段の一例である。
【００５７】
（実施の形態２）
図６は、本発明の実施の形態２のＨＴＴＰサーバ（又はＨＴＴＰクライアント）のＨＴＴＰサーバメインタスク（又はＨＴＴＰクライアントメインタスク）における、ＨＴＴＰヘッダの受信処理を示すフローチャートである。
【００５８】
本実施の形態２のＨＴＴＰサーバ（又はＨＴＴＰクライアント）の構成は、図５に示す実施の形態１と同じ構成であり、ＨＴＴＰヘッダの受信方法のみが、実施の形態１の場合と異なる。
【００５９】
図６に示すステップ６０１〜６０４の処理は、図２に示すステップ２０１〜２０４の処理と同様であり、ステップ６０５以降の処理が実施の形態１と異なる。以下、本実施の形態２におけるステップ６０４以降の処理について説明する。
【００６０】
ステップ６０３において、受信した４バイトの値が制御コード列“ＣＲＬＦＣＲＬＦ”と一致しなかった時は、４バイト目の値を制御コード“ＣＲ”及び制御コード“ＬＦ”と比較する（ステップ６０４）。
【００６１】
これらを比較した結果（ステップ６０５）、４バイト目の値が制御コード“ＣＲ”及び制御コード“ＬＦ”のいずれにも一致しなかった時は、ステップ６０１へ戻り、ＨＴＴＰヘッダの次の４バイトを受信する。
【００６２】
ステップ６０５において、４バイト目の値が制御コード“ＣＲ”に一致した時は、ＨＴＴＰヘッダの次の１バイトを受信し（ステップ６０６）、その１バイトと既に受信済のＨＴＴＰヘッダの直前の３バイトを結合した４バイトの値を、制御コード列“ＣＲＬＦＣＲＬＦ”と比較する（ステップ６０７）。このステップ６０６および６０７の処理は、図２のステップ２０６および２０７の処理と同様である。
【００６３】
一方、ステップ６０５において、４バイト目の値が制御コード“ＬＦ”に一致した時は、ＨＴＴＰヘッダの次の２バイトを受信する（ステップ６１３）。これは、４バイト目の値が制御コード“ＬＦ”の場合には、次の１バイトを受信して結合しても制御コード列“ＣＲＬＦＣＲＬＦ”と一致することはなく、４バイト目の“ＬＦ”と結合させて制御コード列“ＣＲＬＦＣＲＬＦ”と一致するのは、少なくとも次の２バイトを結合させる場合だからである。
【００６４】
そして、ステップ６１３においてＨＴＴＰヘッダの次の２バイトを受信した後、その２バイトと既に受信済のＨＴＴＰヘッダの直前の２バイトを結合した４バイトの値を、制御コード列“ＣＲＬＦＣＲＬＦ”と比較する（ステップ６１４）。
【００６５】
これらの４バイトの値を比較した結果（ステップ６０８）、その４バイトの値が制御コード列“ＣＲＬＦＣＲＬＦ”と一致した時はＨＴＴＰヘッダ受信を完了する。
【００６６】
ステップ６０８において、その４バイトの値が制御コード列“ＣＲＬＦＣＲＬＦ”と一致しなかった時は、ステップ６０６において今回受信した１バイトの値、またはステップ６１３において今回受信した２バイトのデータの２バイト目の値を、制御コード“ＣＲ”及び制御コード“ＬＦ”と比較する（ステップ６０９）。
【００６７】
これらを比較した結果（ステップ６１０）、“ＣＲ”及び制御コード“ＬＦ”のいずれにも一致しなかった時は、ステップ６０１へ戻り、ＨＴＴＰヘッダの次の４バイトを受信する。
【００６８】
ステップ６１０において、比較した１バイトの値が制御コード“ＣＲ”に一致した時は、さらにＨＴＴＰヘッダの次の１バイトを受信する（ステップ６０６）。
【００６９】
ステップ６１０において、比較した１バイトの値が制御コード“ＬＦ”に一致した時は、ここで比較した１バイトを既に受信済のＨＴＴＰヘッダの直前の１バイトと結合した２バイトの値を、制御コード列“ＣＲＬＦ”と比較する（ステップ６１１）。
【００７０】
これらを比較した結果（ステップ６１２）、“ＣＲＬＦ”に一致した時は、さらにＨＴＴＰヘッダの次の２バイトを受信し（ステップ６１３）、一致しなかった時は、ステップ６０１へ戻り、ＨＴＴＰヘッダの次の４バイトを受信する。
【００７１】
なお、ステップ６０１が、本発明の第１の受信ステップの一例である。また、ステップ６０４が、本発明の第１の検査判定ステップの一例である。また、ステップ６０６および６１３が、本発明の第２の受信ステップの一例である。また、ステップ６０９および６１１を合わせた処理が、本発明の第２の検査判定ステップの一例である。また、ステップ６０７および６１４が、本発明の第１のヘッダ受信完了判断ステップの一例である。また、ステップ６０２が、本発明の第２のヘッダ受信完了判断ステップの一例である。また、制御コード列“ＣＲＬＦＣＲＬＦ”が、本発明の所定の終了パターンの一例である。
【００７２】
上記のように、４バイトのデータ受信時の４バイト目のデータが“ＬＦ”であった場合の処理（ステップ６０５）が、実施の形態１の場合の処理（ステップ２０５）と異なる。
【００７３】
図２に示す実施の形態１の場合には、４バイトのデータ受信時の４バイト目のデータが“ＬＦ”の場合には、次の１バイトでＨＴＴＰヘッダが終了することは無いため、ステップ２０６の受信処理を少なくとも２回行なうことになり、タスクディスパッチ処理も少なくとも２回発生することになる。これに対して、本実施の形態２の場合には、４バイトのデータ受信時の４バイト目のデータが“ＬＦ”の場合には、１回の処理で次の２バイトのデータを受信する（ステップ６１３）ので、実施の形態１では２回必要だったタスクディスパッチ処理が１回で済むことになり、さらに処理時間を削減できる。
【００７４】
また、ステップ６０５では、４バイトのデータ受信時の４バイト目のデータのみを検査して次の処理を判断することとしたが、その前のデータ、つまり４バイトのデータ受信時の２バイト目や３バイト目のデータを検査するようにしてもよい。
【００７５】
例えば、４バイト目のデータが“ＣＲ”であった場合に、２バイト目と３バイト目のデータも検査するようにし、２バイト目と３バイト目を合わせたデータパターンが“ＣＲＬＦ”以外のパターンの場合には、次の３バイト分を受信させるようにしてもよい。このようにすることにより、さらにタスクディスパッチ処理の回数を削減することができる。
【００７６】
（実施の形態３）
図７は、本発明の実施の形態３のＨＴＴＰサーバ（又はＨＴＴＰクライアント）のＨＴＴＰサーバメインタスク（又はＨＴＴＰクライアントメインタスク）における、ＨＴＴＰヘッダの受信処理を示すフローチャートである。
【００７７】
本実施の形態３のＨＴＴＰヘッダの受信処理は、図２に示す実施の形態１では４バイトの受信ごとに行っていた制御コード“ＣＲＬＦＣＲＬＦ”との比較（ステップ６０２）を、行わないようにした点が異なる。
【００７８】
以下に、図７を用いて本実施の形態３のＨＴＴＰヘッダの受信処理方法について説明する。
【００７９】
まず、ＨＴＴＰサーバ（又はＨＴＴＰクライアント）は、ＨＴＴＰヘッダを４バイト受信する（ステップ７０１）。
【００８０】
次に、受信した４バイトのデータの４バイト目の値を、制御コード“ＣＲ”及び制御コード“ＬＦ”と比較する（ステップ７０２）。
【００８１】
これらを比較した結果（ステップ７０３）、４バイト目の値が制御コード“ＣＲ”及び制御コード“ＬＦ”のいずれにも一致しなかった時は、ステップ７０１へ戻り、ＨＴＴＰヘッダの次の４バイトを受信する。
【００８２】
ステップ７０３において、４バイト目の値が制御コード“ＣＲ”の場合は、ＨＴＴＰヘッダの次の１バイトを受信する（ステップ７０４）。
【００８３】
そして、ステップ７０３において４バイト目の値が制御コード“ＣＲ”だった場合には、４バイト目の値と次に受信した１バイトのデータを合わせた２バイトについて、制御コード列“ＣＲＬＦ”と比較する。ステップ７０３において４バイト目の値が制御コード“ＬＦ”だった場合には、ステップ７０１で受信した４バイトのデータの３バイト目と４バイト目の２バイトについて、制御コード列“ＣＲＬＦ”と比較する（ステップ７０５）。
【００８４】
これらの２バイトのデータを制御コード列“ＣＲＬＦ”と比較した結果（ステップ７０６）、一致しなかった時は、ステップ７０１へ戻り、ＨＴＴＰヘッダの次の４バイトを受信する。
【００８５】
ステップ７０６において、比較した２バイトが制御コード列“ＣＲＬＦ”に一致した場合には、さらにその２バイトの直前の２バイトを合わせた４バイトについて、制御コード列“ＣＲＬＦＣＲＬＦ”と比較する（ステップ７０７）。
【００８６】
これらを比較した結果（ステップ７０８）、制御コード列“ＣＲＬＦＣＲＬＦ”と一致した時は、ＨＴＴＰヘッダ受信を完了する。
【００８７】
そして、ステップ７０８において、一致しなかった場合には、ＨＴＴＰヘッダの次の２バイトを受信する（ステップ７０９）。そして、ステップ７０５において、その受信した２バイトと、制御コード列“ＣＲＬＦ”を比較し、図７に示すように上記の処理を繰り返し行う。
【００８８】
なお、ステップ７０１が、本発明の第１の受信ステップの一例である。また、ステップ７０２が、本発明の第１の検査判定ステップの一例である。また、ステップ７０４および７０９が、本発明の第２の受信ステップの一例である。また、ステップ７０５および７０７を合わせた処理が、本発明の第２の検査判定ステップの一例である。また、ステップ７０７が、本発明の第１のヘッダ受信完了判断ステップの一例である。また、制御コード列“ＣＲＬＦＣＲＬＦ”が、本発明の所定の終了パターンの一例である。
【００８９】
実施の形態１および２では、４バイトのデータを受信する（ステップ２０１または６０１）際に、制御コード“ＣＲＬＦＣＲＬＦ”との比較処理（ステップ２０２または６０２）を必ず行なっていたが、本実施の形態３の場合には、４バイトのデータを受信する際のこの比較処理を行なわない。したがって、本実施の形態３では、実施の形態１または２よりも、さらにこの比較処理に要する処理時間分を削減することができる。
【００９０】
また、ステップ７０３では、４バイトのデータ受信時の４バイト目のデータのみを検査して次の処理を判断することとしたが、その前のデータ、つまり４バイトのデータ受信時の２バイト目や３バイト目のデータを検査するようにしてもよい。２バイト目や３バイト目のデータも検査することにより、次に受信するデータのバイト数を１バイトよりも多くでき、タスクディスパッチ処理の回数をさらに削減することができる。
【００９１】
以上に説明したように、本発明のＨＴＴＰヘッダの受信方法によれば、ＨＴＴＰサーバメインタスク（又はＨＴＴＰクライアントメインタスク）とソケットタスクのタスクディスパッチが、大半は４バイト受信毎、一部は１バイトまたは２バイト受信毎で発生するため、従来の常時１バイト受信毎のタスクディスパッチと比べ、タスクディスパッチ回数が約４分の１に削減できる。これにより、ＨＴＴＰヘッダの受信処理を高速化できる。
【００９２】
さらに、ＨＴＴＰメッセージボディの受信開始時刻を従来よりも早め、ＨＴＴＰメッセージボディの転送に要する時間を増加させることができ、映像等の高速データ転送およびリアルタイム再生の信頼性を高めることができる。
【００９３】
また、ソケットからＨＴＴＰサーバメインタスク（又はＨＴＴＰクライアントメインタスク）のバッファへのＨＴＴＰヘッダのデータコピーの大半が１バイト単位から４バイト単位となること、一般的な４バイトデータのコピーに関して「４バイト単位でのコピー時間」＜「１バイト単位でのコピー時間」×４が既知、の２点から、ＨＴＴＰヘッダデータのバッファコピー自体も高速化できる。
【００９４】
加えて、ＣＰＵの処理能力の低い機器におけるＨＴＴＰヘッダの受信処理も高速化できる。
【００９５】
なお、本発明のプログラムは、上述した本発明のＨＴＴＰヘッダの受信方法の、第１の受信ステップ、第１の検査判定ステップ、第２の受信ステップ、第２の検査判定ステップ、第１のヘッダ受信完了判断ステップの動作をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムである。
【００９６】
また、本発明の記録媒体は、上述した本発明のＨＴＴＰヘッダの受信方法の、第１の受信ステップ、第１の検査判定ステップ、第２の受信ステップ、第２の検査判定ステップ、第１のヘッダ受信完了判断ステップの動作をコンピュータにより実行させるためのプログラムを担持した記録媒体であり、コンピュータにより読み取り可能かつ、読み取られた前記プログラムが前記コンピュータと協働して利用される記録媒体である。
【００９７】
また、本発明のプログラムの一利用形態は、コンピュータにより読み取り可能な記録媒体に記録され、コンピュータと協働して動作する態様であっても良い。
【００９８】
また、記録媒体としては、ＲＯＭ等が含まれる。
【００９９】
また、上述した本発明のコンピュータは、ＣＰＵ等の純然たるハードウェアに限らず、ファームウェアや、ＯＳ、更に周辺機器を含むものであっても良い。
【０１００】
なお、以上説明した様に、本発明の構成は、ソフトウェア的に実現しても良いし、ハードウェア的に実現しても良い。
【産業上の利用可能性】
【０１０１】
本発明にかかるＨＴＴＰヘッダの受信方法は、ＨＴＴＰヘッダの受信処理を高速化でき、ＨＴＴＰメッセージボディの受信開始時刻を早め、ＨＴＴＰメッセージボディの転送処理に要する時間を増加させることができるので、映像等の高速データ転送、及び、リアルタイム再生を求められるＨＴＴＰサーバ機能およびＨＴＴＰクライアント機能を搭載する装置およびシステムに対して有用である。
【図面の簡単な説明】
【０１０２】
【図１】本発明の実施の形態１のＨＴＴＰヘッダの受信方法における受信パターンを説明する図
【図２】本発明の実施の形態１のＨＴＴＰサーバ及びＨＴＴＰクライアントにおけるＨＴＴＰヘッダの受信処理を示すフローチャート
【図３】本発明の実施の形態１のソケットタスクにおける４バイト受信処理を示すフローチャート
【図４】本発明の実施の形態１のソケットタスクにおける１バイト受信処理を示すフローチャート
【図５】本発明の実施の形態１のＨＴＴＰサーバの内部構成図
【図６】本発明の実施の形態２のＨＴＴＰサーバ及びＨＴＴＰクライアントにおけるＨＴＴＰヘッダの受信処理を示すフローチャート
【図７】本発明の実施の形態３のＨＴＴＰサーバ及びＨＴＴＰクライアントにおけるＨＴＴＰヘッダの受信処理を示すフローチャート
【符号の説明】
【０１０３】
５１  ネットワーク
５２  ＨＴＴＰサーバ
５３  制御部
５４  ソケット
５５  ヘッダ受信部
５６  比較部
５７  データ受信部
５８  送信部
５９  データ蓄積部
【図１】
2006079182.tif 000003
【図２】
2006079182.tif 000004
【図３】
2006079182.tif 000005
【図４】
2006079182.tif 000006
【図５】
2006079182.tif 000007
【図６】
2006079182.tif 000008
【図７】
2006079182.tif 000009