(57)【要約】【課題】融通性のあるアプリケーション・プログラミング・インターフェースを提供することを目的とする。【解決手段】ネットワーク通信のための、キュー非同期アプリケーション・プログラミング・インタフェース（ＡＰＩ）を行うための方法及び技術を提供する。ＡＰＩは、ローカル装置とリモート装置間の接続を示すシステムの抽象化、及び接続時に動作するためのアプリケーションにアクセス可能な多重ルーチンを提供する。上記接続は、これらの各々のローカル装置とリモート装置の間で全二重通信チャネルを提供することが可能である。上記ルーチンは、該接続を確立し、受け入れ、読み出し、記録し、遮断する動作及びパラメータを定義する。【選択図】図５
2008524878.tif 000002
【特許請求の範囲】
【請求項１】
通信アーキテクチャーのためのアプリケーション・プログラミング・インタフェース（ＡＰＩ）であって、
ローカル装置とリモート装置との間の接続を示すシステム抽象化であって、前記システム抽象化に基づく１つ以上のアプリケーションにより例示された接続は、前記各々のローカル装置とリモート装置との間で全二重通信チャネルを提供することの可能な前記システム抽象化と、
１つ以上のアプリケーションにアクセス可能であり、接続を確立し、受け入れ、読み出し、記録及び遮断する動作及び関連のパラメータを定義する複数のルーチンと、
を備えるＡＰＩ。
【請求項２】
前記動作は非同期であり、前記ルーチンに係わるシステムコードは、
（ｉ）存在する場合は、関連のパラメータを確認し、
（ｉｉ）動作をキューし、さらに、
（ｉｉｉ）呼び出しアプリケーションに返す前に完了を待たない、
請求項１に記載のＡＰＩ。
【請求項３】
複数のルーチンは、要請が完了したとき、結果状態によって供給される各々の要請により、呼び出しアプリケーションが任意の不透明パラメータを指定することを許容する、請求項１に記載のＡＰＩ。
【請求項４】
複数のルーチンの読み出し及び記録ルーチンは、各々接続が完全に確立される前に接続のために読み出し及び記録要請を受け入れ、キューすることのできる、請求項１に記載のＡＰＩ。
【請求項５】
前記複数のルーチンのうちのパススルールーチンは、データがアプリケーションレベルにアクセスすることなく、データが直ちに第１の接続から第２の接続まで伝達される能力を提供する、請求項１に記載のＡＰＩ。
【請求項６】
前記ＡＰＩは、下位ハードウェアプラットフォームを直接制御するカスタム実行環境（ＣＥ２）により提供された一連のシステムサービス内で行われる、請求項１に記載のＡＰＩ。
【請求項７】
前記ＡＰＩは、汎用オペレーションシステム内で実行される、請求項１に記載のＡＰＩ。
【請求項８】
前記ＡＰＩは、典型的な仮想マシン制御プログラムの機能を提供し、拡張するゲストオペレーションシステム環境内で実行される、請求項１に記載のＡＰＩ。
【請求項９】
前記ＡＰＩは、マルチプロセシング環境で必要な全てのロックを複数のルーチン内で行って複数のルーチンにより行われる要請を安全にキューすることで、マルチプロセッサーにスケーリングを容易にする、請求項１に記載のＡＰＩ。
【請求項１０】
関連のドライバとネットワークスタックのオンボード及びオフロードボード実現の両方を透過的に支援する複数のモジュール方式配信サービスを示すシステム抽象化をさらに含む、請求項１に記載のＡＰＩ。
【請求項１１】
前記複数のルーチンは、共有要請キュー及び共有結果キューを用いる、請求項１に記載のＡＰＩ。
【請求項１２】
前記ＡＰＩは、種々のプロトコルに対してモジュール方式のアドレスファミリを提供する、請求項１に記載のＡＰＩ。
【請求項１３】
前記ＡＰＩは、アドレスファミリにモジュール方式の配信サービスを提供する、請求項１に記載のＡＰＩ。
【請求項１４】
前記ＡＰＩは、ソケットの最上部でエミュレートされる、請求項１に記載のＡＰＩ。
【請求項１５】
ローカル装置とリモート装置との間でデータを通信する方法であって、
ＣＥ２の非同期接続アプリケーション・プログラミング・インタフェース（ＡＰＩ）により提供される第１クラスの接続の抽象化を用いてリモート装置と全二重通信チャネルを確立し、前記全二重通信チャネルと不透明パラメータを相関させるローカル装置の下位ハードウェアプラットフォームを制御するアプリケーションをカスタム実行環境（ＣＥ２）内で行うステップと、
全二重通信チャネルの確立を完了する前に、前記全二重通信チャネル上で非同期接続ＡＰＩの記録ルーチンを呼び出すことで、ローカル装置からリモート装置へデータが転送されるようにアプリケーションが要請するステップと、
その後、全二重通信チャネルが確立され、その要請されたデータ転送が完了した非同期接続ＡＰＩを介してアプリケーションが指示を受信するステップであって、両指示は不透明パラメータに伴われるステップと、
を含む方法。
【請求項１６】
前記非同期接続ＡＰＩは、マルチプロセシング環境に必要な全てのロックを非同期接続ＡＰＩに係わるルーチン内で行って多重同時発生要請を安全にキューすることで、マルチプロセッサーに対するスケーリングを容易にする、請求項１５に記載の方法。
【請求項１７】
前記非同期接続ＡＰＩは、関連のドライバとネットワークスタックのオンボード及びオフロードボード実現の両方を透過的に支援する複数のモジュール方式の配信サービスを示す抽象化をさらに提供する、請求項１５に記載の方法。
【請求項１８】
ローカル装置とリモート装置との間でデータを通信する方法であって、
ローカル装置の下位ハードウェアプラットフォームを制御するカスタム実行環境（ＣＥ２）の非同期接続アプリケーション・プログラミング・インタフェース（ＡＰＩ）は、非同期接続ＡＰＩにより提供される第１クラスの接続の抽象化を用いて、リモート装置と全二重通信チャネルを確立するために、要請をカスタム実行環境（ＣＥ２）内で行うアプリケーションから受信するステップであって、前記要請は、前記全二重通信チャネルに係わる不透明パラメータを含む前記ステップと、
前記全二重通信チャネルの確立が完了する前に、非同期接続ＡＰＩがローカル装置からリモート装置へ伝達されるデータを規定する記録要請をアプリケーションから受信するステップと、
前記記録要請に応答して、ＡＰＩが前記全二重通信チャネルの確立の完了をペンディングするその記録要請に係わる要請ブロックをクエリーするステップと、
前記全二重通信チャネルが確立された後、非同期接続ＡＰＩは不透明パラメータを含む、第１の完了指示をそのアプリケーションに提供するステップと、
前記記録要請が処理された後、不透明パラメータを含む第２の完了指示を非同期接続ＡＰＩがアプリケーションに提供するステップと、
を含む、方法。
【請求項１９】
前記非同期接続ＡＰＩは、マルチプロセシング環境に必要な全てのロックを非同期接続ＡＰＩに係わるルーチン内で行って多重同時発生要請を安全にキューすることで、マルチプロセッサーにスケーリングを容易にする、請求項１８に記載の方法。
【請求項２０】
前記非同期接続ＡＰＩは、関連のドライバとネットワークスタックのオンボード及びオフロードボード実現の両方を透過的に支援する複数のモジュール方式配信サービスを示す抽象化をさらに提供する、請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、一般的に、装置間の非同期入力／出力（Ｉ／Ｏ）を提供するための方法及びインタフェースに関する。特に、本発明の実施形態は、ネットワーク通信用のキュー非同期アプリケーション・プログラミング・インタフェース（ＡＰＩ）に関するものである。
【背景技術】
【０００２】
２０年経ったＢｅｒｋｅｌｅｙソケットインタフェース（例えば、Ｗｒｉｇｈｔ  ａｎｄ  Ｓｔｅｖｅｎｓ，ＴＣＰ／ＩＰ  Ｉｌｌｕｓｔｒａｔｅｄ  Ｖｏｌｕｍｅ２，Ａｄｄｉｓｏｎ  Ｗｅｓｌｅｙ（１９９６）  ＩＳＢＮ  ０−２０１−６３３５４−Ｘ，Ｃｈ．１６及びＣｈ．１７を参照）は、それ自体反復的に証明された極めて確かな、優れているインタフェースである。しかし、ソケットが使用された通信パラダイムは、遅延、オーバーヘッド、スケジューリングの問題を提起し、マルチプロセッシングのためにスケーリングしない。
【０００３】
ソケットは、ＵＮＩＸシステムにおける極めて合理的で、比較的注意が必要な付加物であって、それは真の非同期（ノンブロッキングと対照的に）入出力（ＩＯ）のための標準方法としては不十分であり、今でも依然不十分である。また、ＵＮＩＸで利用可能な唯一のＩ／Ｏ抽象化は、多くの面でネットワーク通信の要求を満足出来ないファイルである。ソケットを導入する時には、そのオペレーションシステムを大きく再構築せざるをえなかった。
【０００４】
性能問題＃１：オーバーヘッド
図１は、Ｂｅｒｋｅｌｅｙソケットインタフェースモデルにおけるイベント１００の典型的な従来の技術シーケンスを示す。この例によれば、アプリケーション１５０は、ファイルディスクリプターセットの１つ以上のメンバー（図示せず）が１つ以上のファイルディスクリプターに関してイベントを待機するように初期化された状態で、ｓｅｌｅｃｔ（）コール１０５をＢｅｒｋｅｌｅｙソフトウエア設計（ＢＳＤ）ソケットインタフェース１６０に発する。そのｓｅｌｅｃｔ（）コール１０５が復帰する（準備１１０）とき、アプリケーション１５０は、可用ファイルディスクリプター（図示せず）の返されたリストを線形検索する。上記イベントに係わる該データ、例えば利用可能な読み出しデータ１２０がｒｅａｄ（）システムコール１１５をＢＳＤソケットインタフェース１６０に発して読み出されたり、システムコール（一般的にノンブロッキングを設定する）で記録される。そのデータ１２０は、必要な場合には、アプリケーション１５０により処理される。そのアプリケーション１５０がそのソケットとより関連していると、ファイルディスクリプターセットにそのファイルディスクリプターを挿入する。アプリケーション１５０は、次いでこの過程を繰り返してもよい。
【０００５】
次に、イベント１００の該シーケンスの時間ラインを参照すれば、Ｂ、Ｃ及びＥに対応する時間は、ＢＳＤソケットインタフェース１６０のオーバーヘッドを表示する。より大きなコンポーネントはＣであるが、ｓｅｌｅｃｔ（）コール１０５（つまり、Ｂ及びＥで表示された部分）の結果を設定し、解読する所要も無視できない。ファイルディスクリプターが順次に処理されているか、または、セレクト（）結果から収集された後、順次に処理されているかは重要でなく、Ｃオーバーヘッドは要請ごとに行われるので、オーバーヘッドは実質的に同一であることに注意されたい。
【０００６】
ネットワーキングオフロードカードにおいて、オーバーヘッドは、ネットワークデータが汎用オペレーションシステムのＩ／Ｏバッファーにこれ以上存在せず、むしろシステムと非同期で動作するカードのメモリに存在するので、実質的に増大する。たとえコマンドをそのカードに対して発する場合にも、要請が処理される前に直接メモリアクセス（ＤＭＡ）待ち時間や、肯定応答の待ち時間のような長い待ち時間が存在し得る。ＢＳＤソケットインタフェース１６０において、これは性能をひどく制限する固有の障害である。
【０００７】
性能問題＃２：スケジューリング
ＢＳＤソケットインタフェース１６０の別の制限は、１つのスケジューリングである。ｓｅｌｅｃｔ（）コール１０５は、ファイルディスクリプターにどのような臨時情報も保持しない。概念的には、たとえ１つのイベントがより早く発生し、通知はスケジューリングまたは他のシステムの動作のため遅延した場合にも、それらは同時に全て準備される。これは、アプリケーション１５０にスケジューリング処理の負担をかけるので、全ての接続に対して公正なサービスを提供するためには、発見的方法や類似する方法に頼らなければならない。
【０００８】
性能問題＃３：マルチプロセッシング（ＭＰ）
ＢＳＤソケットインタフェース１６０との別の問題は、それがマルチプロセシング環境でうまく適応もせず、うまくスケーリングしないということである。１つのプロセッサーが全ての有効接続のためにｓｅｌｅｃｔ（）コールを処理するのは性能上災害であるのは確かであるが、接続を分散することもやはり扱い難い問題である。アプリケーション１５０は、どの記述語が第１に準備されているか先験的に知ることができず、大概は接続が残りに対してグリッドロックされている間に一部のプロセッサー上の不平衡及び無駄なサイクルが存在することを保障する。直列化、不足及びリソース浪費の問題は扱いにくく、さらに、性能が最も要求されるときほぼ確実に深刻な場合が発生する。
【０００９】
性能問題＃４：オフロードプロセッサー
ＢＳＤソケットインタフェース１６０の内部構造は、古典的なネットワークプロトコルスタックを反映する。このソケットインタフェースモデルにおいて、ネットワークルーティング決定がプロトコルの最下レベル、例えばＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）のインターネットプロトコル（ＩＰ）層で行われる。この設計は、データストリームを案内する決定が遥かに早めに、通常のスタックの最上位で行われる必要があるので、オフロードプロセッサーをプロトコルするのに容易に適応されない。入力側上で、データストリームは既に処理しているので、どうしても既存のプロトコルを避けなければならない。
【００１０】
本発明の図面を参照した実施形態は例示的なものであり、限定するものではなく、同一機能を有するものは同一の参照符号を付ける。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
したがって、この発明は融通性のあるアプリケーション・プログラミング・インターフェースを提供することを目的とする。
【課題を解決するための手段】
【００１２】
ネットワーク通信のための、キュー非同期アプリケーション・プログラミング・インタフェース（ＡＰＩ）を行うための方法及び技術が記載される。一実施形態によれば、ＡＰＩは、（ｉ）ローカル装置とリモート装置間の接続を示すシステムの抽象化、及び（ｉｉ）接続時に動作するためのアプリケーションにアクセス可能な多重ルーチンを提供する。上記システム抽象化に基づくアプリケーションによって例示された接続は、これらの各々のローカル装置とリモート装置との間で全て二重の通信チャネルを提供することが可能である。上記ルーチンは、該接続を確立し、受信し、読み出し、記録し、遮断するために、動作及びパラメータを定義する。
【００１３】
本発明の他の特徴は、添付図面を参照する以後の詳細な説明からより明らかに理解できる。
【発明を実施するための最良の形態】
【００１４】
ネットワーク通信のためのキュー非同期アプリケーション・プログラミング・インタフェース（ＡＰＩ）を行うための方法及び技術を開示する。本発明の実施形態によれば、ｑＮｅｔ接続ＡＰＩは、ソケットに係わる固有の問題中の１つ以上をアドレスするように設計されたカスタム実行環境（ＣＥ２）内で行われる一連のシステムサービスの一部として提供される。例えば、一実施形態において、接続は単に意味論ではない、別の抽象化上で階層化された第１のクラスシステムの抽象化として提供される。また、ｑＮｅｔ接続ＡＰＩ設計は、接続を確立、使用、及び遮断するのに必要なステップ数の最小化を図る。
【００１５】
本発明の一実施形態によれば、システムの実現において、このような設計は新規インタフェース及びプロトコルを容易に付加可能のよう許容し、オフロードプロセッサーの效率的利用を許容する。実際に、一実施形態において、全てのインタフェースは、そのコードを固有に実行するオフロードプロセッサーとして抽象化される。
【００１６】
本発明の一実施形態によれば、応用プログラムの性能を強化するため、全てのｑＮｅｔ接続ＡＰＩコールは、ノンブロッキングであるので、コードができるだけプロセスを実行するように許容する。議論の価値のある少なくとも３つのノンブロッキングコールの結果が存在する。
【００１７】
・第１に、全ての接続動作は非同期である。図１に示されるように、非同期Ｉ／Ｏは、処理から多量のオーバーヘッドを除去するが、そうでないと、データ転送が完全になるまで接続が準備されたものと見なされないからである。最高の性能のために、非同期要求条件はさらに接続を行い、受け入れることに適用されなければならない。ノンブロッキング接続と異なり、本明細書に記載された実施形態による非同期接続は、アプリケーションが下位構造体が初期化されて後すぐに１つ以上のＩ／Ｏ動作をキューすることを許容する。これにより、アプリケーションは、Ｉ／Ｏ動作を開始する前に接続確立が完了することを待つ必要がない。
【００１８】
・好ましくは、アプリケーションは、非同期動作が完了したときインターラプトされる。しかし、多くのアプリケーションらは、非同期イベント通知を処理するように構成されておらず、そこで同期方法が本発明の実施形態によって提供される。一実施形態において、両方の動作モードにおいて、完了は常に完了順に報告される。
【００１９】
・要請は非同期的に完了するので、アプリケーションは結果状態が存在するときシステムによって返される各要請と任意の不透明なパラメータを関連付けることを許容するのが有用である。この値は、アプリケーションが必要とするある情報を表示することができる。
【００２０】
１つ以上のこれら及び他の設計ポイントに基づき、通信アーキテクチャを構成することによってｑＮｅｔが開発された。このような名称は、インタフェースのキュー非同期性質を強調するために付けられたもので、現代のネットワーク通信のキュー非同期性質を反映する。
【００２１】
次に、説明のためのコード及びデータ構造例を含めて、複数の特定の詳細事項が本発明の実施形態の完全な理解のために開示される。しかし、本発明の実施形態において、一部はこれらの詳細な説明がなくても実施することができ、提供された特定例によって本発明が制限されないことを当業者は理解することができる。また、周知の構造及び装置をブロック図の形態で示す。
【００２２】
本発明の実施形態は、様々なステップを含み、以下に説明する。ステップは、オペレーター構成、ハードウェア構成機器により実行されたり、またはマシン実行可能コマンドで実行されてもよく、そのコマンドによってプログラム化された汎用または専用プロセッサーがこのステップを実行するように用いられる。代替として、このステップは、オペレーター構成、ハードウェア、ソフトウエア及び／またはファームウェアの組合せにより実行される。
【００２３】
本発明の実施形態は、コンピュータプログラムの製品として提供されてもよく、それはプロセスを実行するためにコンピュータ（または、他の電子装置）をプログラム化するのに用いられるコマンドを格納している機器の読み出しの可能なメディアを含んでもよい。機器の読み出しの可能なメディアとしては、磁気ディスク、フロッピーディスク、光ディスク、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭｓ、ＣＤ−Ｒｓ、ＣＤ−ＲＷｓ）、デジタル多機能ディスク（ＤＶＤ−ＲＯＭ、ＤＶＤ＋ＲＷ）、及び磁気光学ディスク、ＲＯＭ、ランダムアクセスメモリ（ＲＡＭ）、消去可能プログラマブル読み出し転用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、磁性または光学カード、フラッシュメモリ、または電子的コマンドを格納するのに適している他の種のメディア／機器読み出しの可能なメディアを含むが、これに限定されない。さらに、本発明の実施形態は、コンピュータプログラム製品としてダウンロード可能であり、このプログラムは、リモートコンピュータから要請するコンピュータまで搬送波または他の伝播媒質に含まれたデータ信号により通信リンク（例えば、モデムや接続網との接続）を経由して伝達されてもよい。
【００２４】
便宜のために、本発明の実施形態をカスタム実行環境で提供されたネットワーク通信用接続ＡＰＩについて説明するが、本発明は、他の様々な環境に適用可能である。例えば、ｑＮｅｔ接続ＡＰＩは、主な汎用オペレーションシステム、つまり現在または将来のＵＮＩＸ、Ｌｉｎｕｘ及び／またはＷｉｎｄｏｗｓオペレーションシステムのバージョン、または専用運営システムのうちの１つ以上のようなオペレーションシステムで統合されてもよい。
【００２５】
また、説明を簡単にするために、本発明の実施形態としてＴＣＰ及びユーザーデータグラムプロトコル（ＵＤＰ）について説明する。しかし、本発明は、様々な他の種の通信プロトコル及びウェブプロトコルに適用可能である。また、ｑＮｅｔ接続ＡＰＩは、ネットワーク通信の環境でソケットに対する代替物として機能するようにしたものであるが、ソケットと共存することも可能である。結論的に、ソフトウエアの開発を容易にするため、及びテストのため、ｑＮｅｔ接続ＡＰＩはソケットの最上部でエミュレートされてもよい。
【００２６】
用語
以下、この明細書で使用される用語や略語、及び文章に関して簡単に定義する。
【００２７】
「完了」とは、要請に対して用いられる場合、一般的にエラー条件の有無にかかわらず終了した要請を示す。完了は、内部的にキューされ、アプリケーションにより１つ以上の適しているｑＮｅｔ接続ＡＰＩコールを介してアクセスされる。
【００２８】
「同時並行のカスタム実行環境」または略語「Ｃ２Ｅ２」は、一般的に汎用オペレーションシステムと共存し、少なくとも通信手段を汎用オペレーションシステムと共有するカスタム実行環境を示す。
【００２９】
「接続される」または「連結される」、及びその関連用語は、動作的意味で使用され、必ずしも直接的な物理的接続または連結に制限されない。
【００３０】
「接続」とは、一般的にローカル装置とリモート装置との間の全二重通信チャネルに対応するシステム抽象化を示す。
【００３１】
「カスタム実行環境」または「ＣＥ２」は、一般的にシステムリソース部分に対する直接アクセス及び全ての制御を有するソフトウエアで実行された一連のシステムサービスが提供される、カスタム動作環境そのものを示す。ＣＥ２の例は、同時出願中である米国特許公開第２００４０１７７２４３号に記載されており、これは、全ての目的のために参照として本明細書に組み込まれている。ＣＥ２は、オペレーションシステムまたは専用オペレーションシステムと完全に区別され、さらに、具体的な実施形態により、以下の特徴のうちの１つ以上を含むことができる。
【００３２】
１．ＣＥ２は、静的にリンクされるシステムコード及びデータモジュール、及び応用プログラムドコード及びデータモジュールの両方を含むことができる。
【００３３】
２．ＣＥ２は、他のいずれかのアプリケーションをロードしたり、またはロードして実行できる能力がない場合もある。
【００３４】
３．ＣＥ２の機能的な能力は、厳しく単に特定のアプリケーションまたはアプリケーションの小さなセットにより要求されるサービスにのみ制限されることもある。
【００３５】
４．ＣＥ２は、典型的にオペレーションシステムの期待された能力に著しく及ばない。特に、一実施形態において、アプリケーションは、ＣＥ２により制御される各プロセッサーまたはマルチコアプロセッサーのコアでシングルスレッドの実行に制限される。
【００３６】
５．ＣＥ２のサービスインタフェースは、アプリケーションの広範囲なクラスに対してより複合的で一般的なＡＰＩで構成される場合に比べて単純であり、特定アプリケーションの各々または小さなセットごとに特殊化されることもある。
【００３７】
６．ＣＥ２内のシステムリソースに対するマネージメント計画は、時々全的に伝統的な汎用オペレーションシステムにより採択される計画とは異なる。
【００３８】
７．ＣＥ２は、汎用または共生する汎用オペレーションシステムにより支援されないハードウェア能力を利用することができる。
【００３９】
８．ＣＥ２は、汎用または共生する汎用オペレーションシステムによりあまり利用されないハードウェア能力を実質的に使用することができる。
【００４０】
９．ＣＥ２内でアプリケーションに提供されたサービスは、アプリケーションがシステムエラーからより簡単に回復して継続することができるように設計されることができる。
【００４１】
１０．本発明の一実施形態によれば、汎用オペレーションシステムは、コンピュータシステムに係わるシステムリソースの全ての、または一部分の制御を１つ以上のＣＥ２に最小限一時的に譲る。また、他の実施形態によれば、ＣＥ２は、ハードウェアで直接ブートされることができる。例えば、汎用オペレーションシステムは、ＣＥ２により制御されるシステムリソース部分に対して全く制御せずにＣＥ２を始動することができる。別の実施形態においては、汎用オペレーションシステム及び１つ以上のＣＥ２両方は、Ｈｅｗｌｅｔｔ  Ｐａｃｋａｒｄ社のＳｕｐｅｒｄｏｍｅプラットフォームに提供されたものと同様の別個のハードウェアパーティションでブートされることができる。ＣＥ２は、特定ハードウェアプラットフォームに対して典型的に特殊化される。一実施形態によれば、ＣＥ２は、非移動型であり、カスタム実行環境とカスタム実行環境に割り当てられるシステムリソースの間に挿入された汎用オペレーションシステムの抽象化が存在しない。典型的に、ＣＥ２により提供されるシステムサービスは、特定アプリケーションに調整された、簡単な計算構造及び／またはＩ／Ｏ構造を実現する。例えば、ＣＥ２は、汎用オペレーションシステムにより利用されないあるプロセッサーまたは他のシステムリソースの特徴を利用することもできる。一実施形態によれば、調整されたＣＥ２は、ウェブサーバー、保安ウェブサーバー、プロキシサーバー、保安プロキシサーバーまたは他のアプリケーションまたは通信サーバーのようなウェブエッジエンジンを支援し、そのウェブエッジエンジンができるだけ１００％に近くネットワーク接続の利用を許容するように提供される。
【００４２】
「配信サービス」とは、一般的に特定の物理的接続で特定のプロトコルファミリ（例えば、ＩＰＶ４またはＩＰＶ６）を示す。
【００４３】
ハンドルとは、一般的に特定の接続に係わる識別子を示す。一実施形態によれば、ハンドルは、この特定の接続を判別する３２ビットトークンを含む。
【００４４】
「一実施形態において」、「一実施形態によれば」などは、一般的に、その後に示される特定の特徴、構造または特性が、本発明の少なくとも一実施形態に含まれ、１つ以上の本発明の実施形態に含まれることを意味する。しかし、その段階が必ずしも同一の実施形態を示すのではない。
【００４５】
「着信」とは、接続に対して使用する場合、一般的に、リモート装置からローカル装置上のプロトコルの特定のエンドポイントまで開始される接続を示す。
【００４６】
略語「ＩＰＶ４」は、一般的にインターネットプロトコル、バージョン４に基づくネットワークプロトコルのセットを示す。
【００４７】
略語「ＩＰＶ６」は、一般的にインターネットプロトコル、バージョン６に基づくネットワークプロトコルのセットを示す。
【００４８】
例えば明細書に、「あってもよい」、「あることができる」、「してもよい」、「することができる」などの記載が含まれたり、または特性を有する構成要素または特徴が言及される場合には、その特定の構成要素または特徴が含まれたり、その特性を有することが要求されない。
【００４９】
「オフロードボード」とは、一般的により高いレベルのインタフェースを支援し、付加のプロセシングサイクルを高いボリュームネットワーク、または他のプロセシング負荷の処理に用いることができる別個のプラグインボードのような、別個のプラグインボードを示す。一実施形態において、このようなボードは、安全にブートすることを単独に補助するために採用してもよい。
【００５０】
「不透明パラメータ」とは、一般的にアプリケーションにより生成され、アプリケーションが特定の要請を判別することを助けるｑＮｅｔ接続ＡＰＩ要請の一部としてアプリケーションによって供給された情報を示す。本発明の一実施形態において、ｑＮｅｔ接続ＡＰＩは、相応する要請の完了時に該アプリケーション−供給された不透明パラメータを結果ブロックに返す。不透明パラメータは、アプリケーションが特定の要請を判別するように選択する任意の方法でエンコードされることもできる。例えば、不透明パラメータは、６４−、３２−、または、１６−ビット値、配列へのポイント、テーブルインデクス整数値、１つ以上のフラッグ、完了関数（ｃｏｍｐｌｅｔｉｏｎ  ｆｕｎｃｔｉｏｎ）のアドレス、制御構造体のアドレス、データ構造体へのポインター、データ構造体へのインデクス、関数へのポイント、ビットマスク、コードとビットマスクの組合せ、複数の小さなフィールドなどであってもよい。
【００５１】
「発信」とは、一般的に接続に対して使用されるとき、ローカル装置から特定のリモート装置まで開始される接続を示す。リモート装置は、典型的にプロトコルアドレスまたはドメインネームのうちのいずれか１つに加えて、例えばＵＤＰまたはＴＣＰポートのようなプロトコルの特定情報により識別される。
【００５２】
「並列保護アーキテクチャー」または「ＰＰＡ」は、一般的にＩｔａｎｉｕｍ２プロセッサーの明示的コマンドレベル並列性及び保護能力を少なくとも含むコンピュータアーキテクチャーを示す。
【００５３】
「ペンディング（ｐｅｎｄｉｎｇ）」とは、一般的に要請に対して使用される場合、まだ終了していない要請を示す。一実施形態によれば、実際ネットワーク接続が完了する前に、ペンディング接続要請、着信または発信で接続主体が読み出し及び／または記録要請を受け入れることができる。
【００５４】
「主要汎用オペレーションシステム」または「ＵＬＷシステム」とは、一般的に現在及び未来のバージョンのＵＮＩＸ、Ｌｉｎｕｘ及びＷｉｎｄｏｗｓオペレーションシステムを示す。
【００５５】
「要請」または「要請ブロック」とは、一般的に接続に対する動作及び関連パラメータを示す。一実施形態によれば、接続上の動作は、接続を実行、受け入れ、読み出し、記録及び／または遮断することを含む。一実施形態において、全ての要請が非同期である、つまりシステムコードは、パラメータを確認してその動作をキューするが、発信者に返される前に完了を待たない。
【００５６】
「応答する」とは、完全にまたは部分的に応答することを含む。
【００５７】
「結果」または「結果ブロック」とは、一般的に完了に係わる値を示す。一実施形態によれば、この値は、同期的または非同期的であるかをアプリケーションに通知するときに利用することができる。このパラメータは、接続のハンドル、遠隔ＩＰ及びポートアドレス、完了状態及び／または要請により呼び出しアプリケーションにより含まれたパラメータを含んでもよい。
【００５８】
「共生（ｓｙｍｂｉｏｔｉｃ）汎用オペレーションシステム」または略語「ＳＧＰＯＳ」は、一般的に主要汎用オペレーションシステムのうちの１つのようなオペレーションシステムを示し、それは以下の能力の１つ以上を含むように向上されている。（１）１つ以上のＣＥ２と協力的に連携してコンピュータシステムのリソースを管理するメカニズム；（２）システムリソースをパーティション／区画し、プロセッサー、物理的メモリ、記憶装置、仮想メモリ識別子値、Ｉ／Ｏ装置及び／または例外の配信を含む、システムリソースの１つ以上のパーティションの制御を１つ以上のＣＥ２ｓに伝達するメカニズム；及び（３）システムリソースのパーティション間の通信を許容するメカニズム。ＳＧＰＯＳｓは、移植可能な状態にあることができるか、または特定のハードウェアプラットフォームに関して特殊化されてもよい。ＳＧＰＯＳの例は、同時出願中である米国特許出願公開番号２００４０１７７３４２号に開示されており、これは、全ての目的のために参照として本明細書に組み込まれる。
【００５９】
「システムリソース」とは、一般的に個別的または集合的にコンピュータシステム、例えばプロセッサー、物理的メモリ、記憶装置、仮想メモリ識別子値、入力／出力（Ｉ／Ｏ）装置、例外配信などの演算リソース及び／または他のリソースを示す。
【００６０】
「スレッド（ｔｈｒｅａｄ）」または「実行のスレッド」とは、一般的にプロセッサー制御レジスタの特定状態における連続コマンドの実行を示す。プロセッサーが２つのアプリケーションを同時に行っている場合、一時的に１つのアプリケーションスレッドで実際に行った後、転換して一時的に、別のアプリケーションスレッドで行い、往復して行う。
【００６１】
「ウェブエンジン」及び「ウェブエッジエンジン」とは、一般的にハードウェア、ファームウェア及び／または１つ以上のウェブプロトコルを支援するソフトウエアを示す。
【００６２】
「ウェブプロトコル」とは、一般的にハイパーテキストトランスファープロトコル（ＨＴＴＰ）、保安ＨＴＴＰ（Ｓ−ＨＴＴＰ）、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）、転送制御プロトコル（ＴＣＰ）、ユーザーデータグラムプロトコル（ＵＤＰ）、インターネットプロトコル（ＩＰ）、転送階層保安（ＴＬＳ）、拡張性生成言語（ＸＭＬ）、単純客体接近プロトコル（ＳＯＡＰ）、汎用ディスクリプション、ディスカバリー及びインテグレーション（ＵＤＤＩ）、ＤＨＴＴＰ、ＨＴＴＰ／ＮＧ、ファイル転送プロトコル（ＦＴＰ）、簡易ＦＴＰ（ＴＦＴＰ）、共通オープンポリシーサービス（ＣＯＰＳ）、フロー属性通知プロトコル（ＦＡＮＰ）、フィンガーユーザー情報プロトコル、インターネットメッセージアクセスプロトコルｒｅｖ４（ＩＭＡＰ４）、ＩＰ装置制御（ＩＰＣＤ）、インターネットメッセージ接近プロトコルバージョン４ｒｅｖｌ（ＩＳＡＫＭＰ）、ネットワークタイムプロトコル（ＮＴＰ）、ポストオフィスプロトコルバージョン３（ＰＯＰ３）、ラジウスリモートログイン（ＲＬＯＧＩＮ）、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、ストリーム制御転送プロトコル（ＳＣＴＰ）、サービスロケーションプロトコル（ＳＬＰ）、ＳＭＴＰ単文メール転送プロトコル（ＳＭＴＰ）、簡易網管理プロトコル（ＳＮＭＰ）、ＳＯＣＫＳ、ＴＡＣＡＣＳ＋、ＴＥＬＮＥＴ及ウェブキャッシュ調整プロトコル（ＷＣＣＰ）を含むが、これに限定されない、現在及び未来のネットワークプロトコルを示す。
【００６３】
次に、本発明の様々な特徴を利用できる、例えば２−ウェイＨＰサーバーｒｘ１６００、４−ウェイＨＰサーバーｒｘ５６７０、ＨＰサーバーｒｘ２６００などのような、例示的なサーバーで代表される例示的なコンピュータシステム２００を、図２を参照して説明する。この単純化した例において、コンピュータシステム２００は、バス２３０またはデータ及び制御情報を伝えるための他の通信手段、及びバス２３０に接続された、例えばＩｎｔｅｌ（登録商標）  Ｉｔａｎｉｕｍ（登録商標）またはＩｔａｎｉｕｍ２プロセッサーのような１つ以上のプロセッサー２０５を備える。
【００６４】
コンピュータシステム２００は、プロセッサー２０５により実行される情報及びコマンドを格納するために、バス２３０に接続されたランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置（メインメモリ２１５という）をさらに含む。また、メインメモリ２１５がプロセッサー２１５によるコマンドを実行する間、臨時変数または他の中間情報を格納するために用いられてもよい。本発明の様々な実施形態によれば、メインメモリ２１５は、領域−識別子−基盤メモリパーティションメカニズム（ｒｅｇｉｏｎ−ｉｄｅｎｔｉｆｉｅｒ−ｂａｓｅｄ  ｍｅｍｏｒｙ  ｐａｒｔｉｔｉｏｎｉｎｇ  ｍｅｃｈａｎｉｓｍ）によってパーティションされてもよい。このようにして形成されたパーティションは、該プロセッサーまたはコアによる排他的アクセスのためにメモリの領域を保護キーと関連付けるようなハードウェア−基盤分離メカニズムを用いてマルチコアプロセッサーの１つ以上のプロセッサーまたは１つ以上のコアに割り当てることができる。
【００６５】
また、コンピュータシステム２００は、１つ以上のＣＥ２、カスタムアプリケーション及びオペレーションシステムの初期コード及びデータイメージに係わる暗号化されたデジタル署名、及びプロセッサー２０５に関するコマンドのような、静的情報を記憶するために、バス２３０に結合されている読み出し専用メモリ（ＲＯＭ）２２０及び／または他の静的な記憶装置を備える。
【００６６】
また、磁気ディスクまたは光ディスク、及びその対応ドライブのような大容量の記憶装置２２５が、オペレーションシステムローダー、オペレーションシステム、１つ以上のカスタムアプリケーション及び関連ＣＥ２、初期化ファイルなどのような情報及びコマンドを保存するためにバス２３０に結合されてもよい。
【００６７】
また、１つ以上の通信ポート２１０は、例えば近距離ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネットまたは公衆交換電話ネットワーク（ＰＳＴＮ）を介してコンピュータシステム２００へ／からの情報の通信及びネットワーク接続を支援するためにバス２３０に結合されてもよい。通信ポート２１０は、例えばダイヤルアップ能力を提供する１つ以上のモデム、１つ以上の１０／１００イーサネットポート、１つ以上のキガビットイーサネットポート（ファイバー及び／または銅）、１つ以上のネットワークプロトコルオフロードボードのような周知のインタフェース、またはインターネットワーク環境で一般的に使用される他の周知のネットワークインタフェースの様々な組合せを含んでもよい。どのような場合にも、このような方法で、コンピュータシステム２００は、例えば企業のイントラネット及び／またはインターネットのような従来のネットワークインフラストラクチャーを経由して、多くの他のネットワーク装置、クライアント及び／またはサーバーに結合することができる。
【００６８】
代替的に、オペレーター及び管理インタフェース２３５、例えばディスプレー、キーボード及びカーソル制御装置は、さらにコンピュータシステム２００との直接的なオペレーター相互作用を支援するためにバス２３０に結合されてもよい。他のオペレーター及び管理インタフェースは、通信ポート２１０を介して接続されるネットワーク接続によって提供されることができる。
【００６９】
最終的に、例えば１つ以上の外部または着脱式ハードドライブ、テープ、フロッピーディスク、光磁気ディスク、コンパクトディスク−読み出し専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスク記録可能なメモリ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、デジタルビデオディスクまたはデジタルビデオディスク（ＤＶＤ）（例えば、ＤＶＤ−ＲＯＭ及びＤＶＤ＋ＲＷ）、Ｚｉｐディスク、くは、例えばｔｈｕｍｂドライブまたはフラッシュカードのようなＵＳＢメモリ素子のような着脱式記憶媒体２４０が対応するドライブ、ポートまたはスロットを介してバス２３０に結合されることもできる。
【００７０】
図３Ａは、ＳＧＰＯＳ  ３２５がシステムリソースのパーティション３２９の制御を維持する本発明の一実施形態により安全な高性能のプロセシング環境をサーバー３３０に提供するように構成されたコンピュータシステム３００を概念的に示す。図示されるようなシステム構成は、プロセッサー、関連チップセットまたは中間インタフェースで動作環境（例えば、オペレーションシステム及びＣＥ２）とシステムリソースの間に挿入された、保安−プラットフォーム（ｓｅｃｕｒｅ−ｐｌａｔｆｏｒｍ）インタフェースのような適合したハードウェア基盤の分離構成（ｆｅａｔｕｒｅｓ）の存在により支援される、例示的な多重パーティションの構成を示す。このような分離構成が広く利用できるまで、図３Ｂに示すような、プラットフォームハードウェアパーティショニングまたはより典型的な１つのパーティションの構成が安全なシステムのための選択的構成であると考えられる。
【００７１】
再び本実施形態に戻れば、コンピュータシステム３００は、ダイナミックコンテンツ生成器３２０にサービスを提供するＳＧＰＯＳ  ３２５に係わるパーティション３２９と、ＣＥ２３３５に係わるパーティション３３９との間のシステムリソース３１０の割当ての後が概念的に示されており、それはサービスを保安サーバー３３０に提供する。ＣＥ２３３５が全体的にＳＧＰＯＳ  ３２５及び汎用オペレーションシステムに強要された移動性制約に制限されないため、単純化された、そして、特定の下位ハードウェアプラットフォーム（例えば、１つ以上のインテルＩｔａｎｉｕｍ２プロセッサー及び関連のチップセット）及び／または特定のカスタムアプリケーション（例えば、保安プロキシサーバーまたは保安サーバー３３０）に最適化された演算及び／またはＩ／Ｏ構造を実施することができる。
【００７２】
この例において、未来のハードウェア分離能力または現在のハードウェアプラットフォームパーティショニングを採用することが、常駐オペレーションシステム、ＳＧＰＯＳ  ３２５及び常駐オペレーションシステムから分離された動作環境、ＣＥ２  ３３５の同時的かつ協同的実行を支援することにより、他のカスタムアプリケーションを行う能力を維持するとともに、サーバー保安と性能を増大することができる１つの可能なシステム構成を示す。
【００７３】
図３Ｂは、本発明の代替的実施形態による、安全な高性能のプロセシング環境をサーバー３３０に提供するように構成されたコンピュータシステム３００を概念的に示す。図示されたシステム構成は、常駐オペレーションシステムが、ＣＥ２３３５を初期化して開始した後、システムリソース３１０全てまたはほぼ全ての制御をＣＥ２３３５に渡し、その後、システムリソース３１０の解除時、ＣＥ２３３５により回復することができる中止状態に置かれる、可能なシステム構成を示す。予想されるハードウェア基盤の分離特徴が可能であり、産業的に受容されることが出来るときまではＳＧＰＯＳ  ３２５は、停止中であり、システムリソース３１０全てまたはほぼ大部分の全ての制御が１つ以上のＣＥ２に与えられるシステム構成またはハードウェアプラットフォームパーティショニングが支配的な構成であると見られる。ＣＥ２パーティション内及び／または間に分離が好ましい場合には、領域識別子、保護識別子及びメモリページのアクセス権限のような現在または未来の進歩したメモリ保護アーキテクチャーが使用されてもよい。
【００７４】
図４は、本発明の一実施形態による１つ以上のゲストオペレーションシステムを支援するアーキテクチャーを概念的に示す。図示された例において、ゲストオペレーションシステム環境（ＧＯＳＣ）４５０、４５５がＬｉｎｕｘのようなゲストＯＳと、保安実行環境４６０の間にインタフェースを提供するために、ＣＥ２形態の基本オペレーションシステム（つまり、保安実行環境４６０）とマシン従属ゲストオペレーションシステム（つまり、マシン従属ゲストＬｉｎｕｘ４４０及びマシン従属ゲストその他のＯＳ  ４４５の各々）の間に挿入され、それは実際ハードウェアプラットフォームを制御する。
【００７５】
一実施形態において、ゲストＯＳ環境４５０、４５５が提供され、現在一般的に「仮想マシンモニタ」（ＶＭＭ）と呼ばれる典型的な仮想マシン制御プログラムの機能を拡張する。これは、メインライン汎用オペレーションシステムへの拡張を行って標準化することなく、アプリケーション４２０、４２５がゲストオペレーションシステム（例えば、ゲストＬｉｎｕｘ４３０及びゲストその他のＯＳ  ４３５）に存在しないＡＰＩを利用することを可能にする。また、図示したような実施形態において、ゲストオペレーションシステム内のマルチプロセッサーコンプレキシティ（ｃｏｍｐｌｅｘｉｔｉｅｓ）及びオーバーヘッドを処理せずに、マルチコアプロセッサー４０５の別個のコアがアプリケーションの代わりにゲストオペレーションシステム内で作業を行うことを許容する。
【００７６】
一般的に、同一のコア及び他のコアの両方において行う調整された関数への接近が提供されることができる。例えば、ネットワークＩ／Ｏスタック４１０の場合、別個のコアがネットワークオフロードコンポーネントとして機能することができる。以下に説明するように、一実施形態において、ネットワークＩ／Ｏスタック４１０は、完全に非同期的であってもよく、ここでｑＮｅｔ接続ＡＰＩと称することができるキューイングＡＰＩにより駆動されてもよい。このような方法で、Ｌｉｎｕｘのように本来ゲストオペレーションシステム用として開発されてゲストオペレーションシステムで実行されるアプリケーション４２０、４２５は、性能を利用し、ネットワークＩ／Ｏスタック４１０を利用することも可能である。
【００７７】
図５は、本発明の一実施形態による、非同期網Ｉ／Ｏスタックの動作を示すデータフロー及び制御フローダイアグラムである。この例において、アプリケーション５０５は、ゲストオペレーションシステム内で、または、固有のアプリケーションインタフェース（つまり、ＣＥ２ＡＰＩ）に対して実行されている。アプリケーション５０５は、ｑＮｅｔ接続ＡＰＩ  ５９５へのコールを行うことにより接続を設定、利用する。ｑＮｅｔ接続ＡＰＩ  ５９５へのアプリケーション５０５による各コールは、定義された要請ブロック５１０、５１５のうちの１つを指定する。一実施形態によれば、各要請ブロック５１０、５１５は、アプリケーション５０５が特定の要請を識別するように選択する任意の方法でエンコードされることができる不透明パラメータを含む。対応する結果ブロックがペンディングイベントキュー５８０に記録されるとき、不透明パラメータは、該結果ブロックに返される。
【００７８】
要請ブロック５１０は、ネットワーク接続を受け入れ、確立するための制御を指定する。この例によれば、各要請ブロック５１０は、アドレスファミリ５２０、例えばＩＰｖ４またはＩＰｖ６を指定する。
【００７９】
要請ブロック５１５は、ネットワーク接続を読み出し、記録、遮断、再設定するための制御及びデータ転送を指定する。この要請ブロックは、最初に接続が確立したとき供給された識別するハンドル５２５を用いて既に確立された接続を指定する。
【００８０】
配信サービス５３０は、指定されたオンボードまたはオフロードボードコマンドドライバ５３５、５４０に対して要請ブロックをエンキューする（ｅｎｑｕｅｕｅ）。オンボード（ｏｎ−ｂｏａｒｄ）要請は、オンボードＴＣＰ／ＩＰコマンドドライバ５４０により、オンボードＴＣＰ／ＩＰネットワークスタック５４５によりサービスされるＦＩＦＯ要請キュー５６０にキューされる。オフロード要請は、ホストからオフロードボード５７５からＴＣＰ／ＩＰネットワークスタックまで要請ブロックを通信するため、要請ＦＩＦＯ、例えば共有された要請ＦＩＦＯ  ５５５にオフロードボードコマンドドライバ５３５によりキューされる。
【００８１】
オンボードネットワーク要請のために、回路基板上にあるＴＣＰ／ＩＰネットワークスタック５４５は、要請ＦＩＦＯ  ５６０から順に要請ブロックをデキューする（ｄｅｑｕｅｕｅ）。ＴＣＰ／ＩＰネットワークスタック５４５内のデータ構造（図示せず）は、各接続に対して状態及び操作用パラメータを含む。ＴＣＰ／ＩＰネットワークスタック５４５内のバッファー（図示せず）は、ネットワークインタフェースカード（ＮＩＣ）ドライバ５６５を介してネットワークから着信パケットを受信する。ネットワークへの発信パケットは、このバッファー内でフォーマットされ、ＮＩＣドライバ５６５を介してネットワークに転送される。要請ブロックからのそれぞれの後続結果が準備される場合、結果ブロックは、例えば中央キュールーチン、つまりｓ６４ｏｐＲｅａｄｙ（）５４６をコールすることにより、ＴＣＰ／ＩＰネットワークスタック５４５によってペンディングイベントキュー５８０にエンキューされる。
【００８２】
オフロードボードネットワーク要請のために、ＴＣＰ／ＩＰオフロードプロセッサー及びファームウェア５７５は、共有される要請ＦＩＦＯ  ５５５から順に要請ブロックをデキューする。オフロードＴＣＰ／ＩＰネットワークスタック５７５内のデータ構造（図示せず）は、それぞれの接続に対して状態及び操作用パラメータを含む。オフロードボード内のバッファー（図示せず）は、オフロードボードに含まれたネットワークインタフェースアダプタ（図示せず）及びネットワークドライバを介してネットワークからパケットを受信する。ネットワークへの発信パケットは、このバッファー内でフォーマットされ、ネットワークインタフェースアダプタを介してネットワークに転送される。要請ブロックからのそれぞれの後続結果が準備される場合、結果ブロックは、ＴＣＰ／ＩＰオフロードプロセッサー及びファームウェア５７５により、その共有される結果ＦＩＦＯ  ５７０にエンキューされる。オフロード結果プロセシング５５０は、共有される結果ＦＩＦＯ  ５７０から順に結果ブロックをデキューし、中央キュールーチン、例えばｓ６４ｏｐＲｅａｄｙ（）５４６をコールすることによってペンディングイベントキュー５８０へその結果ブロックを順にエンキューする。
【００８３】
説明のために、５つの結果ブロック５８１〜５８５を図５に示し、この各々は、対応する要請ブロックで指定された動作に対する中間または最終のパラメータをエンコードする。アプリケーション５０５がｑＮｅｔ接続ＡＰＩ  ５９５にｓ６４＿ｑＲｅａｄｙ（）要請５９０を発するとき、要請ブロックは、ペンディングイベントキュー５８０から順に変換される。
【００８４】
例示的なｑＮｅｔ接続ＡＰＩ実現に関する詳細な説明
以下に説明する実施形態において、ｑＮｅｔ接続ＡＰＩは、６個のカテゴリー、つまり構成、接続状態、発信接続、着信接続、接続Ｉ／Ｏ及び接続制御に分けられる。
【００８５】
さらに、説明のために、本発明の実施形態に対する理解を助けるため、コード及びデータ構造例を含む、複数の具体的な説明を以下に記載するが、本発明の実施形態は、これらの一部の具体的な説明なしに実施することができ、本発明がこの例によって制限されるのではないことを理解されたい。
【００８６】
配信サービス及び構成
本発明の一実施形態によれば、ｑＮｅｔ通信アーキテクチャーは一連の配信サービスとして構成される。それぞれの配信サービスは（ネットワークコネクタに対応する）物理的インタフェースとプロトコルアドレスファミリとの固有の組合せを示すことができる。以下の例において、配信サービスは、０から始めて１ずつ増加し、利用できる配信サービスの総数より１つ少ない数まで増加するように番号が付与される。一実施形態において、支援される配信サービスの最大数は２５６である。配信サービスＩＤは、情報をクエリーしてプロトコル−特定パラメータを構成するのに使用されることができる。
【００８７】
支援される配信サービスの最大数が２５６である実施形態では、各々の配信サービスは少なくとも１つ、多い場合でも２５６個のｉｄｅｎｔｉｔｙを支援する。ｉｄｅｎｔｉｔｙは、配信サービスが、例えばＩＰＶ４に対するＩＰアドレスに応答するプロトコルアドレスに対応する。従って、配信サービスのための全ての識別子は、次のようにフォーマットされた１６ビット値である：
【表１】
2008524878.tif 000003
【００８８】
一実施形態において、ｉｄｅｎｔｉｔｙゼロ（０）は常に有効である；一部の配信サービス制御は、単にこのｉｄｅｎｔｉｔｙに適用されることができる。配信サービスにより支援されるｉｄｅｎｔｉｔｙの数は、ＤＳ＿ＱＵＥＲＹ応答の一部として返される。
【００８９】
グローバルプロトコルパラメータ、例えばＩＰＶ４に対するＤＮＳサーバーアドレスは、一般的なプロトコルインタフェースにより構成されることができる。コマンド及びパラメータは、特定のプロトコルの意味論によって解読される。
【００９０】
一実施形態によれば、全ての配信サービス及びプロトコル／アドレスファミリは、共通のクエリーコマンドを支援する。このコマンドは、ある特定のサービスまたはプロトコルが支援するようになるかを含む基本情報を決めるためにアプリケーションによって使用される。
【００９１】
接続情報
一実施形態によれば、一般的な接続情報の構造は次のように定義される：
typedef struct{
u8  ciAF;  //プロトコル／アドレスファミリ
u8  ciFlags;  //プロトコル−または関数−依存フラグ
u8  ciInfo[14];  //プロトコル−または関数−依存フラグ情報
}s64c_connInfo ALIGNED(8);
【００９２】
このように、各々のプロトコル／アドレスファミリは、一般的な構造をオーバーレイする自分のコマンド及びアドレス構造を有することができる。上記の例において、第１のバイトは、アドレスのパターンを定義する。第２のバイトは、プロトコル−、コマンド−または関数−特定の値で提供される。残りの14バイトは、任意の割り当てまたは構造体オーバーレイに用いることができる。その構造は、１、２、４または８−バイト接近のために適切に整列され、ポインターまたはどの整数値も適切に構造にパックされることができることに注意されたい。プロトコルが情報の全ての14バイトを使用しない場合には、それは未来の互換性のためにゼロで満たされなければならない。
【００９３】
例えば、一実施形態において、ＴＣＰ／ＩＰ（ＩＰＶ４）アドレス構造は次のように定義される：
typedef struct{
u8  ipv4_af;  //プロトコル／アドレスファミリ
u8  ipv4_flags;  //プロトコル−または関数−依存フラグ
u16  ipv4_port;  //接続ポートアドレス（ネットワーク順序）
u32  ipv4_addr;  //接続ＩＰアドレス（ネットワーク順序)
u64  ipv4_zero;  //未使用、ゼロではなければならない
}ipv4Addr ALIGNED_DECL(8);
【００９４】
接続状態
一実施形態によれば、要請が完了した場合、次の状態情報を用いることができる：
typedef struct{
s64c_param  qrParam;  //キュー要請からの不透明パラメータ
s64c_handle  qrHandle;  //関連ハンドル値
s64c_status  qrStatus;  //エラーコード
u64  qrInfo[2];  //コマンド依存情報
}s64c_qr;
【００９５】
上記のように、一実施形態では、使用中である接続上の要請からの結果がキューされる。次の準備項目の結果を読み出すために、アプリケーションコールは、ｑＮｅｔ接続ＡＰＩに次のフォームでコールを行うことができる：
s64c_qr result=s64_qReady();
【００９６】
どの結果も利用することができない場合は、ハンドルの値は、Ｓ６４Ｃ＿ＮＯＨＡＮＤＬＥである。各々の接続の現在状態は、次のコールによってクエリーされる：
typedef struct{
u8  cnAF;  //プロトコル／アドレスファミリ−常にＳ６４ＡＦ＿ＩＰＶ４
u8  cnFlags;  //プロトコル−依存フラグ
u16  cnDS;  //配信サービス及びｉｄｅｎｔｉｔｙ
u32  cnStatus;  //接続状態
u64  cnInfo;  //プロトコル−特定情報
}s64c_cnInfo;
s64c_cnInfo cnInfo;
err=s64_cnControl(handle, CN_QUERY, (s64c_connInfo*)&cnInfo);
【００９７】
ここで、ｈａｎｄｌｅは、接続ハンドルである。ハンドルが動作中の接続でない場合は、コールはＥＢＡＤＦを返すようになる。そうでない場合、ＥＮＯＥＲＲＯＲは返され、状態情報ビットはｃｎＩｎｆｏ．ｃｎＳｔａｔｕｓ（詳細はｓ６４＿ｃｎＣｏｎｔｒｏｌ（）を参照）に設定される。
【００９８】
出力接続
一実施形態によれば、発信接続は、全てのプロトコルアドレス情報を指定したり、またはアドレス及び残りのプロトコル情報の代りにホストネームを指定することにより生成されることができる。例えば、１９２．１６８．１．５０における内部ウェブサーバーへの発信接続は、以下により確立される：
ipv4Addr serverAddr;
server Addr.ipv4_af=S64AF_IPV4;
server Addr.ipv4_flags=IPV4_TCP;
server Addr.ipv4_port=s64_htons(80);
server Addr.ipv4_addr=s64_htonl(0xC0A80138);
server Addr.ipv4_zero=0;
err=s64_connectAddr((s64c_connInfo*)&serverAddr,p);
【００９９】
ここで、ｐはアプリケーションが完了した要請を識別することを助けるアプリケーションにより提供される任意の不透明パラメータである。下記のプログラミングの例は、アプリケーションがこの不透明パラメータを利用する方法を示している。
【０１００】
戻り値は、要請が成功的に開始したかを表示する。一実施形態において、正常のリターンコードはＥＮＯＥＲＲＯＲである；また、ｓ６４＿ｃｏｎｎｅｃｔＡｄｄｒ（）はシステムが接続を直ちに開始するリソースがないということを表示するＥＡＧＡＩＮを返すことができる。要請は、後に再度試みることもできる。
【０１０１】
結果がｓ６４＿ｑＲｅａｄｙ（）から返された後にも、実際ネットワーク接続シーケンス（例えば、ＴＣＰの３−パケットハンドシェーク）が始まっていないこともある。しかし、ｑＮｅｔ接続ＡＰＩ及び通信アーキテクチャーの様々な実施形態によれば、接続が確立される前に、接続に読み出し及び／または記録要請をキューすることも許容される。例えば、サーバーに接続するとき、アプリケーションは接続を開始し、その後直ちに接続にＨＴＴＰ要請を含むバッファーにキューすることができる。するとこれは、下にあるネットワークインタフェースがＴＣＰ加速開放を支援する場合、転送の速度を増加させることもできる。
【０１０２】
一実施形態によれば、発信接続はさらにコールによって確立されることもできる：
err=s64_connectHost(name,(s64c_connInfo*)&serverAddr, p);
【０１０３】
ここで、ｎａｍｅはホストのネーム（例えば、ｗｗｗ．ｙａｈｏｏ．ｃｏｍ）であり、ｓｅｒｖｅｒＡｄｄｒはプロトコル−特定情報の残りを指定する。各々のアドレス／プロトコルファミリは、１つ以上のネームレゾリューション（ｎａｍｅ  ｒｅｓｏｌｕｔｉｏｎ）方式を用いることができる。一実施形態において、ＤＮＳは常に支援される。ＤＮＳにおいて、ＡＰＩコールはドメインネームをＤＮＳワイヤーフォーマットで変換した後、その要請をキューすることもできる。一実施形態において、ドメインネームは、ＲＦＣ  １０３５の規定に従うものと考えられる。そうでない場合、ＥＩＮＶＡＬが返される。ｓ６４＿ｃｏｎｎｅｃｔＡｄｄｒ（）のように、正常の戻り値はＥＮＯＥＲＲＯＲである；しかし、結果値は、ＤＮＳ決定（ｒｅｓｏｌｕｔｉｏｎ）が完了したりまたは失敗するまでに利用することができない。
【０１０４】
着信接続
一実施形態によれば、着信接続は、発信接続とは２つの方式において異なる。第１に、１つの着信接続要請に応答して、完了、つまり新たな接続の任意の数を持つことが可能である；第２に、完了が発生した時点を知ることが不可能である。
【０１０５】
一実施形態において、アプリケーションがｓ６４＿ａｃｃｅｐｔＡｄｄｒ（）を呼び出すことによって着信接続を受け入れるという意思を通知する。ＨＴＴＰポート（８０）で要請を受け入れるために、例示的なコード配列は、次のように表わすことができる：
ipv4.Addr svcAddr;
svcAddr.ipv4_af=S64AF_IPV4;
svcAddr.ipv4_flags=IPV4_TCP;
svcAddr.ipv4_port=s64_htons(80);
svcAddr.ipv4_addr=0;
svcAddr.ipv4_zero=0;
err=s64_acceptAddr(&svcAddr,p);
【０１０６】
ここで、ｓｖｃＡｄｄｒは、リモート装置から接続するのに用いられるＩＰ及びＴＣＰポートアドレスを指定する。ＩＰＶ４アドレスファミリで、ゼロのＩＰアドレスは、ＩＰＶ４を実行する全ての配信サービスに対して接続が受け入れられることを示すこともできる。他の関数と同様に、ｐはアプリケーションが新たな接続を識別することを助ける不透明パラメータである。一実施形態において、同一パラメータが規定されたサービスアドレスで全ての新たな接続のために返されるようになる。
【０１０７】
一旦ｓ６４＿ａｃｃｅｐｔＡｄｄｒ（）がコールされれば、１つ以上の接続完了はキューするようになる。ｓ６４＿ｃｏｎｎｅｃｔＡｄｄｒ（）及びｓ６４＿ｃｏｎｎｅｃｔＨｏｓｔ（）からの結果と類似するように、実際接続が完了しないこともある。しかし、遠隔アドレスは知っており、ハンドルは読み出し及び／または記録要請をキューするのに使用されることができる。サーバーがクライアントの要請を第１に読み出す正常的な場合、これはサーバーが直ちに利用できるデータを移動させることを許容する。
【０１０８】
接続Ｉ／Ｏ
様々な実施形態によれば、一旦接続ハンドルがアプリケーションに返されても、多ければ１つの読み出し及び１つの記録要請が接続に対して受け入れられるようになる。読み出し及び記録を始めるための関数コールの例は、次のとおりである：
err=s64_readConnection(handle,buf,len,p);
err=s64_writeConnection(handle,buf,len,p);
【０１０９】
ここで、ｈａｎｄｌｅは接続ハンドルであり；ｂｕｆ及びｌｅｎは、各々文字の適切に整列されたバッファーアドレス及びバッファーの長さである。具体的な実施形態によって、読み出し及び記録要請の動作は互いに異なることもある。
【０１１０】
例えば、読み出し要請が完了した場合、バイト読み出しの回数は、要請された大きさ未満であることもあり−ネットワーキングシステムは、読み出しが完了したと宣言する前にバッファーがいっぱいになることを必ずしも待つのではない。一方、一実施形態で読み出しデータは完了をキューする前に規定されたバッファーに伝達された。従って、アプリケーションは、対応する読み出し要請完了をデーキュ（ｄｅｑｕｅｕｅ）した後すぐにデータを直ちに処理し始めることができる。
【０１１１】
対照的に、一実施形態では、記録要請が完結した場合、ネットワーキングシステムは、エラーがない場合、アプリケーションバッファーからの全てのデータがそのメモリに複写されたことを保証する。従って、アプリケーションは、転送に影響を及ぼすことなくバッファーで値を変更することができる。また一実施形態では、データが接続に記録された順に転送されることが保証される。しかし、どのデータがネットワークを介して転送されたということは保証されない。
【０１１２】
接続遮断
この例によれば、確立された接続を遮断する必要がある場合、そのために２つのコールがｑＮｅｔ接続ＡＰＩにより提供され：
err=s64_connectClose(handle,param);
【０１１３】
これはこれ以上の読み出し及び記録のために接続を遮断するが、全ての以前に記録されたデータを伝達するように試み、さらに、
err=s64_connectReset(handle,param);
【０１１４】
またこれは、これ以上の読み出し及び記録のために接続を遮断するが、全ての以前に記録されたデータを廃棄できる。一実施形態によれば、接続が遮断されたり、再設定（ｒｅｓｅｔ）されてどのペンディングＩ／Ｏ動作もない場合、戻り値はＥＮＯＥＲＲＯＲになる；また、どの結果もその動作のためにキューしない。しかし、ペンディング動作が存在する場合は、例えば接続がタイムアウトのため中断される（ａｂｏｒｔｅｄ）：
【０１１５】
・ペンディング要請が終了するようになる（ところが下記参照）。どの読み出しデータも廃棄されるようになる。接続が再設定されていない場合、記録データの一部、何もまたは全ては、ネットワークバッファーに複写されることができ、転送に利用することができる。
【０１１６】
・完了した要請は、完了キュー（例えば、ペンディングイベントキュー５８０）から除去されるようになり、そして、それらの結果がｓ６４＿ｑＲｅａｄｙ（）を介してアプリケーションに返されない。
【０１１７】
・コールはＥＩＮＰＲＯＧＲＥＳＳを返すようになる。これはアプリケーションが要請で通過されたパラメータでタグされた結果を待つ必要があることを意味する。この結果は、データ転送が非動作状態であり、さらに、その要請で関連のバッファーが間違いなく空いているか使用中であることを信号する。
【０１１８】
ハンドルが実際遮断されない場合も、そのハンドルに利用可能な唯一の動作は、その状態をクエリーすることである。結果がペンディングイベントキュー５８０から読み出される場合、システムはハンドルを遮断しており、アプリケーションは遮断したりまたは再び再設定する必要がない（不可能である）。
【０１１９】
マルチプロセッサー構成において、１つのプロセッサーが別のプロセッサーで遮断される要請に対して結果を得ることが可能である。アプリケーションは、接続が遮断されたりペンディングＩ／Ｏに再設定される場合、この競合状態に備える必要がある。可能な解決策は、単に「デッド（ｄｅａｄ）」でその接続を表示し、完了ハンドラーが実際遮断を実行するようにすることである。
【０１２０】
新たな接続を受け入れるのを中断するために、アプリケーションは次の形態でコールを行うことができる：
err=S64_closeAddr(&ipAddr);
【０１２１】
ここで、ｉｐＡｄｄｒはシャットダウン（ｓｈｕｔ  ｄｏｗｎ）するＩＰ及びポートアドレスである。ｓ６４＿ａｃｃｅｐｔＡｄｄｒ（）をコールする場合、ＩＰアドレスが０である場合には、ポートは全ての装置インターフェに対してシャットダウンされる。どの接続完了も結果キューから除去されるようになる；発信接続を遮断するのと類似するように、これにより接続結果を読み出すことと着信要請をディスエーブル（ｄｉｓａｂｌｅ）にすることの間にはＭＰ競合状態が存在し得る。
【０１２２】
プログラミングの例
本明細書に記載のｑＮｅｔ接続ＡＰＩ及び通信構造の実施形態は、次の条件のうちの１つ以上を保障することにより、ＢＳＤソケットインタフェースの様々な欠点を解決するものである：
【０１２３】
・要請が完了したとき、関連データは既に送信されたか受信されている。
【０１２４】
・完了した要請は、完了順に返され、公正なラウンドロビンスケジューリングを保証する。
【０１２５】
・マルチプロセッサーは自然に接続をキューすることができ、カーネルが要求するもの以上のロック（ｌｏｃｋｉｎｇ）なしに、接続を獲得できる：多くの設計において、これはロック及び競合の量を実質的に減らし、マルチプロセッサースケーリングを向上させる。
【０１２６】
次のコードの例は、単にｑＮｅｔ接続ＡＰＩの実施形態の効果を示すもので、基本的な説明である。このサンプルアプリケーションにおいて、サーバーは１つの着信接続を許容し、入力データを処理し、応答を送信し、その後再びリッスンとなる（ｌｉｓｔｅｎ）。動作（ｔｈｉｎｇｓ）はコールすることにより開始される：
ipv4Addr myPort={S64C_IPV4,IPV4_TCP,MY_PORT,0,0};
s64_acceptAddr(&myPort,(s64c_param)&myStruct);
【０１２７】
ここで、ｍｙＳｔｒｕｃｔは、状態マシンで次の段階を処理するため、特に関数ポインターを含むことができる構造体（ｓｔｒｕｃｔ  ｓｔａｔｅＳｔｒｕｃｔ）を処理するアプリケーションの状態である。プロセシングのための制御ループは、極めて単純である：
extern int keepOnTrucking;  //プロセシングを続くためのグローバルフラグ
do{
struct s64c_qr q;
struct stateStruct*me;
q=s64_qReady();
if(q.qrHandle!=S64C_NOHANDLE){
me=(struct stateStruct*)q.param;
(*me-＞nextState)(me,&q);
}
}while(keepOnTrucking);
【０１２８】
キューイング要請でパスされたパラメータがアプリケーションの過接続状態構造体を唯一に識別する限り、ループは単純であるが、マルチプロセシングのために如何なる変更も必要なく、さらに、ループを多重接続のために変更する必要がないということに注意されたい。
【０１２９】
また、他の例として、それぞれの接続のためのプロセシングがその接続に関するＩ／Ｏイベントにより大きいが全て駆動されない、多重接続を管理するループを考慮する。この場合において、制御ループは類似しており、次のような形態を有してもよい：
do{
struct s64c_qr q;
struct stateStruct*me;
q=s64_qReady();
if(q.handle==S64C_NOHANDLE)
break;
me=(struct stateStruct*)q.param;
(*me-＞complete)(me,&q);
}while(1);
processConnections();
【０１３０】
この例における主な差異の１つは、状態ルーチンが単にその完了を処理することである；より長いプロセシングは、現在ｐｒｏｃｅｓｓＣｏｎｎｅｃｔｉｏｎｓ（）により呼び出される。しかし、どのプロセッサーでも完了した要請及びプロセス接続を獲得することができるので、１つのプロセッサーまたはコアの長い演算で使用中である場合には、他の接続は依然継続して行うことができる。
【０１３１】
普遍性の喪失なしに、本明細書に言及するいろいろの定義された定数、タイプ、状態コード、制御インターフェース、ＦＩＦＯ、キューイング（ｑｕｅｕｉｎｇ）構造体、接続インタフェース、Ｉ／Ｏインタフェース、結果及び状態インタフェース、マルチプロセッサーのロックを本発明の一実施形態により説明する。当業者であれば、より多くの、またはより少ないインタフェースが提供できることが理解できる。
【０１３２】
定義された定数
Ｓ６４Ｃ＿ＮＯＨＡＮＤＬＥ    保証された無効の接続ハンドル値。
【０１３３】
タイプ
s64c_block  システムＮＶＲＡＭのブロック番号。
s64c_count  データ転送カウント。
s64c_port  １６ビットＴＣＰまたはＵＤＰポートナンバー。
s64c_flag  ＡＰＩ関数に対する多様なフラグ。
s64c_handle  接続のための３２ビットシステムＩＤ。
s64c_param  不透明なパラメータのパターン；一実施形態で、ポインターを維持するほど充分大きく保証される。
s64c_service  ６４ビット配信サービス識別子。
s64c_status  ＡＰＩまたは要請完了コード。
s64c_tmo  タイムアウト値、秒単位。
【０１３４】
状態コード
EAGAIN  システムが現在この要請を受け入れることはできず、再び試みることは可能である。
EBADF  無効の接続ハンドル。
EBUSY  接続または配信サービスの使用中。
ECONNABORTED  接続が中断される。
ECONNREFUSED  接続拒否。
ECONNRESET  接続が再設定される。
EINPROGRESS  動作が進行中。
EINVAL  無効のパラメータまたは動作。
ENETDOWN  規定されたネットワークがダウンする。
ENETUNREACH  規定されたネットワークが到達不可能。
ENOTCONN  規定されたハンドルが接続されない。
ENODEV  有効の配信サービスが発見されない。
ENOERROR  コマンドまたは要請がエラーなしに完了する。
ENOSPC  動作を完了するのに不十分なメモリまたはテーブル空間。
EPIPE  ピアによりシャットダウンまたは遮断された接続を記録する。
ETIMEDOUT  動作または接続タイムアウト。
【０１３５】
制御インターフェース
【０１３６】
s64_afControll()
s64c_status
s64_afControl(const u64 cmd,s64c_connInfo *info)
【０１３７】
ｉｎｆｏにより指定されたアドレスファミリに関する情報を獲得したりまたは設定する。アドレスファミリ、例えばＩＰＶ４に対して識別するタグは、ｑＮｅｔインタフェースファイルに定義されることができる。以下のコマンドは、全てのアドレスファミリに対して定義されることができる：
【０１３８】
AF_QUERY  このコマンドは、ｃｉＩｎｆｏ［］フィールドに説明的な文字列を返す。このコマンドは、ある特定のアドレスファミリが支援されるかをチェックするのに使用される。
【０１３９】
AF_CACHE  このコマンドは、プロトコル−特定のフォーマットで、規定のアドレスが重要でありそれに対する情報、例えば関連ＭＡＣアドレスは、高い優先順位でキャッシュ（ｃａｃｈｅ）されなければならない、アドレスファミリにアプリケーションが知らせるのを許容する。アドレスファミリ及び／または下位配信サービス（ｓ）は、このコマンドを静かに無視してもよい。
【０１４０】
一実施形態において、全ての他のコマンドは、特定のアドレスファミリとして、ｉｎｆｏポインターを通じてパスされたり、返された値である。
【０１４１】
戻り値：
ENODEV  規定されたアドレスファミリが存在しない。
EBUSY  規定されたコマンドは、通常、１つ以上の関連配信サービスがイネーブル（ｅｎａｂｌｅ）になるため、実行できない。
EINVAL  Ｉｎｆｏパラメータが無効。
EINVAL  コマンドが規定されたアドレスファミリに対して有効でない。
EINVAL  情報アドレスは無効である。
【０１４２】
結果値：
これは同期要請である：如何なる結果も返されない。
【０１４３】
s64_dsControl()
s64c_status
s64_dsControl(const u64 ds,const u64 cmd,s64c_connInfo *info)
【０１４４】
規定の配信サービス及びｉｄｅｎｔｉｔｙに関する情報を獲得したりまたは設定する。配信サービスは、ゼロ（０）から開始して細かくナンバリングされ、それがｉｄｅｎｔｉｔｙになる。以下のコマンドは、全ての配信サービスに対して定義される：
【０１４５】
DS_QUERY  このコマンドは配信サービスに関する次の情報を返す：
Typedef struct{
u8  dsAF;  //プロトコル／アドレスファミリ。
u8  dsInstance;  //この配信サービスのインストンス。
u8  dsEnable;  //0=disabled
u8  dsInfo[13];  //ＮＵＬ−終了した説明（ｄｅｓｃｒｉｐｔｉｏｎ）。
}s64c_dsInfo ALIGNED_DECL(8);
このコマンドは、ある特定の配信サービス及びｉｄｅｎｔｉｔｙが存在するかどうかをチェックするときに使用される。
【０１４６】
DS_NIC  このコマンドは、配信サービスハードウェアに関する次の情報を返す：
Typedef struct{
u8  dsAF;  //プロトコル／アドレスファミリ。
u8  dsMAC[6];  //ハードウェアＭＡＣアドレス。
u8  dsNIC[9];  //ＮＵＬ−終了された説明。
}s64c_dsNIC  ALIGNED_DECL(8);
このコマンドは、ある特定の配信サービス及びｉｄｅｎｔｉｔｙが存在するかどうかをチェックするときに使用される。
【０１４７】
DS_ENABLE  このコマンドは、関連配信サービスをイネーブルする。配信サービスは、それらのアドレスが構成されるときイネーブルされ、さらに、イネーブルされれば、アドレスを変更できないことに注意されたい。ｉｎｆｏパラメータは無視されてもよく、ＮＵＬＬであってもよい。
【０１４８】
DS_DISABLE  このコマンドは、関連配信サービスをディスエーブルする。配信サービスをディスエーブルする場合、その構成を変更することができない。ｉｎｆｏパラメータは無視されてもよく、ＮＵＬＬであってもよい。
【０１４９】
DS_CLEAR  このコマンドは、配信サービスに係わるａｄｄｒｅｓｓｉｎｇ情報、例えばＡＲＰキャッシュを消去する。ｉｎｆｏパラメータは無視されてもよく、ＮＵＬＬであってもよい。
【０１５０】
この例によれば、全ての他のコマンドは配信特定的であり、それはｉｎｆｏポインターを通じてパスされたり返された値である。
【０１５１】
戻り値：
ENODEV  規定の配信が存在しない。
EBUSY  規定のコマンドは実行することができず、通常、配信サービスはイネーブルされる。
EINVAL  入力アドレスファミリまたはパラメータは有効でないか認められない。
EINVAL  規定の配信サービスに対してコマンドが有効ではない。
【０１５２】
結果値：
これは同期的な要請である：どのような結果も返されない。
【０１５３】
s64_cnControl()
s64c_status
s64_cnControl(s64c_handleh,const u64 cmd,s64c_connInfo *info)
【０１５４】
規定の配信サービス及びｉｄｅｎｔｉｔｙに関する情報を獲得したり設定する。次のコマンドは全ての接続に対して定義される：
【０１５５】
CN_QUERY  このコマンドは接続に関する次の情報を返す：
Typedef struct{
u8  cnAF;  //プロトコル／アドレスファミリ
u8  cnFlags;  //プロトコル−依存フラグ
u16  nDS;  //配信サービス及びｉｄｅｎｔｉｔｙ
u32  cnStatus;  //接続状態
u64  cnInfo;  //プロトコル−特定情報
}s64c_cnInfo;
【０１５６】
CN_SHUTDOWN  後続記録が受け入れられないように接続を設定する。下位プロトコルが許容される場合、全てのデータが転送された後にｅｎｄ−ｏｆ−ｄａｔａ信号を送信する。記録ペンディングである場合は、正常に完了するようになる。ｉｎｆｏパラメータは無視されてもよく、ＮＵＬＬであってもよい。
【０１５７】
ＣＮ＿ＱＵＥＲＹにおいて、ｃｎＡＦは接続のアドレスファミリであり、ｃｎＦｌａｇｓはプロトコル−依存情報である。ｃｎＤＳは配信サービス及びｉｄｅｎｔｉｔｙである。ｃｎＳｔａｔｕｓは接続状態である；ビットは次のように設定される：
【０１５８】
S64C_CONN_FAILED  接続の完了が失敗。
S64C_CONN_CLOSED  接続はリモート装置または他のエラーによって遮断。
S64C_READ_PENDING  読み出し要請はペンディング中。
S64C_READ_DONE  読み出し要請が完了し、結果が利用可能。
S64C_WRITE_PENDING  記録要請はペンディング中。
S64C_WRITE_DONE  記録要請が完了し、結果が利用可能。
【０１５９】
一実施形態において、接続状態ビットは相互に排他的である；何も設定されない場合は、接続は動作中である。
【０１６０】
一実施形態において、読み出し状態ビットは相互に排他的である；何も設定されない場合は、ペンディング中であるか完了した読み出し要請がない。
【０１６１】
一実施形態において、記録状態ビットは相互に排他的である；何も設定されない場合は、ペンディング中であるか完了した記録要請がない。
【０１６２】
この例によれば、全ての他のコマンドは、アドレスファミリまたは配信−サービス特定的に、ｉｎｆｏを通じてパスされたり返された値である。
【０１６３】
戻り値：
EBADF  無効の接続ハンドル。
EINPROGRESS  記録または記録結果がペンディング状態で接続がシャットダウン。
EINVAL  ｉｎｆｏアドレスは無効。
【０１６４】
結果値：
これは同期的な要請である：どのような結果も返されない。
【０１６５】
接続インタフェース
【０１６６】
s64_connectAddr()
s64c_status
s64_connectAddr(s64c_connInfo *dest,s64c_param param)
【０１６７】
一実施形態によれば、ｓ６４＿ｃｏｎｎｅｃｔＡｄｄｒ（）は、規定のアドレスに接続を開始する。構造体がアドレスファミリ依存的であれば、アドレスファミリは残りを説明するｄｅｓｔの第１のフィールドに規定される。ｔｙｐｅパラメータは確立される接続のパターンを定義するアドレス−ファミリ特定の値である。結果は適切なネットワークインタフェースが要請を始めるとすぐに利用することができる。これはネットワーク接続がまだ完了していないこともあり得ることを意味する；しかし、ハンドルは、読み出し及び／または記録を開始するのに使用される。
【０１６８】
接続要求が失敗である場合（ｑｒＳｔａｔｕｓ！＝ＥＮＯＥＲＲＯＲ）、ハンドルは無効である：遮断することを含めて如何なるこれ以上の動作も開始することができない。
【０１６９】
戻り値：
ENOEROR  正常の戻り値：接続要請が成功的に開始。
EAGAIN  システムがすぐに接続を生成するリソースを有していない。要請は後で試みることができる。
ENODEV  規定のアドレスファミリが支援されない。
EINVAL  規定のアドレスが有効ではない。
ENETDOWN  要請された配信サービスがイネーブルされていない。
ENETUNREACH  規定のアドレスがこのシステムから到着されることができない。
【０１７０】
コマンド−特定の結果値：
qrInfos  ６４ｃ＿ｃｏｎｎＩｎｆｏ構造体。ｃｉＡＦはアドレスファミリを示す；構造体の残りがプロトコル−特定的である。
【０１７１】
結果状態：
ENOERROR  接続はエラーなく開始され、Ｉ／Ｏに利用することができる。
EAGAIN  ネットワークインタフェースは、すぐに接続を生成するリソースを有していない。要請は後で試みることができる。
ENETUNREACH  規定のＩＰアドレスが到着されることができない。
ECONREFUSED  規定のホストが接続を許容することを拒否した。
ECONABORTED  規定のホストが接続を中断した。
ECONRESET  規定のホストが接続を再設定した。
ETIMEDOUT  接続がタイムアウトされた。
【０１７２】
実施注釈：
一実施形態において、ハンドルが成功的に返されれば、接続が実際に完了したように全ての面で見なされることができる。
【０１７３】
読み出しまたは記録要請をキューし、接続が失敗する場合、その関連状態があるペンディングＩ／Ｏ要請に対する結果に反映されることができる。
【０１７４】
s64_connectHost()
s64c_status
s64_connectHost(char *host,s64c_connInfo*addr,s64c_param param)
【０１７５】
一実施形態によれば、ｓ６４＿ｃｏｎｎｅｃｔＨｏｓｔ（）は、ａｄｄｒからアドレス−ファミリ特定のパラメータを利用して、規定のホストネームへの接続を生成する。一実施形態において、ホストネームは、ＲＦＣ１０３５の規定に従わなければならない。結果は、ＤＮＳ決定が完了すればすぐに利用することができ、適当なネットワークインタフェースがその要請を開始する。これは、ネットワーク接続がまだ完了していないこともあり得ることを意味する；しかし、ＩＰアドレスは有効であり、ハンドルは読み出し及び／または記録を開始するのに使用できる。
【０１７６】
接続要求が失敗する場合（ｑｒＳｔａｔｕｓ！＝ＥＮＯＥＲＲＯＲ）、ハンドルは無効である：遮断することを含めて如何なるこれ以上の動作も開始されない。
【０１７７】
戻り値：
ENOERROR  要請が非同期であるので、正常の戻り値。
ENODEV  規定のアドレスファミリが支援されない。
EAGAIN  システムはＤＮＳ決定のための、直ちに接続を生成するためのリソースを有していない。要請は後で試みることができる。
ENETDOWN  要求された配信サービスがイネーブルされない。
ENETUNREACH  ＤＮＳはシステム上に構成されない。
EINVAL  規定のホストネームは合法的なＤＮＳネーム（ＲＦＣ  １０３５を詳細に参照）ではない。
【０１７８】
コマンド−特定の結果値：
ｑｒＩｎｆｏ    ｓ６４ｃ＿ｃｏｎｎＩｎｆｏ構造体。ｃｉＡＦはアドレスファミリを示す；構造体の残りはプロトコル特定的である。
【０１７９】
結果状態：
ENOERROR  接続はエラーなしに開始され、Ｉ／Ｏに用いることができる。
EAGAIN  ネットワークインターフェースは、ＤＮＳ決定のための、直ちに接続を生成するためのリソースを有していない。要請は後で試みることができる。
EINVAL  ホストネームはＤＮＳで決定されることができない。
ETIMEDOUT  ＤＮＳ決定が失敗したりまたは接続の試みがタイムアウトされる。
ENETDOWN  要請された配信サービスがイネーブルされない。
ENETUNREACH  規定のホストアドレスが到着されることができない。
ECONREFUSED  規定のホストが接続を許容することを拒否した。
ECONABORTED  規定のホストが接続を中断した。
ECONRESET  規定のホストが接続を再設定した：
【０１８０】
実施注釈：
一実施形態において、ネットワークシステムは、アプリケーションをブロック化せずにＤＮＳルックアップを完了する。その完了結果は、ＩＰアドレスが知られたり、またはＤＮＳルックアップが失敗した後に用いることができる。
【０１８１】
一実施形態において、システムは（可能な場合）速度を向上させるためにＤＮＳキャッシュを行うものである。
【０１８２】
s64_acceptAddr()
s64c_status
s64_acceptAddr(s64c_connInfo *addr,s64c_param param,)
【０１８３】
一実施形態によれば、ｓ６４＿ａｃｃｅｐｔＡｄｄｒ（）は規定のアドレスで着信接続の通知をイネーブルする。そのアドレスプロトコル−特定のワイルドカードアドレスであれば、着信接続が規定のアドレスファミリを支援する全ての配信サービスに対して受け入れるようになる；そうでない場合は、そのアドレスは、ローカル配信サービスと仮定され、接続を規定のポートでそのときまで受け入れない。それぞれの着信接続に対して、別個の接続結果がキューされるようになる；しかし、一実施形態において、それぞれは同一の不透明パラメータを返す。
【０１８４】
戻り値：
ENOERROR  正常の戻り値。
ENODEV  規定のアドレスファミリが支援されない。
EAGAIN  システムが直ちに接続を生成するリソースを有していない。要請は後で試みることができる。
ENETDOWN  要請された配信サービスがイネーブルされない。
ENETUNREACH  ＤＮＳがシステム上に構成されない。
EINVAL  規定のアドレスはシステムアドレスでないか無効である。
【０１８５】
コマンド−特定の結果値：
qrInfo  ｓ６４ｃ＿ｃｏｎｎＩｎｆｏ構造体。ｃｉＡＦはアドレスファミリを示す。この構造体の残りはプロトコル−特定的である。
【０１８６】
（各々の着信接続に対する）結果状態：
ENOERROR  接続がエラーなしに割り当てられ、Ｉ／Ｏに用いることができる。
EAGAIN  ネットワークインタフェースがその規定のポートに対して接続を直ちに受け入れるリソースを有していない。要請は後で試みることができる。
EBUSY  規定のＩＰ及びポートは使用中である。
【０１８７】
実施注釈：
一実施形態によれば、ネットワーキングシステムがｓ６４＿ｃｏｎｔｒｏｌＩＰ（）コールにより指定されたＩＰアドレスを断るようになり、不十分なリソースが利用できる場合、接続を無視したりドロップすることもある。性能統計は、このイベントに対してカウンターを含むことができる。
【０１８８】
実際に、ネットワークシステムは、着信接続が受け入れることができるポートの数を制限することができる；しかし、好ましくは、システムＩＰアドレスあたり８個の可用ポートだけ存在する。
【０１８９】
Ｉ／Ｏインタフェース
【０１９０】
s64_readConnection()
s64c_status
s64_readConnection(s64c_handleh,void *buf,s64c_count len,s64c_param p)
【０１９１】
一実施形態によれば、ｓ６４＿ｒｅａｄＣｏｎｎｅｃｔｉｏｎ（）は、規定のハンドルで読み出し要請をキューする。要請が完了としてキューする前に、接続のｌｅｎバイトまで１６バイトで整列されたｂｕｆに転送される；しかし、システムは、システム−特定的な（ｓｙｓｔｅｍ−ｓｐｅｃｉｆｉｃ）理由のため、少ないデータを送ることが可能である。
【０１９２】
戻り値：
ENOERROR  読み出しが成功的に開始した。
EAGAIN  システムが直ちに要請をキューするためのリソースを持たない。要請は後で試みることができる。
EBADF  無効の接続ハンドル
EINVAL  規定のバッファーが誤整列されるかまたは無効のアドレスである。
EINPROGRESS  第１の要請が完了する前に、第２の読み出し要請が行われる。
ENOTCONN  ハンドルがこれ以上接続されない。
【０１９３】
コマンド−特定の結果値：
qrBSize  最初のバッファー大きさ
qrCount  バッファー（ｓｔａｔｕｓ＝＝ＥＮＯＥＲＲＯＲ）に転送されたバイトの数。ゼロである場合、ｅｎｄ−ｏｆ−ｄａｔａがその接続を介して信号される。
qrToken  プロトコル特定の６４−ｂｉｔトークン。
【０１９４】
結果状態：
ENOERROR  読み出しがエラーなしに完了;しかし、本来の要請されたものより少ないバイトが転送されることが可能である。
ECONABORTED  ホストが接続を中断した。
ECONRESET  ホストがその接続を再設定した。
ENOTCONN  ハンドルがこれ以上接続されない。
【０１９５】
実施注釈：
一実施形態によれば、要請が受け入れられた後、接続が中断される場合、読み出しがＥＮＯＴＣＯＮＮで完了することができる。例えば、その接続を完了することに失敗した場合、接続からの第１の読み出しは、この状態を返すようになる。
【０１９６】
s64_writeConnection()
s64c_status
s64_writeConnection(s64c_handleh,void *buf,s64c_count len,s64c_param p)
【０１９７】
一実施形態によれば、ｓ６４＿ｗｒｉｔｅＣｏｎｎｅｃｔｉｏｎ（）は、規定のハンドルで記録要請をキューする。結果を利用する前に、接続のｌｅｎバイトが１６バイトに整列されたｂｕｆに転送される。成功的な結果（ｓｔａｔｕｓ＝＝ＥＮＯＥＲＲＯＲ）が返される場合、ネットワークインタフェースがデータのｔａｋｅｎ  ｃｕｓｔｏｄｙを有することを意味する：アプリケーションは、ネットワークに転送されるデータに影響を及ぼすことなくバッファーを再利用することができる。全てのデータがキューの順にその接続を介して転送される。
【０１９８】
戻り値：
ENOERROR  正常の戻り値。
EAGAIN  システムが要請を直ちにキューするためのリソースを持たない。要請は後で試みることができる。
EBADF  無効の接続ハンドル
EINVAL  規定のバッファーが誤整列されるかまたは無効のアドレスである。
EINPROGRESS  ペンディング要請が完了する前に、第２の記録要請が行われる。
EPIPE  データがシャットダウンした接続で記録される。
EPIPE  データが他のペンディングデータなしに中断した接続で記録される。
【０１９９】
コマンド−特定の結果値：
qrBSize  最初のバッファー大きさ
qrCount  バッファーから転送されたバイトの数。如何なるエラーもない場合、常にｑｒＢＳｉｚｅと等しい。
qrToken  常にゼロ（０ｘ０）。
【０２００】
結果状態：
ENOERROR  エラーなしに記録が完了した。
EPIPE  データが他のペンディングデータなしに中断した接続で記録される。
ECONABORTED  ホストが接続を中断させる。
ECONRESET  ホストが接続を再設定する；他のデータがペンディングされる。
【０２０１】
実施注釈：
一実施形態において、その要請がキューの後で接続が中断される場合、記録はＥＰＩＰＥで完了することができる。特に、その接続が完了することに失敗する場合は、接続で第１の記録がそれを返すようになる。
【０２０２】
s64_sendConnection()
s64c_status
s64_sendConnection(s64c_handleh,void*buf,s64c_sendInfo*sp, s64c_param p)
【０２０３】
一実施形態によれば、ｓ６４＿ｓｅｎｄＣｏｎｎｅｃｔｉｏｎ（）は、規定のハンドルで値によってｓｐで記録要請をキューする。転送パラメータは、次のような構造体である：
typedef struct{
u8  send_af;  //プロトコル／アドレスファミリ。
u8  send_flags;  //プロトコル−または関数−依存フラグ。
u16  send_data;  //プロトコル−または関数−依存フラグ。
u32  send_len;  //転送長さ。
u64  send_token;  //プロトコル−依存トークン。
}s64c_sendInfo ALIGNED_DECL(8);
【０２０４】
結果を用いることができる前に、データのｓｐ−＞ｓｅｎｄ＿ｌｅｎバイトが規定されたｂｕｆから転送される。成功的な結果（ｓｔａｔｕｓ＝＝ＥＮＯＥＲＲＯＲ）が返される場合、ネットワークインタフェースがデータのｔａｋｅｎ  ｃｕｓｔｏｄｙを持つと言う：アプリケーションは、ネットワークに転送されるデータに影響を及ぼすことなくバッファーを再利用することができる。全てのデータがキューの順にその接続を介して転送される。
【０２０５】
それぞれのプロトコルファミリで、全てのコネクションの形態がｓ６４＿ｓｅｎｄＣｏｎｎｅｃｔｉｏｎ（）を支援しない場合もある。例えば、ＩＰＶ４下ではＴＣＰ接続が行われない；ところが、ＵＤＰエンドポイントが行う。
【０２０６】
戻り値：
ENOERROR  正常の戻り値。
EAGAIN  システムが要請を直ちにキューするためのリソースを持たない。要請は後で試みることができる。
EBADF  無効の接続ハンドル
EINVAL  規定の接続がｓ６４＿ｓｅｎｄＣｏｎｎｅｃｔｉｏｎ（）を支援しない。
EINVAL  規定のバッファーが誤整列されるかまたは無効のアドレスである。
EINPROGRESS  ペンディング要請が完了する前に、第２の記録要請が行われる。
EISCONN  転送がコネクション志向ハンドル（例えば、ＴＣＰ）で試みられる。
EPIPE  データがシャットダウンした接続で記録される。
EPIPE  データが他のペンディングデータなしに中断された接続で記録される。
【０２０７】
コマンド−特定の結果値：
qrBSize  最初のバッファー大きさ。
qrCount  バッファーから転送されたバイトの数。何のエラーもない場合、常にｑｒＢＳｉｚｅと等しい。
qrToken  常にゼロ（０ｘ０）。
【０２０８】
結果状態：
ENOERROR  エラーなしに記録が完了する。
EPIPE  データが他のペンディングデータなしに中断された接続で記録される。
ECONABORTED  ホストが接続を中断させる。
ECONRESET  ホストが接続を再設定した；他のデータがペンディングされる。
【０２０９】
実施注釈：
一実施形態において、その要請がキューの後で接続が中断される場合、記録はＥＰＩＰＥで完了することができる。特に、その接続が完了することに失敗する場合は、接続で第１の記録がそれを返すようになる。
【０２１０】
s64_passThru()
s64c_status
s64_passThru(s64c_handle src,s64c_handle dst,s64c_param p)
【０２１１】
一実施形態によれば、ｓ６４＿ｐａｓｓＴｈｒｕ（）は、ハンドルｓｒｃの入力からハンドルｄｓｔの出力までデータをすぐに通過させるために、要請をキューする。ネットワークサブシステムは、データをできるかぎり效率的に転送する。結果ハンドルはｓｒｃになり、バッファー大きさ及びバイトカウントの両方は、プロトコルヘッダーを除いてパススルーされた（ｐａｓｓｅｄ  ｔｈｒｕ）データバイトの数を反映することができる。
【０２１２】
データが直接２つのハンドルの間にパスされるかどうかは、対応する配信サービス及び接続パターンの実現に依存する。一般的に、他の識別子、他のタイプの接続及び多重送信された（ｍｕｌｔｉｐｌｅｘｅｄ）接続（例えば、ＩＰＶ４のＵＤＰ）による配信サービスは、パススルー（ｐａｓｓ−ｔｈｒｕ）を支援しないこともある。
【０２１３】
戻り値：
ENOERROR  正常の戻り値。
EAGAIN  システムが要請を直ちにキューするためのリソースを持たない。要請は後で試みることができる。
EBADF  無効の接続ハンドル
EINVAL  パススルー（Ｐａｓｓ−ｔｈｒｕ）モードが規定されたハンドルの間に支援されない。
EINPROGRESS  ペンディング要請が完了する前に、第２のパススルー（ｐａｓｓ−ｔｈｒｕ）要請が行われる。
EINPROGRESS  読み出しが既にソースハンドルにペンディング中である。
EINPROGRESS  記録が既に受信先ハンドルにペンディング中である。
EPIPE  データがシャットダウンされた接続で記録された。
EPIPE  データが、ペンディングデータなしに、シャットダウンまたは中断された接続で記録された。
【０２１４】
コマンド−特定の結果値：
qrBSize  受信先ハンドルにパスされたデータバイト。
qrCount  バッファーから転送されたバイトの数。一実施形態において、何のエラーもない場合、常にｑｒＢＳｉｚｅと等しくなる。
QrToken  プロトコル特定の６４−ｂｉｔトークン。
【０２１５】
結果状態：
ENOERROR  エラーなしに記録が完了する。
EPIPE  データが他のペンディングデータなしに中断された接続で記録される。
ECONABORTED  ホストが接続を中断させる。
ECONRESET  ホストが接続を再設定する；他のデータがペンディング中である。
【０２１６】
結果及び状態インタフェース
【０２１７】
s64_qReady()
s64c_qr
s64_qReady(void)
【０２１８】
一実施形態によれば、ｓ６４＿ｑＲｅａｄｙ（）は準備中のキュー（例えば、ペンディングイベントキュー５８０）で次の完了した要請を取る。直ちに利用可能な如何なる結果もない場合は、返還状態のハンドルがＳ６４Ｃ＿ＮＯＨＡＮＤＬＥになる。そうでない場合は、フィールドｑｒＰａｒａｍ及びｑｒＳｔａｔｕｓは常に設定するようになる；他の動作−依存情報は、ｑｒＩｎｆｏ構造体の状態と結合（ｕｎｉｏｎ’ｄ）されてもよい。
【０２１９】
制御インターフェース
【０２２０】
s64_connectClose()
s64c_status
s64_connectClose(s64c_handle handle,s64c_param p)
【０２２１】
一実施形態によれば、ｓ６４＿ｃｏｎｎｅｃｔＣｌｏｓｅ（）は規定の接続を遮断する。接続が遮断されたとき、データが空になるかまたは接続が中断されるまで、システムはキュー（ｑｕｅｕｅｄ）データを継続して転送するようになる。
【０２２２】
ペンディング読み出しまたは記録動作がなく、さらにどの結果もキューされないとき、ｓ６４＿ｃｏｎｎｅｃｔＣｌｏｓｅ（）は、ＥＮＯＥＲＲＯＲを返し、これ以上の結果がそのハンドルで利用できなくなる。この場合、６４ビット不透明パラメータｐは無視される。
【０２２３】
ペンディング読み出しまたは利用できる読み出し結果が存在する場合、ｓ６４＿ｃｏｎｎｅｃｔＣｌｏｓｅＱは、ＥＮＯＥＲＲＯＲの代りにＥＩＮＰＲＯＧＲＥＳＳを返す。ネットワークは、正常の結果を返す前に、エラーの有無に関係なく読み出しのために０以上のバイトを転送することもある。
【０２２４】
ペンディング記録または利用できる記録結果が存在する場合、ｓ６４＿ｃｏｎｎｅｃｔＣｌｏｓｅ（）は、ＥＮＯＥＲＲＯＲの代りにＥＩＮＰＲＯＧＲＥＳＳを返す。一実施形態において、ネットワークは正常の結果を返す前に、エラーの有無に関係なく記録転送を完了するようになる。
【０２２５】
１つ以上の動作がペンディング中であり、及び／または結果がキューされる場合、結果メッセージがｓ６４＿ｃｏｎｎｅｃｔＣｌｏｓｅ（）コールに規定されたパラメータでキューされてもよい。この結果は、接続のための全ての他の結果以降にキューされてもよく、接続が停止して遮断されることを示す。
【０２２６】
戻り値：
ENOERROR  接続ハンドルはシステム呼び出しに対してこれ以上有効ではない；そのハンドルに対する後続動作は、ＥＢＡＤＦを返すようになる。
EINPROGRESS  動作がペンディング中であり、及び／または結果をその接続に用いることができる；アプリケーションは完了を待たなければならない（以下参照）。接続ハンドルがシステム呼び出しに対してこれ以上有効ではない。そのハンドルで後続動作はＥＢＡＤＦを返してもよい。
EBADF  無効の接続ハンドル
【０２２７】
（ＥＩＮＰＲＯＧＲＥＳＳ以降の）コマンド−特定の結果値：
なし
【０２２８】
実施注釈：
一実施形態において、ＡＰＩがｓ６４＿ｃｏｎｎｅｃｔＣｌｏｓｅと同時に発生する他の動作から保護するので、接続の状態は一貫するようになる。１つのＣＰＵで遮断されている接続と別のＣＰＵで処理されている結果の間で本質的な競合が存在する。全ての重要な動作が完了した後で接続を遮断する場合、アプリケーションは、この競合状態から保護することを担当する。
【０２２９】
s64_connectReset()
s64c_status
s64_connectReset(s64c_handle handle,s64c_param p)
【０２３０】
一実施形態によれば、ｓ６４＿ｃｏｎｎｅｃｔＲｅｓｅｔ（）は規定の接続を再設定する。接続が再設定されるとき、キューされるデータの全て、一部、または、なしが転送されることがある；可能であれば、接続は再設定されてもよい。
【０２３１】
ペンディング読み出しまたは用いることができる読み出し結果が存在する場合、ｓ６４＿ｃｏｎｎｅｃｔＲｅｓｅｔ（）は、ＥＮＯＥＲＲＯＲの代りにＥＩＮＰＲＯＧＲＥＳＳを返す。読み出し動作はできれば早く中断されてもよく、結果は廃棄される。
【０２３２】
ペンディング記録または用いることができる記録結果が存在する場合、ｓ６４＿ｃｏｎｎｅｃｔＲｅｓｅｔ（）は、ＥＮＯＥＲＲＯＲの代りにＥＩＮＰＲＯＧＲＥＳＳを返す。記録動作はできれば早く中断されてもよく、結果は廃棄される。
【０２３３】
１つ以上の動作がペンディング中及び／または結果がキューされる場合、結果メッセージがｓ６４＿ｃｏｎｎｅｃｔＲｅｓｅｔ（）コールに規定されたパラメータでキューされてもよい。この結果は、接続が停止し、遮断されることを示す。
【０２３４】
戻り値：
ENOERROR  接続ハンドルがシステム呼び出しに対してこれ以上有効ではない；このハンドルで後続動作は、ＥＢＡＤＦを返すようになる。
EINPROGRESS  動作がペンディング中 及び/または結果を接続に用いることができる；アプリケーションは完了を待たなければならない。接続ハンドルがシステムの呼び出しに対してこれ以上有効ではない。このハンドルで後続動作はＥＢＡＤＦを返すようになる。
EBADF  無効の接続ハンドル
【０２３５】
（ＥＩＮＰＲＯＧＲＥＳＳ以降の）コマンド−特定の結果値：
なし
【０２３６】
実施注釈：
一実施形態において、ＡＰＩがｓ６４＿ｃｏｎｎｅｃｔＲｅｓｅｔ（）と同時に発生する他の動作から保護するので、接続の状態が一貫するようになる。１つのＣＰＵで遮断されている接続と、別のＣＰＵで処理されている結果の間で本質的な競合が存在する。全ての重要な動作が完了する前に接続を再設定する場合には、アプリケーションはこの競合状態から保護することを担当する。
【０２３７】
s64_closeAddr()
s64c_status
s64_closeAddr(s64c_connInfo Hp,s64c_flag discard)
【０２３８】
一実施形態によれば、ｓ６４＿ｃｌｏｓｅＡｄｄｒ（）は、規定のアドレスで新たな接続の受け入れを中断する。廃棄（ｄｉｓｃａｒｄ）がノンゼロ（ｎｏｎｅ−ｚｅｒｏ）の場合は、どのペンディング接続も再設定されるようになり、完了キュー（例えば、ペンディングイベントキュー５８０）から廃棄される。そうでない場合は、ペンディング接続は正常に伝達するようになる；このモードは、自動シャットダウンが支援される。
【０２３９】
戻り値：
ENODEV  規定のアドレスファミリが支援されない。
ENOERROR  新たな接続が規定のアドレスからこれ以上受け入れられなくなる。
【０２４０】
結果状態：
どの完了もこの要請に対して信号されない。
【０２４１】
実施注釈：
一実施形態において、廃棄するものである場合、完了した接続は結果キューから除去されるようになる；発信接続を遮断するように、接続結果を読み出しすることと着信要請をディスエーブルすることの間でＭＰ競合状態が存在し得る。失効ＩＰアドレス及び／またはポートは静かに無視される。
【０２４２】
プロトコル
ＩＰＶ４プロトコルは、定義された定数Ｓ６４ＡＦ＿ＩＰＶ４により表される。ＴＣＰ及びＵＤＰプロトコルが下記例に記載されている唯一のプロトコルであるが、当業者であれば、他のプロトコルが支援できることが分かる。一実施形態によれば、ＩＰアドレスをカプセル化（ｅｎｃａｐｓｕｌａｔｅ）するのに用いることができる構造体は、次のとおりである：
typedef struct{
u8  ipv4_af;  //プロトコル＝＝Ｓ６４ＡＦ＿ＩＰＶ４
u8  ipv4_flags;  //要請特定のフラグ
u16  ipv4_port;  //ポート値（ネットワークバイト順序）
u32  ipv4_addr;  //受信先アドレス（ネットワークバイト順序）
u64  ipv4_info;  //プロトコル特定の値、未使用であれば０
}ipv4Addr ALIGNED_DECL(8);
【０２４３】
一実施形態において、ＩＰアドレス及び１６ビットポートナンバーは、ネットワークバイト順序で格納される。ｉｐｖ４＿ｉｎｆｏフィールドは、付加情報が要請される場合は、ＴＣＰ及びＵＤＰ以外のプロトコルに用いることができる。ＴＣＰ及びＵＤＰにおいて、フィールドはゼロに設定される。
【０２４４】
接続
一実施形態によれば、（ｓ６４＿ａｃｃｅｐｔＡｄｄｒ（））が受け入れられたり、または（ｓ６４＿ｃｏｎｎｅｃｔＡｄｄｒ（）、ｓ６４＿ｃｏｎｎｅｃｔＨｏｓｔ（））が開始される接続パターンは、ｉｐｖ４＿ｆｌａｇｓフィールドをＴＣＰ（ＩＰＶ４＿ＰＲＯＴＯ＿ＴＣＰ）またはＵＤＰ（ＩＰＶ４＿ＰＲＯＴＯ＿ＵＤＰ）に対する標準プロトコル番号に設定することにより表される。
【０２４５】
接続を開始するとき、ローカルＩＰアドレス及びポートナンバーは、システムにより自動的に選択されてもよく、接続ハンドルを介してクエリーされてもよい。接続が完了するとき、リモートＩＰ及びポートアドレスは、返還状態で用いることができる。
【０２４６】
着信接続を受け入れる準備をするとき、発信者は、ローカルＩＰアドレス及びポートナンバーを指定することができる。アドレスが０ｘ０である場合、接続はＩＰＶ４プロトコルを支援する全ての配信サービスに関して受け入れられてもよい；そうでない場合、アドレスが配信サービスに対応するものと仮定される。新たな接続が完了するとき、リモートＩＰ及びポートアドレスは返還状態で用いることができる。
【０２４７】
エンドポイントアドレス
一実施形態によれば、ソースまたは受信先ＩＰアドレスがコマンドに、または結果で規定される場合、次の６４ビット構造体が用いられてもよい：
typedef struct{
u16  ipv4ep_flags;  //要請特定のフラグ
u16  ipv4ep_port;  //ポート値（ネットワークバイト順序）
u32  ipv4ep_addr;  //アドレス（ネットワークバイト順序）
}ipv4endPoint  ALIGNED_DECL(8);
【０２４８】
送受信
一実施形態において、ＴＣＰ接続に対して、プロトコル−特定の結果トークンは、常にゼロになる。ｓ６４＿ｓｅｎｄＣｏｎｎｅｃｔｉｏｎ（）関数は、ｓ６４＿ｗｒｉｔｅＣｏｎｎｅｃｔｉｏｎ（）と等しい；規定されたトークンは無視されてもよい。ＴＣＰが信頼性のあるバイトストリームであるので、実際パケットの境界が維持されることができない。
【０２４９】
一実施形態によれば、ＵＤＰの実現は、ＴＣＰとは、ＵＤＰ通信のパケット指向（ｐａｃｋｅｔ−ｏｒｉｅｎｔｅｄ）、非連結性のため、様々な差異を持つ。同一のＡＰＩコールが用いられても、ｍｕｘという用語はＵＤＰ通信を区別するために使用される。ｓ６４＿ｓｅｎｄＣｏｎｎｅｃｔｉｏｎ（）に規定された、さらにｓ６４＿ｑＲｅａｄｙ（）から返されたトークンの値は、上記の定義されたＩＰエンドポイントアドレスである。
【０２５０】
ＵＤＰ  ｍｕｘは、接続が（そのアプリケーションにより開始されて）発信されたり、または（そのアプリケーションにより受け入れられて）着信されるかによって分けることができる。着信ｍｕｘで、ローカルＩＰアドレス及びポートは、アンカー（ａｎｃｈｏｒ）される：単に、パケットが規定のＩＰアドレスに送信され、ポートはｍｕｘで読み出されるようになる；結果トークンは、ソースＩＰアドレス及びポートであってもよい。パケットがｓ６４＿ｓｅｎｄＣｏｎｎｅｃｔｉｏｎ（）を用いて送信されるとき、トークンは受信先ＩＰアドレス及びポートを指定するが、ソースがアンカー（ａｎｃｈｏｒ）値から取得される。
【０２５１】
ｍｕｘがアプリケーションにより開始されるとき、受信先ＩＰアドレス及びポートはアンカーされる：全てのパケットは、同一の受信先に送信されるようになり、規定のＩＰアドレス及びポートからのパケットのみがｍｕｘで読み出される。パケットがｓ６４＿ｓｅｎｄＣｏｎｎｅｃｔｉｏｎ（）を用いて送信されるとき、トークンはソースＩＰアドレス及びポートを指定する；これはアプリケーションが他のポートから同一の接続で送信することを許容する。
【０２５２】
一実施形態において、ＴＣＰと異なり、ＵＤＰパケット境界は常に維持される。アプリケーションがパケットで用いられるものより少ないバイトを読み出す場合、読み出されないバイトは廃棄される。また、それはパケットがドロップされ、さらに、複製パケットが受信されることが可能である；ハイレベルのプロトコル（例えば、ＤＮＳ）は、これを管理する必要がある。
【０２５３】
ＩＣＭＰ
一実施形態によれば、フラグをＩＰＶ４＿ＰＲＯＴＯ＿ＩＣＭＰに設定し、ｓ６４＿ａｃｃｅｐｔＡｄｄｒ（）を呼び出すことで、アプリケーションは、ＩＰＶ４配信サービスごとに１つのＩＣＭＰ接続を確立することができる。一実施形態において、結果的なハンドルからの読み出しは、ＩＣＭＰペイロード（ｐａｙｌｏａｄ）を返すようになる；関連の配信サービスで到逹できる場合、転送は規定のエンドポイントにＩＣＭＰペイロードを伝達することができる。ネットワークスタックは、入力に対してＩＣＭＰチェックサムをチェックし、出力でそれを生成する。
【０２５４】
ＩＰルーティング
一実施形態において、ＩＰＶ４は、ＩＰＶ４プロトコルを行う全ての配信サービスに対してルーティングテーブルを維持する。エントリーは、２つの方式のうちの１つで導入される：
【０２５５】
・配信サービスが構成される場合、規定のマッチングアドレスが明示されているインタフェースで直接伝達できることを示すエントリーが形成される。
【０２５６】
・ルートがＡＦ＿ＩＰＶ４＿ＲＯＵＴＥコマンドでｓ６４＿ａｆＣｏｎｔｒｏｌ（）に明示的に追加されてもよい。
【０２５７】
概念的に、ルーティングテーブルは、
{netaddr,netniask,hop,dsID}
の４つの形式で構成される。
【０２５８】
一実施形態によれば、ルーティングテーブルは、初めに、サブネットマスクにより最も大きなネットマスク値を第１にして整列され、その次に昇順でＩＰアドレスにより整列される。従って、２つのインタフェースが同一のサブネットで構成される場合には、最下位のＩＰアドレスは、全ての発信接続に対して用いられるようになる。
【０２５９】
アドレスファミリのコマンド
一実施形態によれば、ＡＦ＿ＱＵＥＲＹコマンドに対する応答は、ｓ６４ｃ＿ｃｏｎｎＩｎｆｏ構造体を次のように設定する：
ciAF←S64AF_IPV4
ciFlags←0x0
ciInfo←「IPV4」
【０２６０】
ＡＦ＿ＣＡＣＨＥコマンドは、そのルーティングテーブルに基づいて、影響を受け得る全ての配信サービスへ要請をパスする。ルーティングされることができないアドレスは静かに無視されてもよい。
【０２６１】
一実施形態において、次の付加のアドレスファミリのコマンドは、ＩＰＶ４に対して定義され、後述される：
AF_IPV4_CONFIG†  配信サービスアドレスを構成する。
AF_IPV4_ROUTE  ルーティング情報を設定するか獲得する。
AF_IPV4_CTRL†  ＩＰアドレスを制御する。
AF_IPV4_DNS  ＤＮＳ情報を設定するか獲得する。
【０２６２】
†の表示のコマンドは、ＩＰＶ４を行うそれぞれの配信サービスから支援を要求することができる。
【０２６３】
AF_IPV4_CONFIG  規定された配信サービスを構成する。
【０２６４】
パラメータ
typedef struct{
u8  ipv4d_af;  //プロトコル＝＝Ｓ６４Ｃ＿ＩＰＶ４
u8  ipv4d_cmd;  //オペレーションコード
u16  ipv4d_ds;  //配信サービス及びｉｄｅｎｔｉｔｙ
u32  ipv4d_addr;  //配信サービスアドレス
u32  ipv4d_mask;  //サブネットマスク
u32  ipv4d_bcast;  //放送（ｂｒｏａｄｃａｓｔ）ＩＰ−デフォルトに対して０使用
}ipv4dsConfigALIGNED_DECL(8);
【０２６５】
セット
次の値はｉｐｖ４＿ｓｅｔに対して有効である：
IPV4_SET_CONFIG  配信サービス構成を設定する。
IPV4_GET_CONFIG  配信サービス構成を獲得する。
IPV4_DEL_CONFIG  配信サービス構成を削除する。
【０２６６】
説明
このインタフェースは、その規定の配信サービスに対してＩＰアドレス及びサブネットマスクを設定、獲得、または、削除するのに用いることができる。構成を設定するとき、アドレス及びサブネットマスクは、別のアドレスを複写してはいけない。また、アドレスとサブネットマスクのビット−ワイズ（ｂｉｔ−ｗｉｓｅ）ＡＮＤは、ゼロであってはいけない。多重配信サービスが同一のサブネットで構成される場合には、配信サービスのうちの正確に１つが用いられる；しかし、その１つは不確実である。
【０２６７】
IPV4_SET_CONFIG  配信サービス構成を設定する。
【０２６８】
配信サービスに対してＩＰ構成を設定し、インタフェースをイネーブルする。放送ＩＰは明示的に設定されてもよい；しかし、値０ｘ０がパスされる場合には、放送ＩＰアドレスは、次のように計算される：
(ipv4d_addr&ipv4d_mask)｜〜ipv4d_mask
【０２６９】
IPV4_GET_CONFIG  配信サービス構成を獲得する。
【０２７０】
アドレス、サブネットマスク及び放送アドレスフィールドなどが記録されるようになる。アドレスがゼロである場合には、配信サービスは構成されないこともある。
【０２７１】
IPV4_DEL_CONFIG  配信サービス構成を削除する。
【０２７２】
これは規定の配信サービスをディスエーブルすることができ、その構成を再設定することができる。ｉｎｆｏパラメータは無視されてもよく、ＮＵＬＬであってもよい。
【０２７３】
AF_IPV4_ROUTE  ＩＰＶ４ルーティング情報を獲得したりまたは設定する。
【０２７４】
パラメータ
typedef struct{
u8  ipv4r_af;  //プロトコル＝＝Ｓ６４Ｃ＿ＩＰＶ４
u8  ipv4r_flags;  //ルートコマンド
u16  ipv4r_dsid;  //配信サービス及びｉｄｅｎｔｉｔｙ（ＧＥＴ）
u32  ipv4r_addr;  //受信先アドレス
u32  ipv4r_mask;  //比較マスク
u32  ipv4r_gw;  //ゲートウェイアドレス
}ipv4Route ALIGNED_DECL(8);
【０２７５】
フラグ
次の値は、ｉｐｖ４ｒ＿ｆｌａｇｓに対して有効である：
IPV4_SET_ROUTE  ルーティングテーブル情報を設定する。
IPV4_DEL_ROUTE  ルーティングテーブル情報を削除する。
IPV4_GET_ROUTE  特定事項に対してルーティング情報を獲得する。
【０２７６】
説明
一実施形態において、ルーティングエントリーは、ＩＰアドレスに対してどの配信サービスを利用すべきであるか、さらに、第１のホップのアドレスが何になるべきであるかを決定する；ここで、配信サービス及び受信先が同一のサブネットにある場合は、２つのアドレスは同一になる。ルーティングエントリーが用いられるべきを決めるのに使用される論理は次のとおりである：
(dest&entry.mask)==entry.addr
【０２７７】
ゼロのアドレス及びマスクアドレスの状態で１つの特別なルーティングエントリー、デフォルトゲートウェイ（ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ）が存在し得る。このエントリーは、存在する場合、他のどのエントリーも上記論理を満足しないときに用いることができる。１つ以上のデフォルトゲートウェイが指定されることができる。また、配信サービスが構成される場合、暗示的に生成されたルーティングエントリーが存在する（下記参照）。
【０２７８】
IPV4_SET_ROUTE  ルーティングテーブル情報を設定する。
【０２７９】
ルーティングエントリーが明示的に追加されるとき、パラメータ値は次のテストをパスすることができる：
【０２８０】
・ゲートウェイアドレスは、構成された配信サービスで到達されることができる。構成コマンドは、これを決めるのに既存のルーティングテーブルを用いるようになる。一実施形態において、このテストが失敗する場合は、コマンドはＥＮＯＤＥＶとして失敗する。
【０２８１】
・アドレス及びマスクがルーティングテーブルに既に存在しないことがある。一実施形態において、このテストが失敗する場合は、コマンドはＥＩＮＶＡＬとして失敗になる。
【０２８２】
ここで、１つ以上のルーティングエントリーがルーティング要請を満足する場合には、最も特定のネットワークマスクを持ったエントリーが選択される。例えば、次の２つのエントリー、
<192.168.0.0, 255.255.255.0, 1>
<192.168.0.0, 255.255.0.0, 3>
が存在する場合、アドレス１９２．１６８．０．７は常に配信サービス１でルーティングされ、決して配信サービス３でルーティングされない。
【０２８３】
IPV4_DEL_ROUTE  ルーティングテーブル情報を削除する。
【０２８４】
ルーティングエントリーが削除される場合、パラメータ値は次のテストでパスすることができる：
【０２８５】
・アドレス及びマスクがルーティングテーブルに存在し得る。一実施形態において、このテストが失敗する場合、コマンドはＥＩＮＶＡＬとして失敗になる。
【０２８６】
・アドレス及びマスクは、配信サービスに対する構成を参照しないこともある。一実施形態において、このテストが失敗する場合、コマンドはＥＩＮＶＡＬとして失敗になる。
【０２８７】
IPV4_GET_ROUTE  ルーティング情報を獲得する。
【０２８８】
このコマンドは、アプリケーションが接続をルーティングするかどうか及びその方法を決めることを許容する。一実施形態によれば、入力では単にｉｐｖ４ｒ＿ａｄｄｒが用いられる。ここで、規定されたアドレスがルーティングされることができない場合は、これは、どのデフォルトゲートウェイも存在しないときに単に発生することがあり、コマンドは失敗になることもあり、ＥＮＯＤＥＶを返すことができる。そうでない場合は、配信サービス及びｉｄｅｎｔｉｔｙ、ゲートウェイアドレス、及びネットワークマスクは、各々ｉｐｖ４ｒ＿ｄｓｉｄ、ｉｐｖ４ｒ＿ｇｗ及びｉｐｖ４ｒ＿ｍａｓｋに記録されるようになる。全ての他のフィールドは変化しない。
【０２８９】
AF_IPV4_CTRL  ＩＰアドレスを制御する。
【０２９０】
パラメータ
typedef struct{
u8  ipv4c_af;  //プロトコル＝＝Ｓ６４Ｃ＿ＩＰＶ４
u8  ipv4c_block;  //０＝許容、１＝ブロック
u16  ipv4c_zero;  //未使用−ゼロではなければならない
u32  ipv4c_addr;  //ソースアドレス−ネットワークバイト順序
u32  ipv4c_mask;  //アドレスマスク−ネットワークバイト順序
u32  ipv4c_pspec;  //ポートマスク仕様（ｓｐｅｃｉｆｉｃａｔｉｏｎ）
}ipv4Control ALIGNED_DECL(8);
【０２９１】
説明
一実施形態において、このコマンドは受け入れられるかブロック（ｂｌｏｃｋ）されるべきソースＩＰ及びポートアドレスを指定する。一実施形態において、ｉｐｖ４ｃ＿ｂｌｏｃｋがゼロである場合、アドレス及びポートは許容されるようになる；そうでない場合は、それはブロックされるようになる。ポートアドレスがフィルターの一部でなければ、ｉｐｖ４ｃ＿ｐｓｐｅｃは０ｘ０に設定されなければならない；そうでない場合、
(portMask≪'16)｜portVal
に設定されることがあり、ここで、ｐｏｒｔＭａｓｋ及びｐｏｒｔＶａｌは全てネットワークバイト順序である。
(new.addr&mask)==addr&&(new.port&portMask)==portVal
であるとき、着信接続は仕様（ｓｐｅｃｉｆｉｃａｔｉｏｎ）と一致する。
【０２９２】
AF_IPV4_DNS  ＤＮＳ情報を獲得したり設定する。
【０２９３】
パラメータ
typedef struct{
u8  dns_af;  //プロトコル＝＝Ｓ６４Ｃ＿ＩＰＶ４
u8  dns_flags;  //ＤＮＳコマンド
u16  dns_zero;  //未使用−ゼロではなければならない
u32  dns_addr[3];  //サーバーアドレス−ネットワークバイト順序
}ipv4dnsAddr ALIGNED_DECL(8);
【０２９４】
フラグ
次の値は、ｄｎｓ＿ｆｌａｇｓに対して有効である：
IPV4_SET_DNS  ＤＮＳサーバーエントリーを設定する。
IPV4_GET_DNS  ＤＮＳサーバーエントリーを獲得する。
IPV4_CLR_DNS  ＤＮＳキャッシュを消去する。
【０２９５】
説明
ＤＮＳがＩＰ−オンリー（ＩＰ−ｏｎｌｙ）プロトコルでなくても、本質的にＩＰＶ４に接続され、よってその保護下で管理される。２つのＤＮＳコマンドは、ＤＮＳサーバーに対する１つ〜３つのアドレスを設定したり（ＩＰＶ４＿ＳＥＴ＿ＤＮＳ）、または獲得する（ＩＰＶ４＿ＧＥＴ＿ＤＮＳ）。アドレスは優先順位順序が存在して、つまりｄｎｓ＿ａｄｄｒ［０］は第１のサーバーであり、ｄｎｓ＿ａｄｄｒ［ｌ］は第２のサーバーであり、そして、ｄｎｓ＿ａｄｄｒ［２］は第３のサーバーである。一実施形態において、ＤＮＳアドレスが０ｘ０である場合には、どのサーバーもそのエントリーにより規定されない。
【０２９６】
IPV4_SET_DNS  ＤＮＳサーバーエントリーを設定する。
【０２９７】
アドレスが設定される場合、次のテストを適用することができる：
【０２９８】
・第１のサーバーを指定してもよい。このテストが失敗する場合には、コマンドはＥＩＮＶＡＬとして失敗になる。
【０２９９】
・第３のサーバーは、第２次が指定されたときにのみ指定されることができる。このテストが失敗する場合には、コマンドはＥＩＮＶＡＬとして失敗になる。
【０３００】
・既存のルーティングテーブルが付与される場合には、全ての指定アドレスが到達することができる。このテストが失敗する場合には、コマンドはＥＮＯＤＥＶとして失敗になる。
【０３０１】
IPV4_GET_DNS  ＤＮＳサーバーエントリーを設定する。
【０３０２】
一実施形態において、使用中のＤＮＳサーバーアドレスがｄｎｓ＿ａｄｄｒ［］に複写される。ｄｎｓ＿ａｄｄｒ［０］が０ｘ０である場合には、どのＤＮＳサーバーも構成されない。
【０３０３】
IPV4_CLR_DNS  ＤＮＳキャッシュを消去する。
【０３０４】
ＤＮＳルックアップの結果は、改善された性能のためにキャッシュされてもよい。これらのキャッシュは、ＤＮＳプロトコルによって正常にエージするようになる。しかし、アプリケーションが全てのＤＮＳエントリーを除去することを望む場合は、このコマンドを発することができる；ｄｎｓ＿ａｄｄｒ［］の値は無視される。しかし、フライト中の（ｉｎｆｌｉｇｈｔ）ＤＮＳルックアップが存在する場合には、これは削除されたり中断されたりはしない。
【０３０５】
オンボードＴＣＰ（ＯＢＴＣＰ）インタフェース
このセクションは、システムＣＰＵ、メモリ及びＮＩＣハードウェアを利用してオフ−ロードボード動作を模倣する、「オンボード」ＴＣＰ実現の上位層と下位層の間で交換できる、様々なコマンド、パラメータ、意味論及び結果について記載する。一実施形態によれば、このオンボードのＴＣＰ実現は、次のように構成される：
【０３０６】
ｑＮｅｔ接続ＡＰＩへのコールは、ＯＢＴＣＰコマンド及びパラメータに変換された後、要請ＦＩＦＯに挿入される。これらのコマンドは、順に読み出し及び解読されることができる；特定のコマンドが完了した場合、該結果（存在する場合）はアプリケーションへの配信のためにキューされる。例示的なコマンド、パラメータ及び結果が以下の表に（アルファベット順に）要約されている；以下の各々のコマンドについては引き続き詳細に議論される。
【０３０７】
各々のコマンドは、同一の３２−ｂｙｔｅ構造体を用いる：
typedef struct{
u8  ob_opcode;  //動作／命令コード
u8  ob_flags;  //動作−依存フラグ
u8  ob_rj45;  //ＮＩＣインデクス
u8  ob_identity;  //このＮＩＣでｉｄｅｎｔｉｔｙ
u32  ob_handle;  //関連のハンドル（ない場合は０）
u32  ob_ipAddr;  //ＩＰアドレス（ない場合は０）
u32  ob_gateAddr;  //第１のホップのＩＰ（ない場合は０）
u32  ob_length;  //データｌｅｎ（ない場合は０）
u32  ob_info;  //動作及びプロトコル依存情報
void  *ob_param64;  //ポイントまたは６４−ビット値
}obCommand ALIGNED_DECL(8);
【０３０８】
全てのフィールドが全てのコマンドに対して用いられるのではない：未使用フィールドは、ゼロに設定されなければならない。多重送信の意味を有するフィールドに対して定義され得る、幾つかの便利なエイリアスが存在する：
ob_protocol  OB_CMD_ACCEPT、OB_CMD_HANGUP及びOB_CMD_CONNECTにおけるob_flagsに対するエイリアス。
ob_port  OB_CMD_ACCEPT及びOB_CMD_CONNECTにおけるob_infoに対するエイリアス。
ob_token  OB_CMD_ACCEPT、OB_CMD_HANGUP及びOB_CMD_CONNECTにおけるob_param64に対するエイリアス。
ob_data  OB_CMD_READ、OB_CMD_WRITE、OB_CMD_SEND及びOB_CMD_RESOLVE_DNSにおけるob_param64に対するエイリアス。
ob-reset  OB_CMD_CLOSE及びOB_CMD_QUIESCEにおけるob_flagsに対するエイリアス。
ob_src  OB_CMD_PASSにおけるob_handleに対するエイリアス。
ob_dst  OB_CMD_PASSにおけるob_dateAddrに対するエイリアス。
ob_mask  OB_CMD_CONFIGにおけるob_gateAddrに対するエイリアス。
ob_bcast  OB_CMD_CONFIGにおけるob_lengthに対するエイリアス。
ob_enable  OB_CMD_CONFIGにおけるob_flagsに対するエイリアス。
【０３０９】
この結果は、接続ブロックのコンポーネントを用いてキューされてもよく、次の構造体などからなってもよい：
typedef struct{
void  *no_next;  //キュー上の次の項目
u64  no_param;  //不透明パラメータ
u32  no_status;  //結果状態コード
u16  no_dsid;  //配信サービス及びｉｄｅｎｔｉｔｙ
u16  no_flags;  //状態フラッグ。
u64  no_endPoint;  //プロトコル−特定のエンドポイント情報
}*s64NetConnect ALIGNED_DECL(8);
typedef struct{
void  *no_next;  //キュー上の次の項目
u64  no_param;  //不透明パラメータ
u32  no_status;  //結果状態コード
u16  no_info;  //オペレーション−特定の情報
u16  no_flags;  //状態フラッグ
s64c_count  no_bsize;  //最初のバッファー大きさ
s64c_count  no_count;  //転送されたデータバイト
u64  no_token;  //付加の読み出し情報
}*s64NetRead ALIGNED_DECL(8);
typedef struct{
void  *no_next;  //キュー上の次の項目
u64  no_param;  //不透明パラメータ
u32  no_status;  //結果状態コード
u16  no_info;  //オペレーション−特定の情報
u16  no_flags;  //状態フラッグ
s64c_count  no_bsize;  //最初のバッファー大きさ
constu32  no_reserved;  //予備される、読み出し専用
}*s64NetWrite ALIGNED_DECL(8);
【０３１０】
この例によれば、ＯＢＴＣＰにより支援される使用中の接続あたり１つの包括的なｓ６４ＮｅｔＣｏｎｎＢｌｏｃｋ構造体がある。伝達するそれぞれの結果に対し、接続、読み出しまたは記録構造体のうちの１つに対するポインターを利用してｓ６４＿ｏｐＲｅａｄｙ（）を呼び出すことでキューされる。値を設定する方法は、それぞれのコマンドを使用して論議される；ｎｏ＿ｆｌａｇｓに対する値は、ｓ６４＿ｏｐＲｅａｄｙ（）にパスされる値である。従って、ｎｏ＿ｆｌａｇｓは直接ＯＢＴＣＰコードにより設定されてはならない。
【表２】
2008524878.tif 000004
【０３１１】
ＯＢ＿ＣＭＤ＿ＣＯＮＦＩＧ    配信サービスアドレスを構成する
【０３１２】
パラメータ
ob_enable  配信サービス／ｉｄｅｎｔｉｔｙがディスエーブルされるべきである場合は０ｘ０；そうでない場合は、イネーブルする。
ob_rj45  構成が適用されるＮＩＣインデクス。
ob_identity  構成が適用されるｉｄｅｎｔｉｔｙ。
ob_handle  未使用。
ob_ipAddr  使用可能である場合、配信サービス／ｉｄｅｎｔｉｔｙに対するＩＰアドレス。
ob_mask  使用可能である場合、配信サービス／ｉｄｅｎｔｉｔｙに対するネットマスク。
ob_token  未使用。
ob_data  未使用。
ob_bcast  使用可能である場合、配信サービス／ｉｄｅｎｔｉｔｙに対する放送ＩＰアドレス。
ob_info  未使用。
【０３１３】
OB_CMD_RESOLVE_DNS  ＤＮＳサーバーにネーム決定をクエリーする。
【０３１４】
パラメータ
ob_flags  未使用。
ob_rj45  ＮＩＣインデクス。
ob_identity  未使用−ＤＮＳ要請が常にＩＤ  ０をローカルアドレスとして用いる。
ob_handle  未使用。
ob_ipAddr  ＤＮＳサーバーのＩＰアドレス（ネットワークバイト順序）。
ob_gateAddr  第１のホップのＩＰアドレス（ネットワークバイト順序）。
ob_length  ＤＮＳデータの長さ（ワイヤーフォーマット)。
ob_info  返す３２−ｂｉｔパラメータ。
ob_data  ワイヤーフォーマットされたＤＮＳホストネームのアドレス。
【０３１５】
説明
一実施形態において、この動作は、規定されたホストネームを決定するために規定されたＤＮＳサーバーと接触するのである。第１のホップＩＰアドレスは、配信サービスｉｄｅｎｔｉｔｙ０と同一のサブネット上にあるものとして保証される。
【０３１６】
結果
ＤＮＳクエリーが完了したり、失敗した場合、接続ブロックの接続部分は、次のように初期化され得る：
no_param  決定コマンドからｏｂ＿ｉｎｆｏの値に設定できる。
no_status  決定が成功的あるときＥＮＯＥＲＲＯＲに設定できる。そうでない場合は、どのように要請が失敗したかを示すように設定される。
no_dsid  ｉｄｅｎｔｉｔｙ及びシステム配信サービス（必ずしもＮＩＣインデクスと同じではない）に設定できる。
no_flags  S64_NETOP_CONNECT|S64_NETOP_ACTIVE
no_endPoint  ｉｐｖ４＿ｅｎｄｐｏｉｎｔ構造体に格納される、決定されたＩＰアドレスに対して６４ビット等価値に設定できる。
【０３１７】
OB_CMD_ACCEPT  着信接続を受け入れる。
【０３１８】
パラメータ
ob_protocol  ＩＰプロトコル（例えば、ＩＰＶ４＿ＰＲＯＴＯ＿ＴＣＰ）。
ob_rj45  新たな接続に対するＮＩＣインデクス。
ob_identity  新たな接続に対するｉｄｅｎｔｉｔｙ。
ob_handle  未使用。
ob_ipAddr  未使用。
ob_gateAddr  未使用。
ob_length  未使用。
ob_port  ＴＣＰ／ＵＤＰポート（ネットワークバイト順序）
ob_token  各々の新たな接続に返されるアプリケーショントークン。
【０３１９】
説明
一実施形態において、この動作は、ＴＣＰが規定されたＮＩＣ／ＩＤで接続を受け入れるように許容するものである。ＮＩＣ及びｉｄｅｎｔｉｔｙ値がローカルＩＰアドレスを唯一に決めるので、それはコマンドブロックで指定されない。ｏｂ＿ｔｏｋｅｎ値がそれぞれの着信接続に対して返される。一実施形態において、プロトコルがＵＤＰまたはＩＣＭＰである場合は、該コマンドはリモート装置がＵＤＰまたはＩＣＭＰパケットをそれぞれ送信することもできるローカルエンドポイントを設定する。
【０３２０】
結果
新たな接続を用いることができる場合、接続ブロックの接続部分は、次のように初期化される：
no_param  受け入れコマンドからｏｂ＿ｔｏｋｅｎの値に設定できる。
no_status  常にＥＮＯＥＲＲＯＲになる−失敗した着信接続に対する結果を返すにあたってポイントがない。
no_dsid  ｉｄｅｎｔｉｔｙ及びシステム配信サービス（必ずしもＮＩＣインデクスと同じではない）に設定できる。
no_flags  S64_NETOP_CONNECT｜S64_NETOP_ACTIVE
no_endPoint  ｉｐｖ４＿ｅｎｄｐｏｉｎｔ構造体に格納される、決定されたＩＰアドレスに対して６４ビット等価値に設定できる。
【０３２１】
OB_CMD_HANGUP  着信接続を受け入れることを中断する。
【０３２２】
パラメータ
ob_protocol  ＩＰプロトコル（例えば、ＩＰＶ４＿ＰＲＯＴＯ＿ＴＣＰ）。
ob_rj45  接続のためのＮＩＣインデクス。
ob_identity  接続のためのｉｄｅｎｔｉｔｙ。
ob_handle  未使用。
ob_ipAddr  未使用。
ob_gateAddr  未使用。
ob_length  未使用。
ob_port  ＴＣＰ／ＵＤＰポート（ネットワークバイト順序）
ob_param64  未使用。
【０３２３】
説明
一実施形態において、この動作は規定されたＮＩＣ／ＩＤ及びポートで着信接続を受け入れることを中断する。
【０３２４】
結果
なし
【０３２５】
OB_CMD_CONNECT  リモートアドレスに接続する。
【０３２６】
パラメータ
ob_protocol  ＩＰプロトコル（例えば、ＩＰＶ４＿ＰＲＯＴＯ＿ＴＣＰ）。
ob_rj45  接続のためのＮＩＣインデクス。
ob_identity  接続（ローカルアドレス）のためのｉｄｅｎｔｉｔｙ。
ob_handle  未使用。
ob_ipAddr  リモート装置のＩＰアドレス（ネットワークバイト順序）。
ob_gateAddr  第１のホップのＩＰアドレス（ネットワークバイト順序）。
ob_length  未使用。
ob_port  ＴＣＰ／ＵＤＰポート（ネットワークバイト順序）。
ob_token  接続が確立されたとき返されるアプリケーショントークン
【０３２７】
説明
一実施形態において、この動作は、指定されたリモート装置に接続するものである。一実施形態によれば、第１のホップＩＰアドレスは、規定された配信サービスと同一のサブネットワーク上にあるものとして保証される。
【０３２８】
一実施形態において、プロトコルがＵＤＰである場合、このコマンドは、リモートエンドポイントをアンカーさせ、全ての出るパケットは規定されたリモート装置に送信される。
【０３２９】
結果
新たな接続を用いることができる場合、接続ブロックの接続部分は、次のように初期化される：
no_param  接続コマンドからｏｂ＿ｔｏｋｅｎの値に設定できる。
no_status  成功（ＥＮＯＥＲＲＯＲ）または失敗（他のもの）を表わすように設定できる。
no_dsid  ｉｄｅｎｔｉｔｙ及びシステム配信サービス（必ずしもＮＩＣインデクスと同じではない）に設定できる。
no_flags  S64_NETOP_CONNECT｜S64_NETOP_ACTIVE
no_endPoint  ｉｐｖ４＿ｅｎｄｐｏｉｎｔ構造体に格納される、決定されたＩＰアドレスに対して６４ビット等価値に設定できる。
【０３３０】
OB_CMD_QUIESCE  ペンディングデータ転送を待つかまたは中断する。
【０３３１】
パラメータ
ob_reset  ゼロである場合、接続は正常に遮断されなければならない；そうでない場合、再設定する。
ob_rj45  未使用。
ob_identity  未使用。
ob_handle  停止するための接続ハンドル。
ob_ipAddr  未使用。
ob_gateAddr  未使用。
ob_length  未使用。
ob_port  未使用。
ob_token  停止（ｑｕｉｅｓｃｅ）が完了したとき返されるアプリケーショントークン。
【０３３２】
説明
一実施形態において、このコマンドは、アプリケーションが接続を遮断し、ペンディング中の、または、ペンディング結果によって読み出し及び／または記録コマンドがある場合、発されることができる。返されるとき、結果値はアプリケーションがそのデータエリアがネットワークによりこれ以上使用中でないことを把握することを許容する。一実施形態によれば、ｏｂ＿ｒｅｓｅｔがゼロ（遮断）であるかまたは非ゼロ（再設定）であるかによって、２セットの意味論が存在する：
【０３３３】
遮断
・ペンディング記録（存在する場合）は、利用可能な正常の結果とともに、完了することができる。どのペンディング記録も含めて、全てのデータが正常に伝達されることができ、最後に＜ＦＩＮ＞が送信される（この例外については（３）を参照）。
【０３３４】
・ペンディング読み出し（存在する場合）は、できれば早く中断されることができ、正常の結果メッセージが伝達できる。
【０３３５】
・ＴＣＰ／ＩＰスタックが＜ＦＩＮ＞を受信しない場合は、接続は再設定されることができる。従って、この場合、記録データを伝達するための労力がなくなる。＜ＦＩＮ＞が受信されＡＣＫ’ｄである場合、たとえ読み出されていないデータが存在しても、どの再設定も発しないこともある。
【０３３６】
再設定
・ペンディング記録（存在する場合）はできるだけ早く終了することができ、どの結果も返される必要はない。どのペンディング記録データも廃棄されてもよい。
【０３３７】
・ペンディング読み出し（存在する場合）はできるだけ早く終了することができ、どの結果も返される必要がない。
【０３３８】
・ＴＣＰ接続は再設定されてもよい（＜ＲＳＴ＞）。
【０３３９】
停止結果が伝達された後に、後続ＯＢ＿ＣＭＤ＿ＣＬＯＳＥが受信されるまで、ハンドルがまた有効である点に注意されたい。接続が遮断されたか、あるいは停止で再設定されたかを記憶することはＯＢＴＣＰにかかっている。遮断パラメータにおけるｏｂ＿ｒｅｓｅｔの値はこの場合無視する必要がある。
【０３４０】
結果
データ転送が完了したかあるいは終了し、読み出し及び／または記録結果がキューされる場合（ｏｂ＿ｒｅｓｅｔ＝＝０であるとき）、接続ブロックの接続部分は、次のように設定できる：
no_param  接続コマンドからｏｂ＿ｔｏｋｅｎの値に設定できる。
no_status  常にＥＮＯＥＲＲＯＲに設定される。
no_dsid  未変更。
no_flags  S64_NETOP_CONNECT｜S64_NETOP_ACTIVE
no_endPoint  未変更。
【０３４１】
OB_CMD_CLOSE  規定された接続を遮断する。
【０３４２】
パラメータ
ob_reset  ゼロである場合、接続は正常に遮断されなければならない；そうでない場合、再設定される。
ob_rj45  未使用。
ob_identity  未使用。
ob_handle  停止するための接続ハンドル。
ob_ipAddr  未使用。
ob_gateAddr  未使用。
ob_length  未使用。
ob_port  未使用。
ob_token  未使用。
【０３４３】
説明
一実施形態において、この動作は接続を除去し、そのリソースを解除する。ｏｂ＿ｒｅｓｅｔの全ての意味に対してはＯＢ＿ＴＣＰ＿ＱＵＩＥＳＣＥの説明を参照する。他のコマンドと異なり、どの結果も遮断のためにキューされない。
【０３４４】
結果
なし
【０３４５】
OB_CMD_READ  データ読み出しを開始する。
【０３４６】
パラメータ
ob_flags  未使用。
ob_rj45  未使用。
ob_identity  未使用。
ob_handle  接続ハンドル。
ob_ipAddr  未使用。
ob_gateAddr  未使用。
ob_length  データ転送長さ。
ob_info  未使用。
ob_data  アプリケーションバッファーのアドレス。
【０３４７】
説明
一実施形態において、この動作はｏｂ＿ｌｅｎｇｔｈバイト以下の規定された接続で読み出しを開始する。
【０３４８】
結果
一実施形態によれば、読み出しが完了したとき、接続ブロックの読み出し部分は、次のように設定した後にキューされる：
no_status  たとえ読み出し要請の単に一部だけが満足された場合でも、その読み出しが成功である場合は、ＥＮＯＥＲＲＯＲに設定できる。そうでない場合は、失敗を表わすように設定できる。
no_flags  Ｓ６４＿ＮＥＴＯＰ＿ＲＥＡＤ（１つ以上のバイトが伝達される。）
Ｓ６４＿ＮＥＴＯＰ＿ＲＥＡＤ｜Ｓ６４＿ＮＥＴＯＰ＿ＥＯＦ（ゼロバイトが伝達される。）
Ｓ６４＿ＮＥＴＯＰ＿ＲＥＡＤ｜Ｓ６４＿ＮＥＴＯＰ＿ＲＥＳＥＴ（接続が再設定される。）
no_count  伝達されるバイトの数で設定できる。
no_token  ＴＣＰに対して、この値はゼロである。ＵＤＰに対して、これは接続ｎｏ＿ｅｎｄＰｏｉｎｔと同一の方式を利用してソースＩＰ及びポートに設定される。
【０３４９】
OB_CMD_WRITE  データ記録を開始する。
【０３５０】
パラメータ
ob_flags  未使用。
ob_rj45  未使用。
ob_identity  未使用。
ob_handle  接続ハンドル。
ob_ipAddr  未使用。
ob_gateAddr  未使用。
ob_length  データ転送長さ。
ob_info  未使用。
ob_data  アプリケーションバッファーのアドレス。
【０３５１】
説明
一実施形態において、この動作はｏｂ＿ｌｅｎｇｔｈバイトの規定された接続で記録を開始する。記録は完全に成功であるかあるいは失敗である。
【０３５２】
結果
記録が完了した場合、接続ブロックの記録部分は、次のように設定した後にキューされる：
no_status  たとえ読み出し要請の単に一部だけが満足された場合にも、読み出しが成功的である場合は、ＥＮＯＥＲＲＯＲに設定できる。そうでない場合、失敗を表わすように設定される。
no_flags  Ｓ６４＿ＮＥＴＯＰ＿ＷＲＩＴＥ（接続を依然として用いることができる場合）
Ｓ６４＿ＮＥＴＯＰ＿ＷＲＩＴＥ｜Ｓ６４＿ＮＥＴＯＰ＿ＲＥＳＥＴ（接続が再設定される場合）
【０３５３】
OB_CMD_SEND  明示される受信先にデータ記録を開始する。
【０３５４】
パラメータ
ob_flags  未使用。
ob_rj45  未使用。
ob_identity  未使用。
ob_handle  接続ハンドル。
ob_ipAddr  受信先ＩＰアドレス。
ob_gateAddr  第１のホップＩＰアドレス。
ob_length  データ転送長さ。
ob_port  ＵＤＰポート。
ob_data  アプリケーションバッファーのアドレス。
【０３５５】
説明
一実施形態において、この動作はｏｂ＿ｌｅｎｇｔｈバイトの規定された接続で記録を開始するものである。記録は、第１のホップとしてｏｂ＿ｇａｔｅＡｄｄｒで（ｏｂ＿ｉｐＡｄｄｒと同一であり得る）、規定されたＩＰアドレス及びポートに設定される。記録は完全に成功であるか失敗である。
【０３５６】
結果
記録が完了したとき、接続ブロックの記録部分は次のように設定した後にキューされる：
no_status  たとえ読み出し要請の単に一部だけが満足された場合でも、読み出しが成功的である場合は、ＥＮＯＥＲＲＯＲに設定できる。そうでない場合は、失敗を表わすように設定される。
no_flags  Ｓ６４＿ＮＥＴＯＰ＿ＷＲＩＴＥ（接続を依然として用いることができる場合）
Ｓ６４＿ＮＥＴＯＰ＿ＷＲＩＴＥ｜Ｓ６４＿ＮＥＴＯＰ＿ＲＥＳＥＴ（接続が再設定された場合）
【０３５７】
OB_CMD_PASS  １つの接続から他の接続までパケットを伝達する。
【０３５８】
パラメータ
ob_flags  未使用。
ob_rj45  未使用。
ob_identity  未使用。
ob_src  ソース（読み出し）接続ハンドル。
ob_ipAddr  受信先ＩＰアドレス。
ob_dst  受信先（記録）接続ハンドル。
ob_length  未使用。
ob_port  未使用。
ob_data  未使用。
【０３５９】
説明
一実施形態において、動作はデータを直接読み出し側ｏｂ＿ｓｒｃから記録側ｏｂ＿ｄｓｔまでパスするようになる。
【０３６０】
結果
記録が完了したとき、接続ブロックの記録部分は、次のように設定した後でキューされる：
no_status  読み出し要請の単に一部だけが満足された場合でも、読み出しが成功的である場合は、ＥＮＯＥＲＲＯＲに設定できる。そうでない場合は、失敗を表わすように設定される。
no_flags  Ｓ６４＿ＮＥＴＯＰ＿ＷＲＩＴＥ（接続を依然として用いることができる場合）
Ｓ６４＿ＮＥＴＯＰ＿ＷＲＩＴＥ｜Ｓ６４＿ＮＥＴＯＰ＿ＲＥＳＥＴ（接続が再設定される場合）
【０３６１】
OB_CMD_EOF  転送のためにデータの最後としてその接続を表示する。
【０３６２】
パラメータ
ob_flags  未使用。
ob_rj45  未使用。
ob_identity  未使用。
ob_handle  接続ハンドル。
ob_ipAddr  未使用。
ob_gateAddr  未使用。
ob_length  未使用。
ob_port  未使用。
ob_data  未使用。
【０３６３】
説明
一実施形態において、この動作は記録側に対するデータの最後としてその接続を表示するものである。
【０３６４】
結果
なし
【０３６５】
OB_CMD_CACHE  動的アドレス情報をキャッシュする。
【０３６６】
パラメータ
ob_flags  未使用。
ob_rj45  NICインデクス。
ob_identity  常にゼロ。
ob_handle  未使用。
ob_ipAddr  ＩＰアドレス。
ob_gateAddr  未使用。
ob_length  未使用。
ob_port  未使用。
ob_data  未使用。
【０３６７】
説明
このコマンドは、規定されたアドレスが重要であり、ＯＢＴＣＰシステムが情報、特にＡＲＰ翻訳を格納しなければならないことを暗示する。ＯＢＴＣＰは、このコマンドを無視することができない。
【０３６８】
結果
なし
【０３６９】
以上、本発明の好ましい実施形態を参照して詳細に説明したが、本発明のより広範囲の思想及び有効な範囲から逸脱することなく、種々の修正及び変更を行うことが可能である。よって、詳細な説明及び図面は限定的意味を持つというよりも例示的なものとして理解されなければならない。
【図面の簡単な説明】
【０３７０】
【図１】Ｂｅｒｋｅｌｅｙソケットインタフェースモデルにおけるイベントの典型的な従来技術の順序を示す。
【図２】本発明の実施形態を利用できるコンピュータシステムの一例である。
【図３Ａ】ＳＧＰＯＳがシステムリソースのパーティションの制御を維持する本発明の一実施形態による保安サーバー機能を提供するように構成されたコンピュータシステムを概念的に示す。
【図３Ｂ】ＳＧＰＯＳが中止状態（ｄｏｒｍａｎｔ  ｓｔａｔｅ）にあり、ＣＥ２にシステムリソースの完全制御をわたす本発明の代替的実施形態による、保安サーバー機能を提供するように構成されたコンピュータシステムを概念的に示す。
【図４】本発明の一実施形態による、１つ以上のゲストオペレーションシステムを支援するアーキテクチャーを概念的に示す。
【図５】本発明の一実施形態による非同期網Ｉ／Ｏスタックの動作を示すデータフロー及び制御フローダイアグラムである。
【図１】
2008524878.tif 000005
【図２】
2008524878.tif 000006
【図３Ａ】
2008524878.tif 000007
【図３Ｂ】
2008524878.tif 000008
【図４】
2008524878.tif 000009
【図５】
2008524878.tif 000010