JPH10334015A - Ｔｃｐ／ｉｐソケット・アプリケーションを使用したシステム資源削減方法 - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、マルチホスト・コンピュータ・シ
ステムにおいて、ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉ
ｐｔ機構を使用して不要なシステム遊休時間またはその
他の処理遅延を生じさせないデータ転送の新規な方法を
提供する。 【解決手段】 この機構は、着信データを受信するまで
システム資源を停滞させる可能性のある読取りなどの特
定のコマンドを受信すると一時記憶域を確保する。次
に、システム環境は、着信要求データの最初のバイトを
一時記憶場所で受信するまで他の操作の実行を続け、受
信した時点でこの機構が受信するデータの処理を優先さ
せて実行中のすべての操作を終了させる。要求一時記憶
場所の大きさが着信データの大きさに対応可能な場合、
データは直接読み取られる。そうでない場合は、新しい
記憶場所を入手し、その新しい記憶場所でデータをコピ
ーし、完全に受信してから読み取る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＴＣＰ／ＩＰソケ
ット・アプリケーション中などの通信セッション中に発
行された読取り機能などの特定のコマンドを処理してい
る間にシステムによって使用される資源を削減するよう
に設計されたツールに関する。

【０００２】

【従来の技術】ホスト・システム・ネットワークまたは
その他の同様のマルチホスト・コンピュータ環境では、
いくつかのプロセッサとホストが共存し、それらが同時
にデータの要求とアクセスを行ったり異なる常駐アプリ
ケーションを実行したりする。そのような環境では、デ
ータ処理システムを使用してその環境全体の様々な場所
で必要なデータを維持し、様々なアプリケーションの処
理を行う。これによって、遠隔ホストまたはユーザに単
一のイメージを提示することができ、プロセッサ複合体
による負荷分散が可能になる。データは環境内の通信リ
ンクのネットワークを形成する遠隔ホストおよびその他
のホスト・システムにリンクされた１つまたは複数のホ
スト・システムで維持することができる。リンク上の１
つのホストからリンク上の他のホストにメッセージを送
信するために、プロトコルと呼ばれる通信規則を確立し
て、メッセージを経路指定し、複合体または環境内のリ
ンク上の適切なホスト・コンピュータにアクセスするこ
とによって通信を制御する。このような通信プロトコル
は一般に、データ通信製品の機能と構造を規定する遠隔
処理アーキテクチャの一部として存在する。

【０００３】このようなコンピュータ・ネットワークま
たは環境では、１つまたは複数のオペレーティング・シ
ステムによって供給される機能インターフェースである
アプリケーション・プログラム・インタフェース（以下
ＡＰＩと呼ぶ）も設けられ、高水準言語で書かれたアプ
リケーション・プログラムがオペレーティング・システ
ムの特定のデータまたは機能を使用することができるよ
うにする。場合によっては、ＡＰＩはアプリケーション
・プログラムがそれを介してアクセス方法と対話するイ
ンタフェースとして機能する。マルチタスク・オペレー
ティング・システムでは、アプリケーション・プログラ
ムの要求がＡＰＩを介してオペレーティング・システム
に対して行われ、要求によって、実行するタスクまたは
プロセスが自動的に開始される。並列処理環境では、コ
ンピュータ・アーキテクチャは大量のタスクを高速で同
時に処理するために、相互接続された多くのプロセッサ
を使用して大量のデータにアクセスする。このような環
境では、マルチタスク・オペレーティング・システムは
適時のタスク処理のためにＡＰＩに大きく依存してい
る。

【０００４】必要なタスク処理を遅滞なく行うために、
多くのＡＰＩはプロセスのグループ間で複合通信を行う
ための集合操作のセットを定義する。集合的操作には使
いやすさやパフォーマンスを始め、それに付随するいく
つかの利点がある。しかし、集合操作の使用には１つの
大きな欠点がある。ほとんどの場合、それらの集合操作
の多くは同期し、タスクを実行する時がくるまでプロセ
ッサを「ブロック」する。このため「ブロッキング」操
作と呼ばれる。そのタスクが本質的に同期されないアプ
リケーションの解決策は、「非ブロッキング」または非
同期集合操作を使用することである。非ブロッキング操
作によって、各タスクはそのタスク独自のペースで進む
ことができ、必要であれば完了または「待ち」状態にな
っていないか定期的に検査することもできる。しかし、
非ブロッキング操作にはある種の欠点もある。たとえ
ば、待ちが必要な場合、または内部依存関係に遭遇した
場合、意志決定のためにユーザに制御を返す必要があ
る。これは、非同期集合操作を使用する非ブロッキング
環境では、操作全体がタスクのいずれかまたはプロセッ
サ時間を「ブロック」することができないためである。
この依存関係のために、プロセスのただの１段階も操作
をブロックすることができない。

【０００５】しかし、ユーザに制御を返すことは問題の
一部にすぎない。ユーザに制御が返された後の１つの大
きな問題は、元の内部依存関係が解決された場合など
に、いつ操作を再開することができるかを通知する問題
である。第２の関連する問題は、ユーザが操作の再開を
決定した後で、中断が行われる前と同じ処理箇所に戻る
ことである。

【０００６】ブロッキング操作と非ブロッキング操作の
両方で発生する他の関連する共通の問題は、パフォーマ
ンス問題とシステム遊休時間の解決である。ｒｅａ
ｄ（）やｒｅｃｖｆｒｏｍ（）呼出などの特定のコマン
ドは、読取りコマンドまたは受信コマンドのデータが要
求側アプリケーションによって受け取られるまでシステ
ム環境が一時的に操作の処理を中断する必要がある。デ
ータを処理のためにただちに入手することができない場
合、アプリケーションにとって使用可能な資源の大部分
が中断状態になり、データが入手可能になるまではそれ
以上処理が使用可能にならない。ブロッキング・モード
では、コマンド処理の順次性によってプロセス環境全体
が強制的に着信データを待ってからでなければ、コマン
ド処理の次の段階を行うことができない。非ブロッキン
グ・モードでは、やはりデータをただちに入手すること
ができない場合、プロセス環境はデータの入手可能性を
調べ続けなければならず、したがって非同期操作を同期
操作に変えることになるか、または操作を終了して制御
をユーザに返さなければならず、それによってさらに問
題が生じる。高パフォーマンスのトランザクション指向
システムでは、このようにデータを入手することができ
ないことによって、多くのプロセスが一度にすべて中断
する可能性がある。したがって、システムはどの新しい
プロセスもディスパッチすることができないまま資源を
使い果たすことがある。

【０００７】

【発明が解決しようとする課題】本発明の目的は、シス
テムの可用性とパフォーマンスを向上させることであ
る。

【０００８】本発明の他の目的は、システム制約のため
にシステムを遮断する必要なしにオペレーティング・シ
ステムが多数のトランザクションを処理することができ
るようにすることである。

【０００９】

【課題を解決するための手段】ホストがＴＣＰ／ＩＰな
どの通信プロセッサを使用して互いに通信する、複数の
プロセッサと少なくとも１つの中央メモリとを有するマ
ルチホスト・コンピュータ環境では、データ転送によっ
てシステム全体の動作中断および遊休時間が生じる可能
性がある。本発明は、データを受信してからでなければ
処理を再開することができないプロセッサの１つからコ
マンドを受信すると、ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃ
ｅｉｐｔ関数呼出しを発行するａｃｔｉｖａｔｅ＿ｏｎ
＿ｒｅｃｅｉｐｔ機構を使用する。次に、受信する着信
データの一部を受信するために小さな一次記憶場所を割
り振る。一度受信したデータを識別し、それを要求側ア
プリケーション、プロセッサ、および通信セッションと
関連づけるためにいくつかのパラメータも渡す。システ
ム環境は、その間に着信データの最初のバイトを受信す
る時点まで通常の処理を続ける。一実施形態では、元の
プロセスは正式に終了し資源が解放される。他の実施形
態では、最初のバイトを受け取ると、ａｃｔｉｖａｔｅ
＿ｏｎ＿ｒｅｃｅｉｐｔ機構は着信データを処理するた
めに新しいプロセスの作成を優先して、実行中のプロセ
スを終了させる。着信データが一時割振り記憶場所より
も長い場合、そのデータを収容するために新しい場所を
確保してから残りのビットを受信してデータを読み取
る。そうでない場合は、データを一時記憶場所から読み
取り、新しい記憶場所は割り振らない。

【００１０】

【発明の実施の形態】コンピュータ・ネットワークにい
くつかのホストや遠隔ホストを接続する場合、それらの
間に通信をセットアップし、維持する必要が生じる。通
信を可能にするために、ホスト・システムのネットワー
クは通信リンクを含み、それらのリンクに異なる種類の
ホスト・コンピュータが接続される。リンク上の１つの
ホストからリンク上の他のホストにメッセージを送信す
るために、プロトコルと呼ぶ規則を確立して通信リンク
を制御し、メッセージを経路指定し、リンク上の適切な
ホスト・コンピュータにアクセスする。

【００１１】通信プロトコルは概念的には図１に図示す
るような層状になっているものと見なすことができ、各
プロトコル層はその下にある層によって提供されるサー
ビスを利用する。最下層はリンク層１０２で、ハードウ
ェア・レベルを扱い、特定のタイプの単一のネットワー
ク上のホスト間のデータの伝送を制御する。その上の層
は、マシン対マシン（ＭＭ）層１０４で、同じ物理複合
体に直接接続されていないホスト間で通信する機能を提
供する。この層の広く使用されている例はインターネッ
ト・プロトコル（ＩＰ）である。インターネットＩＰ
は、標準ソフトウェア通信パッケージの使用を可能にす
る標準業界通信プロトコルである。

【００１２】プロトコルのその上の層はポート対ポート
（ＰＰ）層１０６で、異なるアプリケーション・プログ
ラムを実行する複数のプロセスが遠隔ホストにある遠隔
プロセスと同時に通信することができるようにする。Ｐ
Ｐ層はＭＭプロトコル層を使用してホスト機間でデータ
を転送する。ＰＰ層はアプリケーション層とインタフェ
ースし、アプリケーション層はプロセスにローカル通信
ポートを割り振り、そのポートを遠隔ホスト上の遠隔ポ
ートに接続し、ローカル・ポートと遠隔ポートとの間で
データを転送する。このようなＰＰトランスポート・プ
ロトコルの例としては、ＴＣＰ（転送制御プロトコ
ル）、ＵＤＰ（ユーザ・データグラム・プロトコル）、
およびＸＮＳ（ゼロックス・ネットワーク・システム）
がある。ＴＣＰはＩＰプロトコル・スイート（ＴＣＰ／
ＩＰ）を使用する装置と共に稼働することができる。

【００１３】最上層はアプリケーション層１０８であ
る。ＡＰＩもこの層にある。さらに、ソケット・アプリ
ケーションなどのその他の通信アプリケーションもこの
層にある。ソケット・アプリケーションは、ポート識別
子とＴＣＰ／ＩＰまたはその他の通信セッション・アド
レスとの連結によって作成された固有ホスト識別子であ
る。

【００１４】いずれかの高水準アプリケーション、特に
ソケット・アプリケーションを稼働させている間、特定
のタイプのコマンドによって処理の破壊や資源の一時的
保留状態が生じることがある。これは、通常、データを
ただちに入手することができない場合である。たとえ
ば、ＴＣＰプロトコルはデータにアクセスするためにｒ
ｅａｄ（）コマンドを使用していた。ＵＤＰプロトコル
は同様のコマンドｒｅｃｖ（）／ｒｅｃｖｆｒｏｍ（）
関数呼出しを使用する。これはＴＣＰプロトコルのｒｅ
ａｄ（）コマンドと非常によく似ている。どちらの場合
も、ｒｅａｄ（）、ｒｅｃｖ（）、またはｒｅｃｖｆｒ
ｏｍ（）コマンドでは、着信データを見越してメモリの
かなりの部分がただちに割り振られ、プロセッサによっ
て確保される。メモリのうちのこの割り振られたブロッ
クは通常、最大長または最大データ長と呼ばれ、３２Ｋ
ないし２メガの範囲とすることができる。

【００１５】データがただちに受信されない場合、アプ
リケーションにとって使用可能な資源の大部分が中断状
態になり、データが入手可能になるまでそれ以上処理を
行うことができない。高パフォーマンス・システムで
は、これによって同時に多くのプロセスが中断する可能
性がある。このシステムまたはプロセッサの使用不能状
態は、以下で詳述するようにシステムがブロッキング集
合操作と非ブロッキング集合操作のどちらを稼働させて
いるかに関係なく生じる。

【００１６】Ａ）ブロッキング操作 アプリケーションまたはシステムがブロッキング・モー
ドで稼働している場合、処理操作は同期モードで行われ
る。ｒｅａｄ（）、ｒｅｃｖ（）、またはｒｅｃｖｆｒ
ｏｍ（）コマンドが発行されたがデータが直ちに使用可
能にならず、システム全体が同期して稼働している場
合、すべてのスレッドはそのデータ・バイトが最終的に
着信する時点まで遊休状態になっていなければならな
い。データが入手可能になる時点までその先の処理を行
うことができない。さらに、メモリの大きな部分をその
データの受信用に割り振らなければならないため、シス
テム環境全体が影響を受けることがある。

【００１７】Ｂ）非ブロッキング操作 非ブロッキング操作を稼働させている間は、システムの
処理は非同期であり、したがってデータ読取り／受信コ
マンドが発行された後、プロセスはブロッキング操作の
場合と同じ意味では遊休状態にならない。それにもかか
わらず、データを受け取る前のプロセスの操作全体はブ
ロッキング・モードで稼働しているときときわめてよく
似ている。非ブロッキング・モードではシステムが読み
取るデータの可用性を調べ、データがまだ使用不能であ
るとわかるとその都度、決定を行わなければならない。
この決定は、データの可用性を絶えず検査し続け、それ
によってブロッキング操作とほとんど同じ状況を生じさ
せるか、あるいは、割り振られたメモリ空間を抹消し、
現在遊休状態になっているプロセッサの連続動作に必要
な空間割振りを作成し直すことによって、再割り当てす
る必要があるかのいずれかである。

【００１８】ブロッキングと非ブロッキングのいずれの
場合も、最大長（最大データ長）すなわちデータの受信
のために割り振られたメモリによって高パフォーマンス
・トランザクション・プロセス・システム内で使用可能
な資源の途切れのない可用性に大きな問題が生じる。

【００１９】本発明は、ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅ
ｃｅｉｐｔ機構によって上述の問題を解決する。図２に
示すように、（２０２）でｒｅａｄ（）、ｒｅｃ
ｖ（）、ｒｅｃｖｆｒｏｍ（）またはその他の同様の関
数呼出しまたはコマンドを受信すると、本発明はａｃｔ
ｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔ（）コマンドと呼ぶ
新しい関数呼出し（ＡＰＩ）を出す（２０４）。基本的
には、この新しい関数呼出しによってプロセスの操作が
あたかもコマンドがまったく出されなかったかのように
続けられ（２０６）、それによって元のプロセスはデー
タの最初のバイトが着信する時点まで稼働する。しか
し、状況によっては、読取り／受信が発行された後でプ
ロセスを実際に終了させる必要があることもある。本発
明の代替実施形態では、この問題を解決する。そのよう
な場合、読取り／受信の最初の発行によって開始された
プロセスをまず終了させて資源が解放されるようにす
る。しかし、ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｖｅ
コマンド呼出しは、そのような終了にもかかわらず要求
データの入手を続け、データが着信すると、前述の場合
のように新しいプロセスが作成される。いずれの場合
も、着信データの少なくとも一部を受信するようにメモ
リ内に好ましくは４Ｋの一時記憶場所を割り振る（２０
８）。これによって、最大２メガもの大きな部分を使用
する従来技術とは異なり、そのようなデータの受信のた
めにメモリの小領域が確保される。さらに、最初の４Ｋ
のメモリはプロセッサではなくシステム自体によってそ
のつど割り振られ、それによって空間とメモリの可用性
が最も効率的に使用される。これは、システムには、プ
ロセッサのうちのいずれか単独のプロセッサよりもその
ような可用性がよく見えるため、システムは使用可能な
ポケットがあればどのポケットにでも記憶域を割り振る
ことができるからである。

【００２０】各ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐ
ｔ呼出しと共にいくつかのパラメータも渡され（２０
５）、後の処理を可能にする。図３に示すように、渡さ
れるパラメータは、そのコマンドまたは呼出しを出した
アプリケーションおよびホストを後で識別するためのソ
ケット記述子、プログラム名ポインタ、およびトークン
・ポインタである（３０３）。ソケット記述子は、前の
ｓｏｃｋｅｔ（）ＡＰＩ関数呼出しからアプリケーショ
ンが入手した整数であり、ＴＣＰ／ＩＰまたはその他の
同様のプロトコルのデータ通信セッションのうちのアプ
リケーション側に関連づけられる（３３２）。プログラ
ム名ポインタには、プロトコルのデータ通信の他方の側
からホストにデータが着信したときに入れられるプログ
ラム名のアドレスが入る。トークン・ポインタには、ア
プリケーションがプロセス間で受け渡しするデータを含
む８バイトのトークンのアドレスが入れられる。

【００２１】ソケット・アプリケーションがａｃｔｉｖ
ａｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔ（）関数呼出しを出した
後、オペレーティング・システムはプログラム名と８バ
イト・トークンを、そのソケット記述子に関連づけられ
たファイル記述子と呼ばれるデータ構造に保管する（３
３４）。データの着信が開始された後、オペレーティン
グ・システムはａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐ
ｔ（）をｒｅａｄ（）またはｒｅｃｖｆｒｏｍ（）関数
呼出しに変換する。ストリームまたはコネクション指向
（ＴＣＰ）ソケットに対してａｃｔｉｖａｔｅ＿ｏｎ＿
ｒｅｃｅｉｐｔ（）が発行された場合、システムはその
ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔ（）関数呼出
しをｒｅａｄ（）関数呼出しに変換する。データグラム
またはコネクションレス（ＵＤＰ）ソケットに対してａ
ｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔ（）関数呼出し
が出された場合、システムはそのａｃｔｉｖａｔｅ＿ｏ
ｎ＿ｒｅｃｅｉｐｔ（）関数呼出しをｒｅｃｖｆｒｏｍ
（）関数呼出しに変換する。ｒｅａｄ（）またはｒｅｃ
ｖｆｒｏｍ（）は、最大長（３２Ｋまたはそれ以上の要
求）のＴＣＰ／ＩＰスタックに対して発行される。

【００２２】図２（２１４）に示すように、データの最
初のバイトが着信するとこの機構に通知される。次にこ
の機構は、割り振られた一時記憶場所が着信データを収
容することができる大きさであるかどうかを判断する。

【００２３】受信したデータが４Ｋの割振り空間より小
さいか等しい場合、受信するデータの残りを受信するた
めにそれ以上の空間を割り当てない。しかし、データが
４Ｋより長い場合、受信するデータ全体を収容するため
にさらに空間が割り振られる（２１６）。

【００２４】割り振られた場所に最初のデータ・バイト
を受信すると、ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐ
ｔ（）コマンドは、元のプロセスを終了させることでシ
ステムを「活動化」するかまたはホストで新しいプロセ
スを作成する。次にデータの読取り、処理、または転送
を行う（２１３）。（データが着信した後、システムは
新しい記憶域を入手してそのデータをその新しい記憶域
にコピーする必要がある場合がある（２１８）。後で、
データを受信すると関数呼出しを行うことができる（２
２０〜２２２）。）このプロセスは詳細には以下のよう
に行われる。

【００２５】図３に示すように、ファイル記述子を使用
して、システム制御テーブルで、前に保管していたプロ
グラム名および８バイト・トークンと、当該ＴＣＰ／Ｉ
Ｐソケットに関連づけられたソケット記述子を探し出す
（３３８）。システムはそのソケット記述子、８バイト
・トークン、記憶ブロックのアドレス、および内部ヘッ
ダから入手したデータの長さを、システムによって作成
される新しいプロセスに関連づけられた別の制御ブロッ
クにコピーする。ファイル記述子によって、メッセージ
がデータグラム・ソケットから受信されたことが示され
ている場合、システムはメッセージのソース・アドレス
を内部ヘッダから新しいプロセスに関連づけられたブロ
ックにコピーする。システムは次に新しいプロセスを作
成し（３３９）、ファイル記述子から名前を入手したプ
ログラムに入る。

【００２６】データを入手するために、新しいプログラ
ムは、プロセスでシステムから渡されたデータを使用し
て標準のｒｅａｄ（）、ｒｅｃｖ（）、またはｒｅｃｖ
ｆｒｏｍ（）ソケットＡＰＩ関数呼出しを出す。システ
ムはシステムがすでにネットワークからデータを入手し
ていることを知っているため、この関数呼出しはＴＣＰ
／ＩＰまたはその他の同様のプロトコルのスタックには
送られない。この第２のｒｅａｄ（）、ｒｅｃｖ（）、
またはｒｅｃｖｆｒｏｍ（）関数呼出しの目的は、プロ
グラムがそれ自体のバッファから、またはオペレーティ
ング・システムから入手したバッファから、データを入
手することができるようにすることである。アプリケー
ションがｒｅａｄ（）、ｒｅｃｖ（）、またはｒｅｃｖ
ｆｒｏｍ（）関数呼出しを出した後、システムはアプリ
ケーションに対してアプリケーションによって指定され
たバッファにデータを返す。

【００２７】本発明の好ましい実施形態では、割振り空
間でデータの最初のバイトを受信した後でデータが４Ｋ
の割振り空間よりも大きい場合、（３４５）に示すよう
にデータを入手するためにｒｅａｄ（）、ｒｅｃ
ｖ（）、またはｒｅｃｖｆｒｏｍ（）コマンドを出し、
それによって着信データの転送またはコピーあるいはそ
の両方のために最大長またはその他の適切な長さの空間
を割り振る。しかし、着信データが最初に割り振った４
Ｋの空間に入る場合は、上記の場合のｒｅａｄ（）、ｒ
ｅｃｖ（）、またはｒｅｃｖｆｒｏｍ（）コマンドの代
わりにもう一度ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐ
ｔコマンドを出す（３５０）。この第２のａｃｔｉｖａ
ｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔ関数呼出しによって、それ
以上メモリ空間を割り振る必要なしに、割り振られた４
Ｋのメモリでシステムによるデータの処理が可能にな
る。言い換えると、その場合、より長いデータ・バイト
のコピー操作に対応するために最大長空間を割り振らな
い。

【００２８】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００２９】（１）通信プロトコルを使用してホスト間
で通信するマルチホスト・コンピュータ環境において、
処理遊休時間を生じさせずにデータ転送を処理するａｃ
ｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔ機構を設ける方法
であって、着信要求データの将来の受信および処理を必
要とする前記プロセッサのうちの１つのプロセッサから
要求コマンドを受信するとａｃｔｉｖａｔｅ＿ｏｎ＿ｒ
ｅｃｅｉｐｔ関数呼出しを発行するステップと、前記要
求データの少なくとも一部を受信するために小さな一時
記憶場所を割り振るステップと、前記着信要求データを
後で前記要求側プロセッサと実行アプリケーションとそ
の適切な通信セッションとに返すことができるようにす
るパラメータと、システム資源を解放し、前記一時記憶
域で前記要求データの最初のバイトを受信するまで前記
コンピュータ環境が他の操作に進む他の操作を処理する
ことができるようにするステップと、前記着信要求デー
タの最初のバイトを受信すると、前記着信要求データの
即時処理を扱うために新しいプロセスを作成するステッ
プと、前記要求データの大きさが前記割振り一時記憶域
の大きさを超えない場合に前記割振り一時記憶域から直
接、前記着信要求データを処理するステップと、前記要
求データの大きさが前記一時割振り記憶域の大きさを超
える場合に新しい記憶域を割振り、次に前記一時記憶場
所から前記新しい記憶場所に前記要求データをコピー
し、前記要求データの残りの着信部分を受信してから前
記要求データを処理するステップとを含む方法。 （２）前記システム環境が他の保留操作の処理に進むこ
とができ、前記一時割振り記憶域に前記最初のバイトが
着信したときにのみ前記操作を終了させる、上記（１）
に記載の方法。 （３）前記ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔ呼
出しが発行された後ですべての保留操作を終了させてシ
ステム資源を解放し、次にシステム環境が他のプロセス
を作成し、開始することができるようにし、前記一時割
振り記憶域に前記最初のバイトを受信すると、前記バイ
トを処理することになる新しい操作の作成を優先させて
稼働中のプロセスを終了させる、上記（１）に記載の方
法。 （４）前記一時割振り記憶域の大きさが４Ｋである、上
記（１）に記載の方法。 （５）前記データの前記要求側がソケット・アプリケー
ションであり、前記コンピュータ環境がＴＣＰ／ＩＰ通
信プロトコルを使用する、上記（１）に記載の方法。 （６）前記要求コマンドが関数呼出しである上記（５）
に記載の方法。 （７）データの前記最初のバイトが割り振られた前記一
時記憶場所で受信された後、前記コマンド機構が読取り
コマンドを発行する、上記（６）に記載の方法。 （８）前記要求コマンドがｒｅｃｖｆｒｏｍ（）関数呼
出しである、上記（１）に記載の方法。 （９）前記ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔコ
マンドがＵＤＰソケットなどのデータグラムまたはコネ
クションレス・ソケット・アプリケーションについて発
行され、前記方法が前記要求データの前記最初のバイト
を受信するとｒｅｃｖｆｒｏｍ（）関数呼出しを発行す
るステップをさらに含む、上記（８）に記載の方法。 （１０）渡される前記パラメータがソケット記述子パラ
メータとプログラム名ポインタとトークン・ポインタと
を含む、上記（１）に記載の方法。

【図面の簡単な説明】

【図１】使用する通信プロトコルの概念層を示すブロッ
ク図である。

【図２】本発明の概要を示すフローチャートである。

【図３】本発明の特定の実施形態を示すフローチャート
である。

【符号の説明】

１０２ リンク層 １０４ マシン対マシン（ＭＭ）層 １０６ ポート対ポート（ＰＰ）層 １０８ アプリケーション層

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ロバート・オー・ドライフース アメリカ合衆国12603 ニューヨーク州ポ ーキプシー マンダレイ・ドライブ 14 (72)発明者 ラプヤン・ラウ アメリカ合衆国12603−0704 ニューヨー ク州ポーキプシー スプリングサイド・ロ ード ７ (72)発明者 ロバート・ビー・ヴァンドンゲン アメリカ合衆国12540 ニューヨーク州ラ グランジュビル バーモア・ロード 54 (72)発明者 シュフイ・ワーナー アメリカ合衆国06804 コネチカット州ブ ルックフィールド エドナ・コート 12 (72)発明者 ダニエル・エル・イー アメリカ合衆国06801 コネチカット州ベ セル シャロン・コート 11

Claims (10)

【特許請求の範囲】
1. 【請求項１】通信プロトコルを使用してホスト間で通信
   するマルチホスト・コンピュータ環境において、処理遊
   休時間を生じさせずにデータ転送を処理するａｃｔｉｖ
   ａｔｅ＿ｏｎ＿ｒｅｃｅｉｐｔ機構を設ける方法であっ
   て、 着信要求データの将来の受信および処理を必要とする前
   記プロセッサのうちの１つのプロセッサから要求コマン
   ドを受信するとａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉｐ
   ｔ関数呼出しを発行するステップと、 前記要求データの少なくとも一部を受信するために小さ
   な一時記憶場所を割り振るステップと、 前記着信要求データを後で前記要求側プロセッサと実行
   アプリケーションとその適切な通信セッションとに返す
   ことができるようにするパラメータと、 システム資源を解放し、前記一時記憶域で前記要求デー
   タの最初のバイトを受信するまで前記コンピュータ環境
   が他の操作に進む他の操作を処理することができるよう
   にするステップと、 前記着信要求データの最初のバイトを受信すると、前記
   着信要求データの即時処理を扱うために新しいプロセス
   を作成するステップと、 前記要求データの大きさが前記割振り一時記憶域の大き
   さを超えない場合に前記割振り一時記憶域から直接、前
   記着信要求データを処理するステップと、 前記要求データの大きさが前記一時割振り記憶域の大き
   さを超える場合に新しい記憶域を割振り、次に前記一時
   記憶場所から前記新しい記憶場所に前記要求データをコ
   ピーし、前記要求データの残りの着信部分を受信してか
   ら前記要求データを処理するステップとを含む方法。
2. 【請求項２】前記システム環境が他の保留操作の処理に
   進むことができ、前記一時割振り記憶域に前記最初のバ
   イトが着信したときにのみ前記操作を終了させる、請求
   項１に記載の方法。
3. 【請求項３】前記ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉ
   ｐｔ呼出しが発行された後ですべての保留操作を終了さ
   せてシステム資源を解放し、次にシステム環境が他のプ
   ロセスを作成し、開始することができるようにし、前記
   一時割振り記憶域に前記最初のバイトを受信すると、前
   記バイトを処理することになる新しい操作の作成を優先
   させて稼働中のプロセスを終了させる、請求項１に記載
   の方法。
4. 【請求項４】前記一時割振り記憶域の大きさが４Ｋであ
   る、請求項１に記載の方法。
5. 【請求項５】前記データの前記要求側がソケット・アプ
   リケーションであり、前記コンピュータ環境がＴＣＰ／
   ＩＰ通信プロトコルを使用する、請求項１に記載の方
   法。
6. 【請求項６】前記要求コマンドが関数呼出しである請求
   項５に記載の方法。
7. 【請求項７】データの前記最初のバイトが割り振られた
   前記一時記憶場所で受信された後、前記コマンド機構が
   読取りコマンドを発行する、請求項６に記載の方法。
8. 【請求項８】前記要求コマンドがｒｅｃｖｆｒｏｍ（）
   関数呼出しである、請求項１に記載の方法。
9. 【請求項９】前記ａｃｔｉｖａｔｅ＿ｏｎ＿ｒｅｃｅｉ
   ｐｔコマンドがＵＤＰソケットなどのデータグラムまた
   はコネクションレス・ソケット・アプリケーションにつ
   いて発行され、前記方法が前記要求データの前記最初の
   バイトを受信するとｒｅｃｖｆｒｏｍ（）関数呼出しを
   発行するステップをさらに含む、請求項８に記載の方
   法。
10. 【請求項１０】渡される前記パラメータがソケット記述
    子パラメータとプログラム名ポインタとトークン・ポイ
    ンタとを含む、請求項１に記載の方法。