JP2004507825A - コンテキストを切替えることなくサーバで通信要求を処理する方法及び装置 - Google Patents

Abstract

コンテキストを切替えることなくサーバで通信要求を処理する方法及び装置。アプリケーションプロトコルサブシステム（１０２）及びプロトコルモジュール（１０３）は、サーバのオペレーティングシステムカーネル内に配置される。プロトコルサブシステム（１０２）は、カーネル要求構造の中に、ＨＴＴＰ要求やＦＴＰ要求などのアプリケーションプロトコル要求に関する情報を記憶する「カーネル内」プロトコルスタックを作成する。そしてユーザスペースアプリケーションは、オペレーティングシステムがコンテキストを切替えることなくアプリケーションプロトコル要求に応答する間、実行を続けることができる。このようにして、ネットワーク上で受信したアプリケーションプロトコル要求は、コンテキストの切替えを引き起こすことなくサーバによって処理され、応答される。

Description

【０００１】
（背景技術）
インターネットは、通信リンクを経由して相互に接続される数多くのコンピュータとコンピュータネットワークからなる。通信リンクは、公知の標準的な伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）を使用してデジタル情報をやり取りする。ハイパーテキスト転送プロトコル（ＨＴＴＰ）及びファイル転送プロトコル（ＦＴＰ）などのアプリケーションプロトコルがＴＣＰ／ＩＰの上位で使用される。同様又は同一の伝送プロトコル及びアプリケーションプロトコルも最新のコンピュータによって使用され、イントラネットやローカルエリアネットワーク（ＬＡＮ）などの私設網を経由して通信する。これらのアプリケーションプロトコルによって、サーバコンピュータシステムは情報を遠方のクライアントコンピュータシステムに送信することができる。そして遠方のクライアントコンピュータシステムは、その情報を表示したり、利用することができる。ＨＴＴＰの場合は、情報はいわゆるワールドワイドウェブページの形式で表示されるであろう。
【０００２】
近年における、インターネットの使用及び他の形式のクライアント／サーバ通信の著しい増加は、サーバがますます多くの要求を受信し、ますます多くの接続と応答を処理していることを意味する。そのため、一定の時間内に扱う要求の数に対してサーバが動作する速度が、全体の速度及びインターネットや他のコンピュータ通信システムの性能において非常に重要となってきた。
【０００３】
サーバにインストールされたオペレーティングシステム及びアプリケーションの性能を遅くする一つの処理は、実行のコンテキストを切り替える処理である。実行のコンテキストは単に「コンテキスト」「プロセス」「スレッド」あるいは「タスク」とも呼ばれる。コンテキストは、マルチタスクオペレーティングシステムカーネルの基本単位である。オペレーティングシステムカーネルは、ハードウェアのリソースを扱いオペレーティングシステムの基本的な動作を行うオペレーティングシステムの一部である。現行のオペレーティングシステムカーネルの中には、ＴＣＰ／ＩＰ機能などのいくつかの下位プロトコル機能を有するものがある。いずれの場合においても、コンテキスト切替えは２つ以上の処理の「切替え」であるので、各処理は中央演算処理装置（ＣＰＵ）を使用することができる。
【０００４】
コンテキストの切替えによって行われる有用なアプリケーションワークがないという点において、コンテキストの切替えは意味のないものである。マルチタスキングオペレーティングシステムやこのようなシステムにインストールされたアプリケーション内のいくつかの動作は、コンテキストの切替無しに行うことができる。そのような動作は「原子」動作と呼ばれることが多い。しかしながら、入出力、つまり「Ｉ／Ｏ」、を伴う動作は通常コンテキスト切替えを必要とする。このような動作は媒体装置にアクセスすることを含み、さらに、残念なことにアプリケーションプロトコルを使用してネットワーク上で通信することを含む。
【０００５】
（発明の開示）
本発明によって、ネットワーク上で受信したアプリケーションプロトコル要求がコンテキストの切替えを起こさずにサーバで処理され応答されることが可能となる。本発明は、オペレーティングシステムカーネル内にアプリケーションプロトコルサブシステムとプロトコルモジュールを備えることによってこの機能を可能なものにする。プロトコルサブシステムは、カーネル要求構造の中に、アプリケーションプロトコル要求に関する情報を記憶する「カーネル内」アプリケーションプロトコルスタックを作成する。そして、ユーザスペースアプリケーションは、オペレーティングシステムがコンテキストを切替えることなく前記アプリケーションプロトコル要求に応答する間、実行を続けることができる。
【０００６】
本発明のひとつの実施例によると、サーバはカーネル及びユーザスペースを備えたオペレーティングシステムを有する。前記サーバは、アプリケーションプロトコル要求に対応するユーザスペース要求構造を確立し、前記アプリケーションプロトコル要求に対応するカーネル要求構造を作ることによって受信された前記アプリケーションプロトコル要求に応答する。前記サーバは、前記アプリケーションプロトコル要求に関連してクライアントから受信したデータを用いて前記カーネル要求構造を作成する。前記オペレーティングシステムは、前記ユーザスペースのアプリケーションが実行を続け、前記オペレーティングシステムがコンテキストを切替えることなく前記アプリケーションプロトコル要求に応答できるように前記カーネル要求構造に従って前記ユーザスペース要求構造を更新する。そして前記サーバは、前記アプリケーションプロトコル要求に応答する。ひとたび前記要求が処理されると、前記カーネル要求構造を削除することができる。
【０００７】
ある実施例では、サーバシステムは本発明によるオペレーティングシステムを有し、前記アプリケーションプロトコル要求に対応するユーザスペース要求構造を確立し維持するよう動作可能なユーザスペースを備える。前記サーバシステムはまた、前記ユーザスペースに動作可能に接続されたオペレーティングシステムカーネルを有する。前記カーネルは、前記アプリケーションプロトコル要求に関連してクライアントから受け取ったデータを使用し、前記アプリケーションプロトコル要求に対応するカーネル要求構造を維持するよう動作可能である。前記カーネルはまた、前記オペレーティングシステムがコンテキストを切替えることなく前記アプリケーションプロトコル要求に応答できるように、前記ユーザスペース要求構造を更新できる。
【０００８】
本発明の実施例において、コンピュータプログラムコードは本発明の多くの態様を実行するために使用される。コンピュータプログラムは媒体上に記憶することができる。前記媒体として、ディスケット、テープ、固定ディスクといった磁気媒体や、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭといった光媒体が可能である。前記コンピュータプログラムコードは、半導体装置にも記憶できる。さらに、前記コンピュータプログラムをインターネットや何らかの他の種類のネットワークを経由して供給することもできる。ネットワークに接続されたワークステーション又はコンピュータシステムは一般に、コンピュータプログラム製品の一部として供給される前記コンピュータプログラムコードを作動させる。このコンピュータシステムは、「プログラム実行システム」又は「命令実行システム」とも呼ぶことができる。前記コンピュータシステム及び測定システムと組み合わせた前記コンピュータプログラムコードは、本発明の方法を実行する手段を形成する。
【０００９】
（本発明を実行するための最良の形態）
本発明は典型的に、コンピュータソフトウェアまたはコンピュータプログラム製品において具体化される。説明されるソフトウェアのすべての特徴が、付記された請求項のうちの何れか特定のひとつにおいて請求されている本発明を実施するのに、必要であるというわけではないと理解されるべきである。完全なソフトウェア製品は、むしろ本発明を十分に可能なものとするために説明される。ソフトウェア処理又は方法が示されている又は説明されているこの開示全体にわたって、あるステップが最初に行われている他のステップに依存することが文脈から明確でない場合は、この方法のステップはいかなる順序で行われても又は同時に行われてもよいということも理解されるべきである。
【００１０】
説明される本発明の実施例は、インターネット上でオープンソースとして直接入手可能である「リナックス」として一般に知られるコンピュータオペレーティングシステムに基づいたコンピューティングプラットフォームにおいて実施される。リナックスはまた、リナックスオペレーティングシステムのためのサービスとサポートを提供するさまざまなベンダを通しても入手可能である。これらのベンダの中には、本発明の譲受人であるノースキャロライナ州、リサーチ・トライアングル・パークのレッド・ハット・インコーポレイティッドがある。本発明の一部を実施するパッチ形式のあるコンピュータプログラムコードの例がこの明細書の最後に記載され、その使用については後述する。さらに簡単なあるコードのサンプルがこの明細書中に記載されており、説明される特定の概念を示す。これらの例の全ては、当業者によって容易に理解されるであろう。リナックスの例は例示のためのみに示されていることも理解されるであろう。ここに述べられる発明の概念は、マッキントッシュ（登録商標）、ユニックス（登録商標）及びウィンドウズ（登録商標）に基づくオペレーティングシステムを含む任意のオペレーティングシステムに基づいた、任意のコンピューティングプラットフォームに適応されることができる。
【００１１】
最後に、発明の概念を示すために用いられるいくつかのブロック図及びフローチャートは相互に他を排除するものではないと理解されるべきである。むしろ、各図は説明される特定の概念を示すのに合わせて作成されている。多くの場合、特定の図面に示された要素やステップは別の図面に示された他の要素やステップと共存するが、分かりやすくするためにある要素又はステップのみが示されている。例えば、図１及び図４のブロック図はともにオペレーティングシステムカーネル及びユーザスペース内の要素を示している。実際のソフトウェアにおいては、両図の要素の全てが存在するかもしれない。しかしながら、分かりやすくするために特定の特徴に関連する要素だけが各図に示されている。
【００１２】
図１に戻ると、オペレーティングシステムカーネル１００及びユーザスペース１０１を有するソフトウェアシステムの種々の要素を示すブロック図が示されている。図１によって示される特徴はサーバとして使用されるコンピュータプラットフォーム又は命令実行システムにとって重要であるため、図１のソフトウェアシステムは「サーバシステム」と呼ぶことができる。オペレーティングシステムカーネル、あるいは単に「カーネル」は、ハードウェアリソースを操作し、基本的な機能を提供し、アプリケーションに基本的なプログラミングインタフェースを提供するオペレーティングシステムソフトウェアの一部である。このようなプログラミングインタフェースは、「アプリケーションプログラミングインタフェース」または「ＡＰＩ」と呼ばれることが多い。本発明の本実施例においては、オペレーティングシステムカーネル１００はカーネル内のアプリケーションプロトコルサブシステム１０２を使用することで通信プロトコルスタックを保持する機能を有している。ＨＴＴＰやＦＴＰなどのアプリケーションプロトコルとＴＣＰ／ＩＰなどの下位プロトコルを区別することは重要である。信頼できるプロトコルモジュール１０３もカーネルに備わっており、プロトコルサブシステム１０２にアプリケーションプロトコル情報及び機能を提供する。関与するプロトコルは、ＨＴＴＰ、ＦＴＰ、又はＨＴＴＰを使用する拡張マークアップ言語（ＸＭＬ）及びハイパーテキストマークアップ言語（ＨＴＭＬ）などのいわゆる「メタアプリケーションプロトコル」を含むネットワーク通信に使用される任意の他のアプリケーションプロトコルが可能である。ここに述べられるＨＴＴＰに言及するということは、ＨＴＭＬ及びＸＭＬを含むということであると理解されるべきである。包括的なオペレーティングシステムキャッシュ１０４もカーネルに備わっており、情報のファイルやページを格納するのに使用することができる。最後に、プロトコルオブジェクトキャッシュ１０５もカーネルの中にあり、プロトコルサブシステム１０２に動作可能に接続される。プロトコルオブジェクトキャッシュは、後述するソフトウェアシステムのある特性にとって重要となる。図１に示すようにこの実施例のプロトコルサブシステムは、直接共通ゲートウェイ・インタフェース（ＣＧＩ）及びトランスペアレント・ソケット出力先変更を提供することに注目するべきである。
【００１３】
図１で説明するオペレーティングシステムアーキテクチャ（及び図４を用いて後述するオペレーティングシステムアーキテクチャ）は代表例であることを強調してもしすぎることはない。オペレーティングシステムの中には、あるアプリケーションをカーネルスペースで実行させるものもあれば、ユーザスペースで実行させるものもある。ある環境においては、アプリケーションが両方の場所で作動することも可能で、あるコードはカーネルスペースで作動し別のコードはユーザスペースで作動する。
【００１４】
図１のユーザスペース１０１は、信頼できないモジュールあるいは他のエクセキュータブル１０６を有する。「信頼できる」ソフトウェアモジュール対「信頼できない」ソフトウェアモジュールの意味するものを説明することはこの時点で有益である。当業者には公知であるように、ほとんどの最新のオペレーティングシステムは、ユーザスペースにあるアプリケーション又はソフトウェアモジュールが「サンドボックス」のようなものの中にあるように設計されている。このサンドボックスは、オペレーティングシステムの中のモジュールが壊れないこと又はユーザスペース内で起きることによって悪影響を受けないことを保証している。この概念は、ユーザスペースのモジュールが「信頼できない」とみなされてオペレーティングシステム機能へのアクセスが制限されるようにオペレーティングシステムを設計することで実施される。それに対して、オペレーティングシステムカーネル内のモジュールは「信頼できる」ものであり、オペレーティングシステム機能に完全にアクセスできる。本発明のこの実施例において、上位の通信プロトコルアプリケーションはオペレーティングシステムカーネル内の信頼できるモジュールとして存在できる。これらのカーネル内プロトコルモジュール及びカーネル内プロトコルサブシステムによって、サーバシステムは、オペレーティングシステムがコンテキストを切り替えること無しにアプリケーションプロトコル要求に応答可能となる。全てのオペレーティングシステムが別個のユーザスペースを有するわけではないことに注目するのは重要である。オペレーティングシステムには、オペレーティングシステムカーネルスペース内でアプリケーションを実行するものがある。しかしながら、これらの場合、オペレーティングシステムとアプリケーションの機能的な関係は同じである。オペレーティングシステムはハードウェアを操作し、ＡＰＩを提供し、アプリケーションはＡＰＩを用いて、アプリケーションのタスクを行う。
【００１５】
コンテキストの切替え、又は何らかの他の処理スケジュールの中断を起こさないコンピュータシステムにおける動作は、「原子」動作と呼ばれることが多い。説明したばかりのアーキテクチャでは、通信アプリケーションは、一般にコンテキストの切替えを伴わない「非原子」作業となるであろうものを行うことができる。応答を発生させる必要がある場合、ひとたび応答が既に起こったかのように相応のユーザスペース要求構造が更新されるとカーネルが実行を再開できるようにするメモリ内のカーネル内要求構造に、アプリケーションプロトコル要求についての情報が記憶される。ＨＴＴＰ要求の要求構造の例が下記に示されている。この特定の場合においてユーザ要求構造が示されているが、カーネル要求構造は非常に類似しておりユーザスペース要求構造から容易に得られる。

【００１６】
図２はコンテキストの切替えを伴わずに要求に応答する方法を示すフローチャートである。ステップ２０１で、ユーザスペース要求構造が作成される。ステップ２０２で、サーバシステムとして動作する命令実行システムによる実行がオペレーティングシステムカーネルに入る。ステップ２０３で、新しいカーネル要求構造が作成されて要求を処理する。カーネル要求構造は、通常ネットワーク上に要求をするクライアントシステムから、この要求に関連して受信したデータで埋められる。ステップ２０４で、カーネル要求構造は、ユーザスペース要求構造を埋めることでユーザスペースにコピーされる。この「コピー」は、要求構造の使用済み部分にのみ関連したデータを移動させることで最も効率良く行われる。この場合、要求構造のいわゆる「私設領域」も移動されるであろう。この私設領域は、参考のためにアプリケーションが使用できる不透明なポインタである。ステップ２０５で、実行はユーザスペースに戻り、ユーザスペースアプリケーションは要求が処理されたかのように動作を続ける。ユーザスペース要求構造は、別の要求を処理する必要がある場合は上書きされる。カーネルはしかるべき時に、通常に要求を処理する（分かりやすくするために、このステップは図示されていない）。２０６で、オペレーティングシステムは要求を監視する。要求が完了する、あるいは時間切れになれば、実行はステップ２０７でオペレーティングシステムカーネルに入り、カーネル要求構造は２０８で削除され、メモリリソースをセーブする。要求は完了されないが時間切れが起こらなかった場合は、システムは要求を保持し、その要求のための入出力動作が終了した後に、その要求はユーザスペースへ現在の要求として戻される。「一時停止された」要求は、実行を一時停止させることはない。タスクではなく要求が一時停止されるので、実行はユーザスペースで続くことに気付くべきである。要求を二つ以上の入出力動作で一時停止させることも可能である。
【００１７】
図３は、本発明を具体化するオペレーティングシステムに含まれる他の処理、すなわちアプリケーションプロトコル要求に応答してクライアントアプリケーションに送られる、ＨＴＴＰウェブページなどの応答に静的プロトコルオブジェクトを埋め込む処理を示す。この説明は例としてのみＨＴＴＰウェブページに基づいていることに注目すべきである。ＦＴＰなどの他のアプリケーションプロトコルで本発明を実行することも可能である。本発明のこの実施例において、静的プロトコルオブジェクトは図１のプロトコルオブジェクトキャッシュ１０５に記憶されるが、それらは包括的なオペレーティングシステムキャッシュの中にあってもよい。図３のステップ３０１で、サーバはアプリケーションプロトコル要求を受信し、分析する。ＨＴＴＰ要求の形式のアプリケーションプロトコル要求のサンプルを下に示す。このような要求は通常ふたつの改行文字で終わる。

ステップ３０２でプリアンブルがクライアントに送り返される。プリアンブルとはＨＴＴＰ応答又は返答のヘッダ部分である。ヘッダ部分の例を下に示す。

【００１８】
ステップ３０３で、返答ページの任意の動的部分がサーバ上のメモリバッファ内で作成される。動的部分は、返答の一部分を形成する動的プロトコルオブジェクトからなる。返答はまた静的プロトコルオブジェクトを内部に埋め込むこともできる。ステップ３０４で、動的プロトコルオブジェクトはクライアントアプリケーションに送信される。ステップ３０５で、返答ページの静的部分又は静的プロトコルオブジェクトがプロトコルオブジェクトキャッシュ又は包括的なオペレーティングシステムキャッシュから検索される。ステップ３０６で、静的オブジェクトはクライアントアプリケーションに送信され、ここで静的オブジェクトは完全な返答がクライアントシステムで表示されるように返答の中に埋め込まれる。
【００１９】
図４は本発明のオペレーティングシステムの実施例を示す別のブロック図である。この場合、このブロック図は原子ファイル検索特性の動作を示すように構成されている。図４にはオペレーティングシステム環境の３つの主なセグメント：すなわちファイルシステム４００、ユーザスペース４０１、及びオペレーティングシステムカーネル４０２が含まれている。ファイルシステム４００は、そのファイルシステムスペースにファイルシステムオブジェクト４０３を備えている。ファイルシステムオブジェクトまたは単に「ファイル」は、ファイルシステムスペースの構成要素である。実際には、それらは情報の容器である。通常のファイル、ディレクトリ、及びシンボリックリンクを含む種々の種類のファイルシステムオブジェクトがある。シンボリックリンクは、実際は既存のファイルを指す新しいファイルを作る手段を提供する。シンボリックリンクはソフトリンクとも呼ばれる。リンク付けは分離文字を含む文字列によって行われる。分離記号はリナックス及びユニックス（登録商標）システム上、及びインターネットのＵＲＬシステムでは「／」（スラッシュ）文字であり、それはウィンドウズ（登録商標）システム上の「＼」（逆スラッシュ）文字である。
【００２０】
ファイルシステムオブジェクト名又はファイル名は、例えば、「ｈｏｍｅｗｏｒｋ．ｄｏｃ」のような分離文字を含まない文字列であることに注目するべきである。各ファイルシステムオブジェクトは、ファイルシステムオブジェクト名を持つ。しかしながらファイルシステムオブジェクトパス、すなわち「ファイルパス」は、通常は分離文字で始まり、ファイルの位置を示すパスの種々の部分を特定する文字列である。いくつかのシステムでは、このファイルパスがディレクトリパス又はフォルダパスとも呼ばれ、例えば「／ｈｏｍｅ／ｊｏｅ／ｄｏｃｓ／ｈｏｍｅｗｏｒｋ．ｄｏｃ」などとなる。
【００２１】
図４のファイルシステムはまた、ファイルシステムネームスペース４０４を有する。ファイルシステムネームスペースは、システム内の全てのファイルパスを参照する。全てのファイルのパスは、典型的にディレクトリの形式でファイルシステム装置に記憶される。図４に示されたユーザスペース４０１では、アプリケーション４０５が典型的に備わっている。これらのアプリケーションは、ファイルシステム４００内に保持されているファイルシステムオブジェクト４０３を利用する。未使用のファイルを使用するために、アプリケーション及びオペレーティングシステムはファイルシステムネームスペース動作を行う。このような動作は、例えばファイルを開く、ファイルを読む、ファイルに書き込む、ファイル名を変える、又はファイルをディレクトリ間で移動させるために行われる。他の公知のファイルシステムネームスペース動作もある。この開示のために、これらのファイルシステムネームスペース動作はいずれも総称して「ファイルを開く」、「ファイルオープン要求」を処理する、ファイル操作を行う、などと呼ばれる。従来の技術においては、アプリケーションが「／ｈｏｍｅ／ｊｏｅ／ｄｏｃｓ／ｈｏｍｅｗｏｒｋ．ｄｏｃ」ファイルの最初の１０００バイトを読みたい場合、アプリケーションは下記のＣ言語の例に示されるのと同様のコンピュータプログラムコードを有するであろう。

これらの３つのシステムコールを行った後、オペレーティングシステムカーネルはメモリバッファ「ｂｕｆ」にファイルの最初の１０００バイトを入れるであろう。
【００２２】
オペレーティングシステムカーネルは、ファイルシステムネームスペースキャッシュ４０６を有する。パスがいったんファイルシステムネームスペースキャッシュに記憶されると、上に示した「オープン」システムコールは内部でファイルシステムネームスペースキャッシュにアクセスし、ファイルへのアクセスの速度を上げる。ファイルシステムネームスペースキャッシュは、「デントリキャッシュ（ｄｅｎｔｒｙ ｃａｃｈｅ）」と呼ばれることもある。ネームスペースキャッシュはファイルのコンテンツを格納しないことに注意すべきである。このネームスペースキャッシュはファイルの属性を格納してもよいであろう。ファイルコンテンツは、公知であり、分かりやすくするために図４からは省いた「ページキャッシュ」と呼ばれることの多い、図１で示した包括的なキャッシュなどの、別個のデータ構造に格納される。
【００２３】
上記のような従来の技術では、カーネルは、時間とリソースについてどれだけ要しようとファイルに到達するであろう、そしてファイル名を有するファイルパスがネームスペースキャッシュに既に存在したか否かはアプリケーションにとってトランスペアレントである。もしそうでなければ、カーネルはディスクからファイルパスの詳細を読み込み、入出力が終了するまでそのアプリケーションに関連した処理は一時停止されてコンテキストの切替えが起こり、重大な性能上の支障を引き起こす。
【００２４】
説明したばかりの従来の技術とは異なり、図４のシステムは、本発明のこの実施例による原子ファイル検索を実行する原子検索動作４０７を備えている。原子ファイル検索によってアプリケーション４０５は、ファイルが既にネームスペースキャッシュに格納されているか否かを検出することができる。以下のコードは、その特性が実際にはどのように使用されるかを示す。

「Ｏ＿ＡＴＯＭＩＣＬＯＯＫＵＰ」フラグ及び新しい「−ＥＷＯＵＬＤＢＬＯＣＫＩＯ」はオープンシステムコールのためのコードを返すことに注目するべきである。ファイルパスがまだ格納されていないことがわかると、アプリケーションは、ファイルのオープンをアプリケーション開発者によって適当であると判断されるような別の処理へ戻すか、転送することができる。この処理はブロッキングポイント処理を行う処理となる場合もある。
【００２５】
ブロッキングポイント処理は図４のユーザスペースの４０８に、あるい図４のはカーネルの４０９に備えることができる。「ブロッキングポイント」とは、検索によって、可能性のあるコンテキスト切替えが起こるであろうポイントである。「ブロッキングポイントの処理」には、性能を改善するようにファイルのオープンを管理できる別のプロセス／スレッドにこの検索を返すことを伴う。
【００２６】
図５は、原子検索動作の一例をフローチャートの形式で示す。ステップ５０１で、アプリケーションは、文字列によって示される開かれるべきファイル名を決める。５０２で、オペレーティングシステムに対してファイルオープン要求がなされる。ステップ５００で、オペレーティングシステムカーネルはこの要求を受信し、原子的にファイルを開くことを試みる。原子オープンを試みるために、カーネルはファイルシステムネームスペースキャッシュに適当なファイルパスがないか調べる。ステップ５０３は、このようなファイルの存在の欠如などのエラーについて調べる決定ポイントである。この処理は、従来技術と同じ方法で行われる。エラーがある場合、５０４のエラー処理ルーチンによって処理される。エラーがない場合、処理は続く。オペレーティングシステムカーネルは、ステップ５０５で、パスがファイルシステムネームスペースキャッシュに記憶されたためファイルが原子的に開かれたか又は開かれているかについてアプリケーションに通知する。ファイルが原子的に開かれた場合、そのファイルはステップ５０６で使用される。原子的に開かれなかった場合、原子的オープンがステップ５０５で不可能であったという事実がアプリケーションに通知されているので、可能なブロッキングポイントがステップ５０７で処理される。
【００２７】
この実施例では、アプリケーションはファイルパスが格納されているかどうかについての問い合わせを送信しないことに注目するべきである。アプリケーションは単に、オペレーティングシステムカーネルに対してファイルを原子的に開きたいということを通知するだけである。ファイルパスが格納されているためカーネルが応じることができる場合、ファイルは開かれ、処理がアプリケーションに戻される。ファイルパスが格納されていない場合、そのときファイルは開かれず、−ＥＷＯＵＬＤＢＬＯＣＫＩＯはアプリケーションに戻される。この特徴についてのここでの記述に関して、「開かれた」「開かれるであろう」「開かれている」などの用語が区別なく使用される。同様に、「行われた」「行われている」「行われるであろう」などの、ファイル操作に関する用語が区別なく使用される。「行われる」などが区別なく使用される。キャッシュの検査、ファイルのオープン、およびオペレーティングシステムカーネルからアプリケーションへの通知の厳密なタイミングに関係なく、本発明の動作は同じである。
【００２８】
上述のオペレーティングシステムアーキテクチャには多くの変形があるが、そのいずれも原子検索動作を有することができる。例えば、ファイルシステム装置は、オペレーティングシステムカーネルを保持しているコンピュータシステムに備わる必要は無く、代わりにネットワーク上でアクセスされてもよい。この場合、ファイルシステムネームスペースは、ネットワーク接続されたファイルシステム装置とともに設置されるか、オペレーティングシステムカーネルを保持しているシステム上に位置するか、両方の場所に分配されるかである。全てのオペレーティングシステム環境が別個の保護領域としてユーザスペースを有するわけではないことに注意することも重要である。例えば組み込まれたプロセッサとともに通常使用されるものなどいくつかのオペレーティングシステムでは、アプリケーションがオペレーティングシステムカーネル内で保持され実行される。この場合でも、オペレーティングシステムはアプリケーションにＡＰＩを提供し、アプリケーションがユーザスペースの中で作動しているのと全く同じようにオペレーティングシステムはＡＰＩを介してアプリケーションと通信する。
【００２９】
原子検索特性を実行するコードを示すソースコード一覧の一例が、請求項の前のこの明細書の最後に記載される。このソースコード一覧は「ソースコード例」というタイトルが付けられている。ソースコードは公知の差分パッチ形式のものである。そのソースコードは、インターネット上で、また本出願の譲受人であるレッド・ハット・インコーポレイティッドなどインターネットのサポートを提供する会社から取得できるオープンソースオペレーティングシステムであるリナッックスオペレーティングシステムの公的に入手可能なバージョン２．４．２にパッチをあてる。
【００３０】
先に述べたように、いくつかの実施例では、本発明はパーソナルコンピュータやワークステーションなどのプログラム可能なコンピュータシステム又は命令実行システム、または他のマイクロプロセッサによるプラットフォーム上で作動するコンピュータプログラムコードによって実行される。図６はこのようにして本発明を実行しているコンピュータシステムのさらなる詳細を示す。システムバス６０１は主な構成要素を相互接続する。システムは、このシステムのための中央演算処理装置（ＣＰＵ）として機能するマイクロプロセッサ６０２によって制御される。システムメモリ６０５は典型的に、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）などの多数の種類のメモリやメモリ領域に分けられる。システムメモリはまた、基本入出力システム（ＢＩＯＳ）を有してもよい。複数の一般的な入出力（Ｉ／Ｏ）アダプタ又は装置６０６が存在する。分かりやすくするために、３つのみを図示している。これらは、固定ディスクドライブ６０７、ディスケットドライブ６０８、ネットワーク６１０、及びディスプレイ６０９を含む種々の装置に接続している。本発明の機能を実行するコンピュータプログラムコード命令は、固定ディスク６０７に記憶されている。システムが作動している時、命令は部分的にメモリ６０５にロードされ、マイクロプロセッサ６０２によって実行される。入出力装置のひとつは、随意に、インターネットとすることができるネットワーク６１０への接続のためのネットワークアダプタまたはモデムである。図６のシステムは例示的な一例としての意味を持つだけであることに気付くべきである。多くの種類の汎用コンピュータシステムが入手可能で、使用することができる。
【００３１】
本発明の要素は、（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）コンピュータプログラムコードとしてハードウェア及び／又はソフトウェアにおいて具体化されてもよい。さらに、本発明は、図６に示すような命令実行システムによって使用される、又はこのシステムと関連して使用される媒体に組み込まれた、コンピュータ使用可能な又はコンピュータ可読のプログラムコードを有するコンピュータ使用可能な又はコンピュータ可読の記憶媒体上のコンピュータプログラム製品の形を取ってもよい。このような媒体が図６に図式的に示されていて、ディスケットドライブを表している。コンピュータ使用可能な又はコンピュータ可読の媒体は、命令実行システムによって使用される、又はこのシステムと関連して使用されるプログラムを有する、記憶する、通信する、または伝送できる任意の媒体とすることができる。コンピュータ使用可能な又はコンピュータ可読の媒体は、例えば、電子システム、磁気システム、光システム、電磁気システム、赤外線システム、又は半導体システムである。媒体はまた単に、コンピュータプログラム製品がインターネットなどのネットワークを通じて「ダウンロードされる」場合に検索される情報のストリームであってもよい。コンピュータ使用可能な又はコンピュータ可読の媒体は紙であってもよいし、プログラムが印刷される他の適切な媒体であってもよいことに注目すべきである。
【００３２】
この明細書に述べられた特徴を実行する差分パッチ形式のソースコードはｗｗｗ．ｒｅｄｈａｔ．ｃｏｍ／〜ｍｉｎｇｏ／ＴＵＸ／において、この出願の出願日現在で公的に入手可能である。本発明を実現するソフトウェアシステムのための完全なソースコードも、この出願の譲受人であるレッド・ハット・インコーポレイティッドからこの出願の出願日現在、取得可能である。上記インターネットアドレスにあるソースコードは、インターネット上において、また本出願の譲受人であるレッド・ハット・インコーポレイティッドなどのインターネットサポートを提供する会社から取得可能なオープンソースオペレーティングシステムであるリナックスオペレーティングシステムのバージョンにパッチをあてるためのものである。このコードは、公知のいわゆる「ａｃ４」パッチによって既にパッチされたリナックスオペレーティングシステムのバージョン２．４．５にパッチをあてるためのものである。
【００３３】
リナックスのバージョン２．４．５は、いろいろある中でも特に、ｗｗｗ．ｋｅｒｎｅｌ．ｏｒｇ／ｐｕｂ／ｌｉｎｕｘ／ｋｅｒｎｅｌ／ｖ２．４／ｌｉｎｕｘ−２．４．５．ｔａｒ．ｇｚ．で入手可能である。上記公知のａｃ４パッチは、いろいろある中でも特に、ｗｗｗ．ｋｅｒｎｅｌ．ｏｒｇ／ｐｕｂ／ｌｉｎｕｘ／ｋｅｒｎｅｌ／ｐｅｏｐｌｅ／ａｌａｎ／２．４／ｐａｔｃｈ−２．４．５−ａｃ４．ｇｚ．で入手可能である。
【００３４】
発明の特定の実施例がここに述べられている。コンピュータ技術の当業者なら、本発明が他の環境の中では他のアプリケーションを有することを速やかに認識するであろう。事実、多くの実施例と実施が可能である。本発明の請求項は、本発明の範囲を上述の特定の実施例に限定することを意図したものでは決してない。
ソースコード例

【図面の簡単な説明】
【図１】本発明の実施例を実行するソフトウェアのいくつかの特徴を示すブロック図である。
【図２】本発明の一つの実施例を実行するソフトウェアによって行われる方法を示すフローチャートである。
【図３】本発明の実施例を実行するソフトウェアによって行われる方法を示す別のフローチャートである。
【図４】本発明の実施例を実行するソフトウェアのいくつかの特徴を示すブロック図である。
【図５】本発明の一つの実施例を実行するソフトウェアによって行われる方法を示すフローチャートである。
【図６】本発明の実施例を実行しているコンピュータシステムのブロック図である。

Claims (20)

1. アプリケーションプロトコル要求に応答する方法であって、
   前記アプリケーションプロトコル要求を受信するステップと、
   前記アプリケーションプロトコル要求に対応するユーザスペース要求構造を確立する（２０１）ステップと、
   前記アプリケーションプロトコル要求に関連してクライアントシステムから受信したデータを使用して、前記アプリケーションプロトコル要求に対応するカーネル要求構造を作成する（２０３）ステップと、
   ユーザスペースのアプリケーションが実行を続行し、オペレーティングシステムがコンテキストを切替えることなく前記アプリケーションプロトコル要求に応答できるように、前記カーネル要求構造に従って前記ユーザスペース要求構造を更新する（２０４）ステップと、
   前記アプリケーションプロトコル要求に応答するステップとを、備えたことを特徴とする方法。
2. 請求項１に記載の方法であって、
   前記アプリケーションプロトコル要求に応答した後、前記カーネル要求構造を削除するステップをさらに備えたことを特徴とする方法。
3. 請求項１に記載の方法において、
   前記アプリケーションプロトコル要求及び前記アプリケーションプロトコル要求に対する任意の応答は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従ってフォーマットされることを特徴とする方法。
4. 請求項２に記載の方法において、
   前記アプリケーションプロトコル要求及び前記アプリケーションプロトコル要求に対する任意の応答は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従ってフォーマットされることを特徴とする方法。
5. 請求項１に記載の方法において、
   前記アプリケーションプロトコル要求及び前記アプリケーションプロトコル要求に対する任意の応答は、ファイル転送プロトコル（ＦＴＰ）に従ってフォーマットされることを特徴とする方法。
6. 請求項２に記載の方法において、
   前記アプリケーションプロトコル要求及び前記アプリケーションプロトコル要求に対する任意の応答は、ファイル転送プロトコル（ＦＴＰ）に従ってフォーマットされることを特徴とする方法。
7. カーネル及びユーザスペースを有するオペレーティングシステムを備えるサーバがアプリケーションプロトコル要求に応答可能とするコンピュータプログラムコードが内部に組み込まれたコンピュータプログラム製品であって、前記コンピュータプログラムコードは、
   前記アプリケーションプロトコル要求を受信するための命令と、
   前記アプリケーションプロトコル要求に対応するユーザスペース要求構造を確立するための命令と、
   前記アプリケーションプロトコル要求に関連してクライアントシステムから受信したデータを使用して、前記アプリケーションプロトコル要求に対応するカーネル要求構造を作成するための命令と、
   前記ユーザスペースのアプリケーションが実行を続行し、前記オペレーティングシステムがコンテキストを切替えることなく前記アプリケーションプロトコル要求に応答できるように前記カーネル要求構造に従って前記ユーザスペース要求構造を更新するための命令と、
   前記アプリケーションプロトコル要求に応答するための命令と、
   前記カーネル要求構造を削除するための命令とを、備えたことを特徴とするコンピュータプログラム製品。
8. 請求項７に記載のコンピュータプログラム製品において、
   前記コンピュータプログラムコードは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を実行するための命令をさらに備えたことを特徴とするコンピュータプログラム製品。
9. 請求項７に記載のコンピュータプログラム製品において、
   前記コンピュータプログラムコードは、ファイル転送プロトコル（ＦＴＰ）を実行するための命令をさらに備えたことを特徴とするコンピュータプログラム製品。
10. 請求項８に記載のコンピュータプログラム製品において、
    前記コンピュータプログラムコードは、ファイル転送プロトコル（ＦＴＰ）を実行するための命令をさらに備えたことを特徴とするコンピュータプログラム製品。
11. カーネル及びユーザスペースを有するオペレーティングシステムを備え、アプリケーションプロトコル要求に応答するよう動作可能な装置であって、
    前記アプリケーションプロトコル要求を受信する手段と、
    前記アプリケーションプロトコル要求に対応するユーザスペース要求構造を確立する手段と、
    前記アプリケーションプロトコル要求に関連してクライアントシステムから受信したデータを使用して、前記アプリケーションプロトコル要求に対応するカーネル要求構造を作成する手段と、
    前記ユーザスペースのアプリケーションが実行を続行し、前記オペレーティングシステムがコンテキストを切替えることなく前記アプリケーションプロトコル要求に応答できるように前記カーネル要求構造に従って前記ユーザスペース要求構造を更新する手段と、
    前記アプリケーションプロトコル要求に応答する手段と、
    前記カーネル要求構造を削除する手段とを、備えたことを特徴とする装置。
12. オペレーティングシステムを備え、アプリケーションプロトコル要求に応答するよう動作可能なサーバシステムであって、
    前記アプリケーションプロトコル要求に対応するユーザスペース要求構造を確立し保持するよう動作可能なユーザスペース（１０１）と、
    前記アプリケーションプロトコル要求に関連してクライアントシステムから受信したデータを使用して、前記アプリケーションプロトコル要求に対応するカーネル要求構造を保持し、前記オペレーティングシステムがコンテキストを切替えることなく前記アプリケーションプロトコル要求に応答できるように前記ユーザスペース要求構造を更新するよう動作可能な、前記ユーザスペースに接続されたオペレーティングシステムカーネル（１００）とを、備えたことを特徴とするサーバシステム。
13. 請求項１２に記載のサーバシステムにおいて、前記オペレーティングシステムカーネルは、
    少なくとも一つのプロトコルモジュール（１０３）と、
    前記ユーザスペース及び前記少なくとも一つのプロトコルモジュールに動作可能に接続され、少なくとも部分的に前記オペレーティングシステムカーネルが前記カーネル要求構造を保持することを可能とするプロトコルサブシステム（１０２）とを、さらに備えたことを特徴とするサーバシステム。
14. 請求項１３に記載のサーバシステムにおいて、
    前記少なくとも一つのプロトコルモジュールは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）モジュールをさらに備えたことを特徴とするサーバシステム。
15. 請求項１３に記載のサーバシステムにおいて、
    前記少なくとも一つのプロトコルモジュールは、ファイル転送プロトコル（ＦＴＰ）モジュールをさらに備えたことを特徴とするサーバシステム。
16. 請求項１４に記載のサーバシステムにおいて、
    前記少なくとも一つのプロトコルモジュールは、ファイル転送プロトコル（ＦＴＰ）モジュールをさらに備えたことを特徴とするサーバシステム。
17. カーネル及びユーザスペースを有するオペレーティングシステムを備えた通信プロトコルサーバとして動作可能であって、アプリケーションプロトコル要求に対して、
    前記アプリケーションプロトコル要求を受信するステップと、
    前記アプリケーションプロトコル要求に対応するユーザスペース要求構造を確立するステップと、
    前記アプリケーションプロトコル要求に関連してクライアントシステムから受信したデータを使用して、前記アプリケーションプロトコル要求に対応するカーネル要求構造を作成するステップと、
    前記ユーザスペースのアプリケーションが実行を続行し、前記オペレーティングシステムがコンテキストを切替えることなく前記アプリケーションプロトコル要求に応答できるように前記カーネル要求構造に従って前記ユーザスペース要求構造を更新するステップと、
    前記アプリケーションプロトコル要求に応答するステップとを、行うことによって応答するよう動作可能である命令実行システム。
18. 請求項１７に記載の命令実行システムであって、
    さらにハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバとして動作可能であることを特徴とする命令実行システム。
19. 請求項１７に記載の命令実行システムであって、
    さらにファイル転送プロトコル（ＦＴＰ）サーバとして動作可能であることを特徴とする命令実行システム。
20. 請求項１７に記載の命令実行システムであって、
    さらにハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバ及びファイル転送プロトコル（ＦＴＰ）サーバとして動作可能であることを特徴とする命令実行システム。

Images