JPH10340238A - Tcp/ipソケット・アプリケーションを使用したシステム資源削減装置 - Google Patents
Tcp/ipソケット・アプリケーションを使用したシステム資源削減装置Info
- Publication number
- JPH10340238A JPH10340238A JP10131619A JP13161998A JPH10340238A JP H10340238 A JPH10340238 A JP H10340238A JP 10131619 A JP10131619 A JP 10131619A JP 13161998 A JP13161998 A JP 13161998A JP H10340238 A JPH10340238 A JP H10340238A
- Authority
- JP
- Japan
- Prior art keywords
- data
- command
- name
- token
- program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5629—Admission control
- H04L2012/5631—Resource management and allocation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Multi Processors (AREA)
Abstract
(57)【要約】
【課題】 少なくとも1つの常駐オペレーティング・シ
ステムを有するコンピュータ・システム内に、データ処
理ツールを導入する。 【解決手段】 読取り/受信コマンドを受信したとき
に、特殊なインタフェース関数呼出しを発行し、読取り
/受信要求側アプリケーションまたはプロセッサに関連
するプログラム名およびトークンに関する情報を保存す
る。次いで、データ通信プロトコルを識別するソケット
記述子を生成する。さらにまた、プログラム名、および
トークン情報およびソケット記述子に関する情報を含む
システム制御テーブル・エントリを生成する。データが
到着した後、このファイルは、読取り/受信コマンドの
処理および要求側アプリケーション/プロセッサへの関
連する処理情報の返送を可能にする。
ステムを有するコンピュータ・システム内に、データ処
理ツールを導入する。 【解決手段】 読取り/受信コマンドを受信したとき
に、特殊なインタフェース関数呼出しを発行し、読取り
/受信要求側アプリケーションまたはプロセッサに関連
するプログラム名およびトークンに関する情報を保存す
る。次いで、データ通信プロトコルを識別するソケット
記述子を生成する。さらにまた、プログラム名、および
トークン情報およびソケット記述子に関する情報を含む
システム制御テーブル・エントリを生成する。データが
到着した後、このファイルは、読取り/受信コマンドの
処理および要求側アプリケーション/プロセッサへの関
連する処理情報の返送を可能にする。
Description
【0001】
【発明の属する技術分野】本発明は、TCP/IPソケ
ット・アプリケーション中などの通信セッション中に発
行された読取り機能などの特定のコマンドを処理してい
る間にシステムによって使用される資源を削減するよう
に設計されたツールに関する。
ット・アプリケーション中などの通信セッション中に発
行された読取り機能などの特定のコマンドを処理してい
る間にシステムによって使用される資源を削減するよう
に設計されたツールに関する。
【0002】
【従来の技術】ホスト・システム・ネットワークまたは
その他の同様のマルチホスト・コンピュータ環境では、
いくつかのプロセッサとホストが共存し、それらが同時
にデータの要求とアクセスを行ったり異なる常駐アプリ
ケーションを実行したりする。そのような環境では、デ
ータ処理システムを使用してその環境全体の様々な場所
で必要なデータを維持し、様々なアプリケーションの処
理を行う。これによって、遠隔ホストまたはユーザに単
一のイメージを提示することができ、プロセッサ複合体
による負荷分散が可能になる。データは環境内の通信リ
ンクのネットワークを形成する遠隔ホストおよびその他
のホスト・システムにリンクされた1つまたは複数のホ
スト・システムで維持することができる。リンク上の1
つのホストからリンク上の他のホストにメッセージを送
信するために、プロトコルと呼ばれる通信規則を確立し
て、メッセージを経路指定し、複合体または環境内のリ
ンク上の適切なホスト・コンピュータにアクセスするこ
とによって通信を制御する。このような通信プロトコル
は一般に、データ通信製品の機能と構造を規定する遠隔
処理アーキテクチャの一部として存在する。
その他の同様のマルチホスト・コンピュータ環境では、
いくつかのプロセッサとホストが共存し、それらが同時
にデータの要求とアクセスを行ったり異なる常駐アプリ
ケーションを実行したりする。そのような環境では、デ
ータ処理システムを使用してその環境全体の様々な場所
で必要なデータを維持し、様々なアプリケーションの処
理を行う。これによって、遠隔ホストまたはユーザに単
一のイメージを提示することができ、プロセッサ複合体
による負荷分散が可能になる。データは環境内の通信リ
ンクのネットワークを形成する遠隔ホストおよびその他
のホスト・システムにリンクされた1つまたは複数のホ
スト・システムで維持することができる。リンク上の1
つのホストからリンク上の他のホストにメッセージを送
信するために、プロトコルと呼ばれる通信規則を確立し
て、メッセージを経路指定し、複合体または環境内のリ
ンク上の適切なホスト・コンピュータにアクセスするこ
とによって通信を制御する。このような通信プロトコル
は一般に、データ通信製品の機能と構造を規定する遠隔
処理アーキテクチャの一部として存在する。
【0003】このようなコンピュータ・ネットワークま
たは環境では、1つまたは複数のオペレーティング・シ
ステムによって供給される機能インターフェースである
アプリケーション・プログラム・インタフェース(以下
APIと呼ぶ)も設けられ、高水準言語で書かれたアプ
リケーション・プログラムがオペレーティング・システ
ムの特定のデータまたは機能を使用することができるよ
うにする。場合によっては、APIはアプリケーション
・プログラムがそれを介してアクセス方法と対話するイ
ンタフェースとして機能する。マルチタスク・オペレー
ティング・システムでは、アプリケーション・プログラ
ムの要求がAPIを介してオペレーティング・システム
に対して行われ、要求によって、実行するタスクまたは
プロセスが自動的に開始される。並列処理環境では、コ
ンピュータ・アーキテクチャは大量のタスクを高速で同
時に処理するために、相互接続された多くのプロセッサ
を使用して大量のデータにアクセスする。このような環
境では、マルチタスク・オペレーティング・システムは
適時のタスク処理のためにAPIに大きく依存してい
る。
たは環境では、1つまたは複数のオペレーティング・シ
ステムによって供給される機能インターフェースである
アプリケーション・プログラム・インタフェース(以下
APIと呼ぶ)も設けられ、高水準言語で書かれたアプ
リケーション・プログラムがオペレーティング・システ
ムの特定のデータまたは機能を使用することができるよ
うにする。場合によっては、APIはアプリケーション
・プログラムがそれを介してアクセス方法と対話するイ
ンタフェースとして機能する。マルチタスク・オペレー
ティング・システムでは、アプリケーション・プログラ
ムの要求がAPIを介してオペレーティング・システム
に対して行われ、要求によって、実行するタスクまたは
プロセスが自動的に開始される。並列処理環境では、コ
ンピュータ・アーキテクチャは大量のタスクを高速で同
時に処理するために、相互接続された多くのプロセッサ
を使用して大量のデータにアクセスする。このような環
境では、マルチタスク・オペレーティング・システムは
適時のタスク処理のためにAPIに大きく依存してい
る。
【0004】必要なタスク処理を遅滞なく行うために、
多くのAPIはプロセスのグループ間で複合通信を行う
ための集合操作のセットを定義する。集合的操作には使
いやすさやパフォーマンスを始め、それに付随するいく
つかの利点がある。しかし、集合操作の使用には1つの
大きな欠点がある。ほとんどの場合、それらの集合操作
の多くは同期し、タスクを実行する時がくるまでプロセ
ッサを「ブロック」する。このため「ブロッキング」操
作と呼ばれる。そのタスクが本質的に同期されないアプ
リケーションの解決策は、「非ブロッキング」または非
同期集合操作を使用することである。非ブロッキング操
作によって、各タスクはそのタスク独自のペースで進む
ことができ、必要であれば完了または「待ち」状態にな
っていないか定期的に検査することもできる。しかし、
非ブロッキング操作にはある種の欠点もある。たとえ
ば、待ちが必要な場合、または内部依存関係に遭遇した
場合、意志決定のためにユーザに制御を返す必要があ
る。これは、非同期集合操作を使用する非ブロッキング
環境では、操作全体がタスクのいずれかまたはプロセッ
サ時間を「ブロック」することができないためである。
この依存関係のために、プロセスのただの1段階も操作
をブロックすることができない。
多くのAPIはプロセスのグループ間で複合通信を行う
ための集合操作のセットを定義する。集合的操作には使
いやすさやパフォーマンスを始め、それに付随するいく
つかの利点がある。しかし、集合操作の使用には1つの
大きな欠点がある。ほとんどの場合、それらの集合操作
の多くは同期し、タスクを実行する時がくるまでプロセ
ッサを「ブロック」する。このため「ブロッキング」操
作と呼ばれる。そのタスクが本質的に同期されないアプ
リケーションの解決策は、「非ブロッキング」または非
同期集合操作を使用することである。非ブロッキング操
作によって、各タスクはそのタスク独自のペースで進む
ことができ、必要であれば完了または「待ち」状態にな
っていないか定期的に検査することもできる。しかし、
非ブロッキング操作にはある種の欠点もある。たとえ
ば、待ちが必要な場合、または内部依存関係に遭遇した
場合、意志決定のためにユーザに制御を返す必要があ
る。これは、非同期集合操作を使用する非ブロッキング
環境では、操作全体がタスクのいずれかまたはプロセッ
サ時間を「ブロック」することができないためである。
この依存関係のために、プロセスのただの1段階も操作
をブロックすることができない。
【0005】しかし、ユーザに制御を返すことは問題の
一部にすぎない。ユーザに制御が返された後の1つの大
きな問題は、元の内部依存関係が解決された場合など
に、いつ操作を再開することができるかを通知する問題
である。第2の関連する問題は、ユーザが操作の再開を
決定した後で、中断が行われる前と同じ処理箇所に戻る
ことである。
一部にすぎない。ユーザに制御が返された後の1つの大
きな問題は、元の内部依存関係が解決された場合など
に、いつ操作を再開することができるかを通知する問題
である。第2の関連する問題は、ユーザが操作の再開を
決定した後で、中断が行われる前と同じ処理箇所に戻る
ことである。
【0006】ブロッキング操作と非ブロッキング操作の
両方で発生する他の関連する共通の問題は、パフォーマ
ンス問題とシステム遊休時間の解決である。rea
d()やrecvfrom()呼出などの特定のコマン
ドは、読取りコマンドまたは受信コマンドのデータが要
求側アプリケーションによって受け取られるまでシステ
ム環境が一時的に操作の処理を中断する必要がある。デ
ータを処理のためにただちに入手することができない場
合、アプリケーションにとって使用可能な資源の大部分
が中断状態になり、データが入手可能になるまではそれ
以上処理が使用可能にならない。ブロッキング・モード
では、コマンド処理の順次性によってプロセス環境全体
が強制的に着信データを待ってからでなければ、コマン
ド処理の次の段階を行うことができない。非ブロッキン
グ・モードでは、やはりデータをただちに入手すること
ができない場合、プロセス環境はデータの入手可能性を
調べ続けなければならず、したがって非同期操作を同期
操作に変えることになるか、または操作を終了して制御
をユーザに返さなければならず、それによってさらに問
題が生じる。高パフォーマンスのトランザクション指向
システムでは、このようにデータを入手することができ
ないことによって、多くのプロセスが一度にすべて中断
する可能性がある。したがって、システムはどの新しい
プロセスもディスパッチすることができないまま資源を
使い果たすことがある。
両方で発生する他の関連する共通の問題は、パフォーマ
ンス問題とシステム遊休時間の解決である。rea
d()やrecvfrom()呼出などの特定のコマン
ドは、読取りコマンドまたは受信コマンドのデータが要
求側アプリケーションによって受け取られるまでシステ
ム環境が一時的に操作の処理を中断する必要がある。デ
ータを処理のためにただちに入手することができない場
合、アプリケーションにとって使用可能な資源の大部分
が中断状態になり、データが入手可能になるまではそれ
以上処理が使用可能にならない。ブロッキング・モード
では、コマンド処理の順次性によってプロセス環境全体
が強制的に着信データを待ってからでなければ、コマン
ド処理の次の段階を行うことができない。非ブロッキン
グ・モードでは、やはりデータをただちに入手すること
ができない場合、プロセス環境はデータの入手可能性を
調べ続けなければならず、したがって非同期操作を同期
操作に変えることになるか、または操作を終了して制御
をユーザに返さなければならず、それによってさらに問
題が生じる。高パフォーマンスのトランザクション指向
システムでは、このようにデータを入手することができ
ないことによって、多くのプロセスが一度にすべて中断
する可能性がある。したがって、システムはどの新しい
プロセスもディスパッチすることができないまま資源を
使い果たすことがある。
【0007】
【発明が解決しようとする課題および課題を解決するた
めの手段】少なくとも1つの常駐オペレーティング・シ
ステムを有するコンピュータ・システム内に、データ処
理ツールを導入する。ツールは、まず読取り/受信コマ
ンドを受信したときに特殊なインタフェース関数呼出し
を発行する。次いで、システムは、オペレーティング・
システムが特定の読取り/受信コマンドを発行したアプ
リケーションまたはプロセッサに関連するプログラム名
およびトークンを保存する間、他の動作を復帰または継
続する。次いで、データ通信プロトコルを識別するソケ
ット記述子を生成する。さらにまた、プログラム名およ
びトークン情報をデータ構造フォーマット中に保存し、
かつそれらを前記ソケット記述子に関連付けるファイル
記述子を有するシステム制御テーブル・エントリを生成
する。データが到着した後、このシステム制御テーブル
を見つけ出し、ソケット記述子の所在に関する記憶され
た情報を見つけることによって要求側アプリケーション
またはプロセッサを識別する。次いで、要求側プログラ
ムの名前を得た後で新たに到着したデータを処理する新
しいプロセスを生成し、最後に読取り/受信コマンドを
処理する。
めの手段】少なくとも1つの常駐オペレーティング・シ
ステムを有するコンピュータ・システム内に、データ処
理ツールを導入する。ツールは、まず読取り/受信コマ
ンドを受信したときに特殊なインタフェース関数呼出し
を発行する。次いで、システムは、オペレーティング・
システムが特定の読取り/受信コマンドを発行したアプ
リケーションまたはプロセッサに関連するプログラム名
およびトークンを保存する間、他の動作を復帰または継
続する。次いで、データ通信プロトコルを識別するソケ
ット記述子を生成する。さらにまた、プログラム名およ
びトークン情報をデータ構造フォーマット中に保存し、
かつそれらを前記ソケット記述子に関連付けるファイル
記述子を有するシステム制御テーブル・エントリを生成
する。データが到着した後、このシステム制御テーブル
を見つけ出し、ソケット記述子の所在に関する記憶され
た情報を見つけることによって要求側アプリケーション
またはプロセッサを識別する。次いで、要求側プログラ
ムの名前を得た後で新たに到着したデータを処理する新
しいプロセスを生成し、最後に読取り/受信コマンドを
処理する。
【0008】
【発明の実施の形態】コンピュータ・ネットワークにい
くつかのホストや遠隔ホストを接続する場合、それらの
間に通信をセットアップし、維持する必要が生じる。通
信を可能にするために、ホスト・システムのネットワー
クは通信リンクを含み、それらのリンクに異なる種類の
ホスト・コンピュータが接続される。リンク上の1つの
ホストからリンク上の他のホストにメッセージを送信す
るために、プロトコルと呼ぶ規則を確立して通信リンク
を制御し、メッセージを経路指定し、リンク上の適切な
ホスト・コンピュータにアクセスする。
くつかのホストや遠隔ホストを接続する場合、それらの
間に通信をセットアップし、維持する必要が生じる。通
信を可能にするために、ホスト・システムのネットワー
クは通信リンクを含み、それらのリンクに異なる種類の
ホスト・コンピュータが接続される。リンク上の1つの
ホストからリンク上の他のホストにメッセージを送信す
るために、プロトコルと呼ぶ規則を確立して通信リンク
を制御し、メッセージを経路指定し、リンク上の適切な
ホスト・コンピュータにアクセスする。
【0009】通信プロトコルは概念的には図1に図示す
るような層状になっているものと見なすことができ、各
プロトコル層はその下にある層によって提供されるサー
ビスを利用する。最下層はリンク層102で、ハードウ
ェア・レベルを扱い、特定のタイプの単一のネットワー
ク上のホスト間のデータの伝送を制御する。その上の層
は、マシン対マシン(MM)層104で、同じ物理複合
体に直接接続されていないホスト間で通信する機能を提
供する。この層の広く使用されている例はインターネッ
ト・プロトコル(IP)である。インターネットIP
は、標準ソフトウェア通信パッケージの使用を可能にす
る標準業界通信プロトコルである。
るような層状になっているものと見なすことができ、各
プロトコル層はその下にある層によって提供されるサー
ビスを利用する。最下層はリンク層102で、ハードウ
ェア・レベルを扱い、特定のタイプの単一のネットワー
ク上のホスト間のデータの伝送を制御する。その上の層
は、マシン対マシン(MM)層104で、同じ物理複合
体に直接接続されていないホスト間で通信する機能を提
供する。この層の広く使用されている例はインターネッ
ト・プロトコル(IP)である。インターネットIP
は、標準ソフトウェア通信パッケージの使用を可能にす
る標準業界通信プロトコルである。
【0010】プロトコルのその上の層はポート対ポート
(PP)層106で、異なるアプリケーション・プログ
ラムを実行する複数のプロセスが遠隔ホストにある遠隔
プロセスと同時に通信することができるようにする。P
P層はMMプロトコル層を使用してホスト機間でデータ
を転送する。PP層はアプリケーション層とインタフェ
ースし、アプリケーション層はプロセスにローカル通信
ポートを割り振り、そのポートを遠隔ホスト上の遠隔ポ
ートに接続し、ローカル・ポートと遠隔ポートとの間で
データを転送する。このようなPPトランスポート・プ
ロトコルの例としては、TCP(転送制御プロトコ
ル)、UDP(ユーザ・データグラム・プロトコル)、
およびXNS(ゼロックス・ネットワーク・システム)
がある。TCPはIPプロトコル・スイート(TCP/
IP)を使用する装置と共に稼働することができる。
(PP)層106で、異なるアプリケーション・プログ
ラムを実行する複数のプロセスが遠隔ホストにある遠隔
プロセスと同時に通信することができるようにする。P
P層はMMプロトコル層を使用してホスト機間でデータ
を転送する。PP層はアプリケーション層とインタフェ
ースし、アプリケーション層はプロセスにローカル通信
ポートを割り振り、そのポートを遠隔ホスト上の遠隔ポ
ートに接続し、ローカル・ポートと遠隔ポートとの間で
データを転送する。このようなPPトランスポート・プ
ロトコルの例としては、TCP(転送制御プロトコ
ル)、UDP(ユーザ・データグラム・プロトコル)、
およびXNS(ゼロックス・ネットワーク・システム)
がある。TCPはIPプロトコル・スイート(TCP/
IP)を使用する装置と共に稼働することができる。
【0011】最上層はアプリケーション層108であ
る。APIもこの層にある。さらに、ソケット・アプリ
ケーションなどのその他の通信アプリケーションもこの
層にある。ソケット・アプリケーションは、ポート識別
子とTCP/IPまたはその他の通信セッション・アド
レスとの連結によって作成された固有ホスト識別子であ
る。
る。APIもこの層にある。さらに、ソケット・アプリ
ケーションなどのその他の通信アプリケーションもこの
層にある。ソケット・アプリケーションは、ポート識別
子とTCP/IPまたはその他の通信セッション・アド
レスとの連結によって作成された固有ホスト識別子であ
る。
【0012】いずれかの高水準アプリケーション、特に
ソケット・アプリケーションを稼働させている間、特定
のタイプのコマンドによって処理の破壊や資源の一時的
保留状態が生じることがある。これは、通常、データを
ただちに入手することができない場合である。たとえ
ば、TCPプロトコルはデータにアクセスするためにr
ead()コマンドを使用していた。UDPプロトコル
は同様のコマンドrecv()/recvfrom()
関数呼出しを使用する。これはTCPプロトコルのre
ad()コマンドと非常によく似ている。どちらの場合
も、read()、recv()、またはrecvfr
om()コマンドでは、着信データを見越してメモリの
かなりの部分がただちに割り振られ、プロセッサによっ
て確保される。メモリのうちのこの割り振られたブロッ
クは通常、最大長または最大データ長と呼ばれ、32K
ないし2メガの範囲とすることができる。
ソケット・アプリケーションを稼働させている間、特定
のタイプのコマンドによって処理の破壊や資源の一時的
保留状態が生じることがある。これは、通常、データを
ただちに入手することができない場合である。たとえ
ば、TCPプロトコルはデータにアクセスするためにr
ead()コマンドを使用していた。UDPプロトコル
は同様のコマンドrecv()/recvfrom()
関数呼出しを使用する。これはTCPプロトコルのre
ad()コマンドと非常によく似ている。どちらの場合
も、read()、recv()、またはrecvfr
om()コマンドでは、着信データを見越してメモリの
かなりの部分がただちに割り振られ、プロセッサによっ
て確保される。メモリのうちのこの割り振られたブロッ
クは通常、最大長または最大データ長と呼ばれ、32K
ないし2メガの範囲とすることができる。
【0013】データがただちに受信されない場合、アプ
リケーションにとって使用可能な資源の大部分が中断状
態になり、データが入手可能になるまでそれ以上処理を
行うことができない。高パフォーマンス・システムで
は、これによって同時に多くのプロセスが中断する可能
性がある。このシステムまたはプロセッサの使用不能状
態は、以下で詳述するようにシステムがブロッキング集
合操作と非ブロッキング集合操作のどちらを稼働させて
いるかに関係なく生じる。
リケーションにとって使用可能な資源の大部分が中断状
態になり、データが入手可能になるまでそれ以上処理を
行うことができない。高パフォーマンス・システムで
は、これによって同時に多くのプロセスが中断する可能
性がある。このシステムまたはプロセッサの使用不能状
態は、以下で詳述するようにシステムがブロッキング集
合操作と非ブロッキング集合操作のどちらを稼働させて
いるかに関係なく生じる。
【0014】A)ブロッキング操作 アプリケーションまたはシステムがブロッキング・モー
ドで稼働している場合、処理操作は同期モードで行われ
る。read()、recv()、またはrecvfr
om()コマンドが発行されたがデータが直ちに使用可
能にならず、システム全体が同期して稼働している場
合、すべてのスレッドはそのデータ・バイトが最終的に
着信する時点まで遊休状態になっていなければならな
い。データが入手可能になる時点までその先の処理を行
うことができない。さらに、メモリの大きな部分をその
データの受信用に割り振らなければならないため、シス
テム環境全体が影響を受けることがある。
ドで稼働している場合、処理操作は同期モードで行われ
る。read()、recv()、またはrecvfr
om()コマンドが発行されたがデータが直ちに使用可
能にならず、システム全体が同期して稼働している場
合、すべてのスレッドはそのデータ・バイトが最終的に
着信する時点まで遊休状態になっていなければならな
い。データが入手可能になる時点までその先の処理を行
うことができない。さらに、メモリの大きな部分をその
データの受信用に割り振らなければならないため、シス
テム環境全体が影響を受けることがある。
【0015】B)非ブロッキング操作 非ブロッキング操作を稼働させている間は、システムの
処理は非同期であり、したがってデータ読取り/受信コ
マンドが発行された後、プロセスはブロッキング操作の
場合と同じ意味では遊休状態にならない。それにもかか
わらず、データを受け取る前のプロセスの操作全体はブ
ロッキング・モードで稼働しているときときわめてよく
似ている。非ブロッキング・モードではシステムが読み
取るデータの可用性を調べ、データがまだ使用不能であ
るとわかるとその都度、決定を行わなければならない。
この決定は、データの可用性を絶えず検査し続け、それ
によってブロッキング操作とほとんど同じ状況を生じさ
せるか、あるいは、割り振られたメモリ空間を抹消し、
現在遊休状態になっているプロセッサの連続動作に必要
な空間割振りを作成し直すことによって、再割り当てす
る必要があるかのいずれかである。
処理は非同期であり、したがってデータ読取り/受信コ
マンドが発行された後、プロセスはブロッキング操作の
場合と同じ意味では遊休状態にならない。それにもかか
わらず、データを受け取る前のプロセスの操作全体はブ
ロッキング・モードで稼働しているときときわめてよく
似ている。非ブロッキング・モードではシステムが読み
取るデータの可用性を調べ、データがまだ使用不能であ
るとわかるとその都度、決定を行わなければならない。
この決定は、データの可用性を絶えず検査し続け、それ
によってブロッキング操作とほとんど同じ状況を生じさ
せるか、あるいは、割り振られたメモリ空間を抹消し、
現在遊休状態になっているプロセッサの連続動作に必要
な空間割振りを作成し直すことによって、再割り当てす
る必要があるかのいずれかである。
【0016】ブロッキングと非ブロッキングのいずれの
場合も、最大長(最大データ長)すなわちデータの受信
のために割り振られたメモリによって高パフォーマンス
・トランザクション・プロセス・システム内で使用可能
な資源の途切れのない可用性に大きな問題が生じる。
場合も、最大長(最大データ長)すなわちデータの受信
のために割り振られたメモリによって高パフォーマンス
・トランザクション・プロセス・システム内で使用可能
な資源の途切れのない可用性に大きな問題が生じる。
【0017】本発明は、activate_on_re
ceipt機構によって上述の問題を解決する。図2に
示すように、(202)でread()、rec
v()、recvfrom()またはその他の同様の関
数呼出しまたはコマンドを受信すると、本発明はact
ivate_on_receipt()コマンドと呼ぶ
新しい関数呼出し(API)を出す(204)。基本的
には、この新しい関数呼出しによってプロセスの操作が
あたかもコマンドがまったく出されなかったかのように
続けられ(206)、それによって元のプロセスはデー
タの最初のバイトが着信する時点まで稼働する。しか
し、状況によっては、読取り/受信が発行された後でプ
ロセスを実際に終了させる必要があることもある。本発
明の代替実施形態では、この問題を解決する。そのよう
な場合、読取り/受信の最初の発行によって開始された
プロセスをまず終了させて資源が解放されるようにす
る。しかし、activate_on_receive
コマンド呼出しは、そのような終了にもかかわらず要求
データの入手を続け、データが着信すると、前述の場合
のように新しいプロセスが作成される。いずれの場合
も、着信データの少なくとも一部を受信するようにメモ
リ内に好ましくは4Kの一時記憶場所を割り振る(20
8)。これによって、最大2メガもの大きな部分を使用
する従来技術とは異なり、そのようなデータの受信のた
めにメモリの小領域が確保される。さらに、最初の4K
のメモリはプロセッサではなくシステム自体によってそ
のつど割り振られ、それによって空間とメモリの可用性
が最も効率的に使用される。これは、システムには、プ
ロセッサのうちのいずれか単独のプロセッサよりもその
ような可用性がよく見えるため、システムは使用可能な
ポケットがあればどのポケットにでも記憶域を割り振る
ことができるからである。
ceipt機構によって上述の問題を解決する。図2に
示すように、(202)でread()、rec
v()、recvfrom()またはその他の同様の関
数呼出しまたはコマンドを受信すると、本発明はact
ivate_on_receipt()コマンドと呼ぶ
新しい関数呼出し(API)を出す(204)。基本的
には、この新しい関数呼出しによってプロセスの操作が
あたかもコマンドがまったく出されなかったかのように
続けられ(206)、それによって元のプロセスはデー
タの最初のバイトが着信する時点まで稼働する。しか
し、状況によっては、読取り/受信が発行された後でプ
ロセスを実際に終了させる必要があることもある。本発
明の代替実施形態では、この問題を解決する。そのよう
な場合、読取り/受信の最初の発行によって開始された
プロセスをまず終了させて資源が解放されるようにす
る。しかし、activate_on_receive
コマンド呼出しは、そのような終了にもかかわらず要求
データの入手を続け、データが着信すると、前述の場合
のように新しいプロセスが作成される。いずれの場合
も、着信データの少なくとも一部を受信するようにメモ
リ内に好ましくは4Kの一時記憶場所を割り振る(20
8)。これによって、最大2メガもの大きな部分を使用
する従来技術とは異なり、そのようなデータの受信のた
めにメモリの小領域が確保される。さらに、最初の4K
のメモリはプロセッサではなくシステム自体によってそ
のつど割り振られ、それによって空間とメモリの可用性
が最も効率的に使用される。これは、システムには、プ
ロセッサのうちのいずれか単独のプロセッサよりもその
ような可用性がよく見えるため、システムは使用可能な
ポケットがあればどのポケットにでも記憶域を割り振る
ことができるからである。
【0018】各activate_on_receip
t呼出しと共にいくつかのパラメータも渡され(20
5)、後の処理を可能にする。図3に示すように、渡さ
れるパラメータは、そのコマンドまたは呼出しを出した
アプリケーションおよびホストを後で識別するためのソ
ケット記述子、プログラム名ポインタ、およびトークン
・ポインタである(303)。ソケット記述子は、前の
socket()API関数呼出しからアプリケーショ
ンが入手した整数であり、TCP/IPまたはその他の
同様のプロトコルのデータ通信セッションのうちのアプ
リケーション側に関連づけられる(332)。プログラ
ム名ポインタには、プロトコルのデータ通信の他方の側
からホストにデータが着信したときに入れられるプログ
ラム名のアドレスが入る。トークン・ポインタには、ア
プリケーションがプロセス間で受け渡しするデータを含
む8バイトのトークンのアドレスが入れられる。
t呼出しと共にいくつかのパラメータも渡され(20
5)、後の処理を可能にする。図3に示すように、渡さ
れるパラメータは、そのコマンドまたは呼出しを出した
アプリケーションおよびホストを後で識別するためのソ
ケット記述子、プログラム名ポインタ、およびトークン
・ポインタである(303)。ソケット記述子は、前の
socket()API関数呼出しからアプリケーショ
ンが入手した整数であり、TCP/IPまたはその他の
同様のプロトコルのデータ通信セッションのうちのアプ
リケーション側に関連づけられる(332)。プログラ
ム名ポインタには、プロトコルのデータ通信の他方の側
からホストにデータが着信したときに入れられるプログ
ラム名のアドレスが入る。トークン・ポインタには、ア
プリケーションがプロセス間で受け渡しするデータを含
む8バイトのトークンのアドレスが入れられる。
【0019】ソケット・アプリケーションがactiv
ate_on_receipt()関数呼出しを出した
後、オペレーティング・システムはプログラム名と8バ
イト・トークンを、そのソケット記述子に関連づけられ
たファイル記述子と呼ばれるデータ構造に保管する(3
34)。データの着信が開始された後、オペレーティン
グ・システムはactivate_on_receip
t()をread()またはrecvfrom()関数
呼出しに変換する。ストリームまたはコネクション指向
(TCP)ソケットに対してactivate_on_
receipt()が発行された場合、システムはその
activate_on_receipt()関数呼出
しをread()関数呼出しに変換する。データグラム
またはコネクションレス(UDP)ソケットに対してa
ctivate_on_receipt()関数呼出し
が出された場合、システムはそのactivate_o
n_receipt()関数呼出しをrecvfrom
()関数呼出しに変換する。read()またはrec
vfrom()は、最大長(32Kまたはそれ以上の要
求)のTCP/IPスタックに対して発行される。
ate_on_receipt()関数呼出しを出した
後、オペレーティング・システムはプログラム名と8バ
イト・トークンを、そのソケット記述子に関連づけられ
たファイル記述子と呼ばれるデータ構造に保管する(3
34)。データの着信が開始された後、オペレーティン
グ・システムはactivate_on_receip
t()をread()またはrecvfrom()関数
呼出しに変換する。ストリームまたはコネクション指向
(TCP)ソケットに対してactivate_on_
receipt()が発行された場合、システムはその
activate_on_receipt()関数呼出
しをread()関数呼出しに変換する。データグラム
またはコネクションレス(UDP)ソケットに対してa
ctivate_on_receipt()関数呼出し
が出された場合、システムはそのactivate_o
n_receipt()関数呼出しをrecvfrom
()関数呼出しに変換する。read()またはrec
vfrom()は、最大長(32Kまたはそれ以上の要
求)のTCP/IPスタックに対して発行される。
【0020】図2(214)に示すように、データの最
初のバイトが着信するとこの機構に通知される。次にこ
の機構は、割り振られた一時記憶場所が着信データを収
容することができる大きさであるかどうかを判断する。
初のバイトが着信するとこの機構に通知される。次にこ
の機構は、割り振られた一時記憶場所が着信データを収
容することができる大きさであるかどうかを判断する。
【0021】受信したデータが4Kの割振り空間より小
さいか等しい場合、受信するデータの残りを受信するた
めにそれ以上の空間を割り当てない。しかし、データが
4Kより長い場合、受信するデータ全体を収容するため
にさらに空間が割り振られる(216)。
さいか等しい場合、受信するデータの残りを受信するた
めにそれ以上の空間を割り当てない。しかし、データが
4Kより長い場合、受信するデータ全体を収容するため
にさらに空間が割り振られる(216)。
【0022】割り振られた場所に最初のデータ・バイト
を受信すると、activate_on_receip
t()コマンドは、元のプロセスを終了させることでシ
ステムを「活動化」するかまたはホストで新しいプロセ
スを作成する。次にデータの読取り、処理、または転送
を行う(213)。(データが着信した後、システムは
新しい記憶域を入手してそのデータをその新しい記憶域
にコピーする必要がある場合がある(218)。後で、
データを受信すると関数呼出しを行うことができる(2
20〜222)。)このプロセスは詳細には以下のよう
に行われる。
を受信すると、activate_on_receip
t()コマンドは、元のプロセスを終了させることでシ
ステムを「活動化」するかまたはホストで新しいプロセ
スを作成する。次にデータの読取り、処理、または転送
を行う(213)。(データが着信した後、システムは
新しい記憶域を入手してそのデータをその新しい記憶域
にコピーする必要がある場合がある(218)。後で、
データを受信すると関数呼出しを行うことができる(2
20〜222)。)このプロセスは詳細には以下のよう
に行われる。
【0023】図3に示すように、ファイル記述子を使用
して、システム制御テーブルで、前に保管していたプロ
グラム名および8バイト・トークンと、当該TCP/I
Pソケットに関連づけられたソケット記述子を探し出す
(338)。システムはそのソケット記述子、8バイト
・トークン、記憶ブロックのアドレス、および内部ヘッ
ダから入手したデータの長さを、システムによって作成
される新しいプロセスに関連づけられた別の制御ブロッ
クにコピーする。ファイル記述子によって、メッセージ
がデータグラム・ソケットから受信されたことが示され
ている場合、システムはメッセージのソース・アドレス
を内部ヘッダから新しいプロセスに関連づけられたブロ
ックにコピーする。システムは次に新しいプロセスを作
成し(339)、ファイル記述子から名前を入手したプ
ログラムに入る。
して、システム制御テーブルで、前に保管していたプロ
グラム名および8バイト・トークンと、当該TCP/I
Pソケットに関連づけられたソケット記述子を探し出す
(338)。システムはそのソケット記述子、8バイト
・トークン、記憶ブロックのアドレス、および内部ヘッ
ダから入手したデータの長さを、システムによって作成
される新しいプロセスに関連づけられた別の制御ブロッ
クにコピーする。ファイル記述子によって、メッセージ
がデータグラム・ソケットから受信されたことが示され
ている場合、システムはメッセージのソース・アドレス
を内部ヘッダから新しいプロセスに関連づけられたブロ
ックにコピーする。システムは次に新しいプロセスを作
成し(339)、ファイル記述子から名前を入手したプ
ログラムに入る。
【0024】データを入手するために、新しいプログラ
ムは、プロセスでシステムから渡されたデータを使用し
て標準のread()、recv()、またはrecv
from()ソケットAPI関数呼出しを出す。システ
ムはシステムがすでにネットワークからデータを入手し
ていることを知っているため、この関数呼出しはTCP
/IPまたはその他の同様のプロトコルのスタックには
送られない。この第2のread()、recv()、
またはrecvfrom()関数呼出しの目的は、プロ
グラムがそれ自体のバッファから、またはオペレーティ
ング・システムから入手したバッファから、データを入
手することができるようにすることである。アプリケー
ションがread()、recv()、またはrecv
from()関数呼出しを出した後、システムはアプリ
ケーションに対してアプリケーションによって指定され
たバッファにデータを返す。
ムは、プロセスでシステムから渡されたデータを使用し
て標準のread()、recv()、またはrecv
from()ソケットAPI関数呼出しを出す。システ
ムはシステムがすでにネットワークからデータを入手し
ていることを知っているため、この関数呼出しはTCP
/IPまたはその他の同様のプロトコルのスタックには
送られない。この第2のread()、recv()、
またはrecvfrom()関数呼出しの目的は、プロ
グラムがそれ自体のバッファから、またはオペレーティ
ング・システムから入手したバッファから、データを入
手することができるようにすることである。アプリケー
ションがread()、recv()、またはrecv
from()関数呼出しを出した後、システムはアプリ
ケーションに対してアプリケーションによって指定され
たバッファにデータを返す。
【0025】本発明の好ましい実施形態では、割振り空
間でデータの最初のバイトを受信した後でデータが4K
の割振り空間よりも大きい場合、(345)に示すよう
にデータを入手するためにread()、rec
v()、またはrecvfrom()コマンドを出し、
それによって着信データの転送またはコピーあるいはそ
の両方のために最大長またはその他の適切な長さの空間
を割り振る。しかし、着信データが最初に割り振った4
Kの空間に入る場合は、上記の場合のread()、r
ecv()、またはrecvfrom()コマンドの代
わりにもう一度activate_on_receip
tコマンドを出す(350)。この第2のactiva
te_on_receipt関数呼出しによって、それ
以上メモリ空間を割り振る必要なしに、割り振られた4
Kのメモリでシステムによるデータの処理が可能にな
る。言い換えると、その場合、より長いデータ・バイト
のコピー操作に対応するために最大長空間を割り振らな
い。
間でデータの最初のバイトを受信した後でデータが4K
の割振り空間よりも大きい場合、(345)に示すよう
にデータを入手するためにread()、rec
v()、またはrecvfrom()コマンドを出し、
それによって着信データの転送またはコピーあるいはそ
の両方のために最大長またはその他の適切な長さの空間
を割り振る。しかし、着信データが最初に割り振った4
Kの空間に入る場合は、上記の場合のread()、r
ecv()、またはrecvfrom()コマンドの代
わりにもう一度activate_on_receip
tコマンドを出す(350)。この第2のactiva
te_on_receipt関数呼出しによって、それ
以上メモリ空間を割り振る必要なしに、割り振られた4
Kのメモリでシステムによるデータの処理が可能にな
る。言い換えると、その場合、より長いデータ・バイト
のコピー操作に対応するために最大長空間を割り振らな
い。
【0026】まとめとして、本発明の構成に関して以下
の事項を開示する。
の事項を開示する。
【0027】(1)少なくとも1つのオペレーティング
・システムを有するコンピュータ・システム内で、読取
り/受信コマンドを受信したときにActivate_
on_receiptアプリケーション・プログラム・
インタフェース関数呼出しを発行する手段と、前記読取
りコマンドを発行したアプリケーションに関連するプロ
グラム名およびトークンを保存する手段と、データ通信
プロトコルを識別するソケット記述子を生成する機構
と、前記プログラム名およびトークン情報をデータ構造
フォーマット中に保存し、かつそれらを前記ソケット記
述子に関連付けるファイル記述子を有するシステム制御
テーブルと、前記要求された読取りコマンドに関連する
データを受け取ったときに、前記システム制御テーブル
を位置指定し、前記ソケット記述子情報が常駐すること
を発見する手段と、前記コンピュータ・システム内で新
しいプロセスを生成し、前記システム制御テーブルから
得られた前記データを要求する前記プログラムの名前を
入力する手段と、前記読取りコマンドを処理する手段と
を含むデータ処理装置。 (2)前記コンピュータ・システムがそれ自体のバッフ
ァからか、またはそのオペレーティング・システムによ
って得られた他のバッファからデータを得ることができ
るように他の読取りコマンドを発行する手段をさらに含
む、上記(1)に記載の装置。 (3)前記データが処理される前に前記一時記憶位置の
サイズが前記着信データよりも小さい場合に他の特殊な
プログラム・インタフェース関数呼出しを発行する手段
をさらに含む、上記(1)に記載の装置。 (4)新しい記憶位置が前記着信データ用に割り振ら
れ、かつ前記データが前記新しい記憶位置にコピーされ
る、上記(3)に記載の装置。 (5)TCP/IP通信プロトロルが使用される、上記
(1)に記載の装置。 (6)前記プログラム名が、前記プログラム名を指示す
るプログラム名ポインタと呼ばれるパラメータによって
識別される、上記(1)に記載の装置。 (7)前記トークン名が、前記プログラム名を指示する
トークン名ポインタと呼ばれるパラメータによって識別
される、上記(1)に記載の装置。 (8)前記プログラム名ポインタが、前記プログラム名
のアドレスを含み、前記データが到着したときに使用さ
れ、データ通信セッションを実施する間に他の点から受
信される、上記(6)に記載の装置。 (9)前記トークン・ポインタが、前記アプリケーショ
ンが前記プロセス間に送っているデータを有する8バイ
ト・トークンのアドレスを含む、上記(7)に記載の装
置。 (10)前記トークン名パラメータの長さが8バイトで
ある、上記(9)に記載の装置。 (11)前記ソケット記述子が前記動作中のアプリケー
ションの通信セッションに関連するパラメータである、
上記(1)に記載の装置。 (12)前記ソケット記述子が整数である、上記(1)
に記載の装置。 (13)前記読取りコマンドが受信コマンドである、上
記(1)に記載の装置。 (14)前記activate_on_receipt
コマンドがデータグラムまたはコネクションレス・ソケ
ットに対して発行される、上記(13)に記載の装置。 (15)前記受信コマンドがrecvfrom()関数
呼出しである、上記(14)に記載の装置。
・システムを有するコンピュータ・システム内で、読取
り/受信コマンドを受信したときにActivate_
on_receiptアプリケーション・プログラム・
インタフェース関数呼出しを発行する手段と、前記読取
りコマンドを発行したアプリケーションに関連するプロ
グラム名およびトークンを保存する手段と、データ通信
プロトコルを識別するソケット記述子を生成する機構
と、前記プログラム名およびトークン情報をデータ構造
フォーマット中に保存し、かつそれらを前記ソケット記
述子に関連付けるファイル記述子を有するシステム制御
テーブルと、前記要求された読取りコマンドに関連する
データを受け取ったときに、前記システム制御テーブル
を位置指定し、前記ソケット記述子情報が常駐すること
を発見する手段と、前記コンピュータ・システム内で新
しいプロセスを生成し、前記システム制御テーブルから
得られた前記データを要求する前記プログラムの名前を
入力する手段と、前記読取りコマンドを処理する手段と
を含むデータ処理装置。 (2)前記コンピュータ・システムがそれ自体のバッフ
ァからか、またはそのオペレーティング・システムによ
って得られた他のバッファからデータを得ることができ
るように他の読取りコマンドを発行する手段をさらに含
む、上記(1)に記載の装置。 (3)前記データが処理される前に前記一時記憶位置の
サイズが前記着信データよりも小さい場合に他の特殊な
プログラム・インタフェース関数呼出しを発行する手段
をさらに含む、上記(1)に記載の装置。 (4)新しい記憶位置が前記着信データ用に割り振ら
れ、かつ前記データが前記新しい記憶位置にコピーされ
る、上記(3)に記載の装置。 (5)TCP/IP通信プロトロルが使用される、上記
(1)に記載の装置。 (6)前記プログラム名が、前記プログラム名を指示す
るプログラム名ポインタと呼ばれるパラメータによって
識別される、上記(1)に記載の装置。 (7)前記トークン名が、前記プログラム名を指示する
トークン名ポインタと呼ばれるパラメータによって識別
される、上記(1)に記載の装置。 (8)前記プログラム名ポインタが、前記プログラム名
のアドレスを含み、前記データが到着したときに使用さ
れ、データ通信セッションを実施する間に他の点から受
信される、上記(6)に記載の装置。 (9)前記トークン・ポインタが、前記アプリケーショ
ンが前記プロセス間に送っているデータを有する8バイ
ト・トークンのアドレスを含む、上記(7)に記載の装
置。 (10)前記トークン名パラメータの長さが8バイトで
ある、上記(9)に記載の装置。 (11)前記ソケット記述子が前記動作中のアプリケー
ションの通信セッションに関連するパラメータである、
上記(1)に記載の装置。 (12)前記ソケット記述子が整数である、上記(1)
に記載の装置。 (13)前記読取りコマンドが受信コマンドである、上
記(1)に記載の装置。 (14)前記activate_on_receipt
コマンドがデータグラムまたはコネクションレス・ソケ
ットに対して発行される、上記(13)に記載の装置。 (15)前記受信コマンドがrecvfrom()関数
呼出しである、上記(14)に記載の装置。
【図1】使用する通信プロトコルの概念層を示すブロッ
ク図である。
ク図である。
【図2】本発明の概要を示すフローチャートである。
【図3】本発明の特定の実施形態を示すフローチャート
である。
である。
【符号の説明】 102 リンク層 104 マシン対マシン(MM)層 106 ポート対ポート(PP)層 108 アプリケーション層
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ロバート・オー・ドライフース アメリカ合衆国12603 ニューヨーク州ポ ーキプシー マンダレイ・ドライブ 14 (72)発明者 ラプヤン・ラウ アメリカ合衆国12603−0704 ニューヨー ク州ポーキプシー スプリングサイド・ロ ード 7 (72)発明者 ロバート・ビー・ヴァンドンゲン アメリカ合衆国12540 ニューヨーク州ラ グランジュビル バーモア・ロード 54 (72)発明者 シュフイ・ワーナー アメリカ合衆国06804 コネチカット州ブ ルックフィールド エドナ・コート 12 (72)発明者 ダニエル・エル・イー アメリカ合衆国06801 コネチカット州ベ セル シャロン・コート 11
Claims (15)
- 【請求項1】少なくとも1つのオペレーティング・シス
テムを有するコンピュータ・システム内で、 読取り/受信コマンドを受信したときにActivat
e_on_receiptアプリケーション・プログラ
ム・インタフェース関数呼出しを発行する手段と、 前記読取りコマンドを発行したアプリケーションに関連
するプログラム名およびトークンを保存する手段と、 データ通信プロトコルを識別するソケット記述子を生成
する機構と、 前記プログラム名およびトークン情報をデータ構造フォ
ーマット中に保存し、かつそれらを前記ソケット記述子
に関連付けるファイル記述子を有するシステム制御テー
ブルと、 前記要求された読取りコマンドに関連するデータを受け
取ったときに、前記システム制御テーブルを位置指定
し、前記ソケット記述子情報が常駐することを発見する
手段と、 前記コンピュータ・システム内で新しいプロセスを生成
し、前記システム制御テーブルから得られた前記データ
を要求する前記プログラムの名前を入力する手段と、 前記読取りコマンドを処理する手段とを含むデータ処理
装置。 - 【請求項2】前記コンピュータ・システムがそれ自体の
バッファからか、またはそのオペレーティング・システ
ムによって得られた他のバッファからデータを得ること
ができるように他の読取りコマンドを発行する手段をさ
らに含む、請求項1に記載の装置。 - 【請求項3】前記データが処理される前に前記一時記憶
位置のサイズが前記着信データよりも小さい場合に他の
特殊なプログラム・インタフェース関数呼出しを発行す
る手段をさらに含む、請求項1に記載の装置。 - 【請求項4】新しい記憶位置が前記着信データ用に割り
振られ、かつ前記データが前記新しい記憶位置にコピー
される、請求項3に記載の装置。 - 【請求項5】TCP/IP通信プロトロルが使用され
る、請求項1に記載の装置。 - 【請求項6】前記プログラム名が、前記プログラム名を
指示するプログラム名ポインタと呼ばれるパラメータに
よって識別される、請求項1に記載の装置。 - 【請求項7】前記トークン名が、前記プログラム名を指
示するトークン名ポインタと呼ばれるパラメータによっ
て識別される、請求項1に記載の装置。 - 【請求項8】前記プログラム名ポインタが、前記プログ
ラム名のアドレスを含み、前記データが到着したときに
使用され、データ通信セッションを実施する間に他の点
から受信される、請求項6に記載の装置。 - 【請求項9】前記トークン・ポインタが、前記アプリケ
ーションが前記プロセス間に送っているデータを有する
8バイト・トークンのアドレスを含む、請求項7に記載
の装置。 - 【請求項10】前記トークン名パラメータの長さが8バ
イトである、請求項9に記載の装置。 - 【請求項11】前記ソケット記述子が前記動作中のアプ
リケーションの通信セッションに関連するパラメータで
ある、請求項1に記載の装置。 - 【請求項12】前記ソケット記述子が整数である、請求
項1に記載の装置。 - 【請求項13】前記読取りコマンドが受信コマンドであ
る、請求項1に記載の装置。 - 【請求項14】前記activate_on_rece
iptコマンドがデータグラムまたはコネクションレス
・ソケットに対して発行される、請求項13に記載の装
置。 - 【請求項15】前記受信コマンドがrecvfro
m()関数呼出しである、請求項14に記載の装置。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US86481497A | 1997-05-29 | 1997-05-29 | |
US08/864814 | 1997-05-29 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH10340238A true JPH10340238A (ja) | 1998-12-22 |
Family
ID=25344132
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP10131619A Pending JPH10340238A (ja) | 1997-05-29 | 1998-05-14 | Tcp/ipソケット・アプリケーションを使用したシステム資源削減装置 |
Country Status (2)
Country | Link |
---|---|
JP (1) | JPH10340238A (ja) |
KR (1) | KR19980086589A (ja) |
-
1998
- 1998-04-13 KR KR1019980013051A patent/KR19980086589A/ko not_active Application Discontinuation
- 1998-05-14 JP JP10131619A patent/JPH10340238A/ja active Pending
Also Published As
Publication number | Publication date |
---|---|
KR19980086589A (ko) | 1998-12-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5991797A (en) | Method for directing I/O transactions between an I/O device and a memory | |
US5727142A (en) | Method for a non-disruptive host connection switch after detection of an error condition or during a host outage or failure | |
JP3364587B2 (ja) | 通信システムで比較的大きなデータ・オブジェクトの伝送を制御するシステムと方法 | |
JP3553634B2 (ja) | 相互接続インターフェース | |
US5802258A (en) | Loosely coupled system environment designed to handle a non-disruptive host connection switch after detection of an error condition or during a host outage or failure | |
EP1498822B1 (en) | State migration in multiple NIC RDMA enabled devices | |
EP0343820B1 (en) | Temporary state preservation for a distributed file service | |
US20180375782A1 (en) | Data buffering | |
KR100326864B1 (ko) | 네트워크통신방법및네트워크시스템 | |
US6888792B2 (en) | Technique to provide automatic failover for channel-based communications | |
US7543290B2 (en) | Multiple queue pair access with single doorbell | |
US6163812A (en) | Adaptive fast path architecture for commercial operating systems and information server applications | |
EP0889622A2 (en) | System and method for remote buffer allocation and management for message passing between network nodes | |
JP2005535226A (ja) | 高データレートのステートフルプロトコル処理 | |
JP2005538588A (ja) | リモート・ダイレクト・メモリ・アクセス対応ネットワーク・インタフェース・コントローラのスイッチオーバーとスイッチバックのサポート | |
US20050144402A1 (en) | Method, system, and program for managing virtual memory | |
EP1191438A2 (en) | Web server in-kernel interface to data transport system and cache manager | |
US7543037B2 (en) | RDMA completion and retransmit system and method | |
US8539089B2 (en) | System and method for vertical perimeter protection | |
US9069592B2 (en) | Generic transport layer mechanism for firmware communication | |
US20050188070A1 (en) | Vertical perimeter framework for providing application services | |
JP4021780B2 (ja) | 計算機ノード、クラスタシステム、クラスタ管理方法、クラスタ管理プログラム | |
JPH1145220A (ja) | Tcp/ipソケット・アプリケーションを使用したシステム資源削減装置および方法 | |
JPH11149387A (ja) | 共有装置制御方法及びその実施装置 | |
JPH10340238A (ja) | Tcp/ipソケット・アプリケーションを使用したシステム資源削減装置 |