JP3743963B2 - リモートネットワーク装置を用いる通信システム及び方法 - Google Patents
リモートネットワーク装置を用いる通信システム及び方法 Download PDFInfo
- Publication number
- JP3743963B2 JP3743963B2 JP52414295A JP52414295A JP3743963B2 JP 3743963 B2 JP3743963 B2 JP 3743963B2 JP 52414295 A JP52414295 A JP 52414295A JP 52414295 A JP52414295 A JP 52414295A JP 3743963 B2 JP3743963 B2 JP 3743963B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- driver
- client
- port
- data
- 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.)
- Expired - Lifetime
Links
- 238000004891 communication Methods 0.000 title claims abstract description 78
- 238000000034 method Methods 0.000 title description 14
- 230000002457 bidirectional effect Effects 0.000 claims description 3
- 230000001360 synchronised effect Effects 0.000 abstract description 2
- 239000000872 buffer Substances 0.000 description 87
- 230000005540 biological transmission Effects 0.000 description 50
- 230000004044 response Effects 0.000 description 21
- 230000008859 change Effects 0.000 description 11
- 230000006870 function Effects 0.000 description 9
- 230000008569 process Effects 0.000 description 9
- 230000002093 peripheral effect Effects 0.000 description 7
- ATJFFYVFTNAWJD-UHFFFAOYSA-N Tin Chemical compound [Sn] ATJFFYVFTNAWJD-UHFFFAOYSA-N 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- SRVFFFJZQVENJC-IHRRRGAJSA-N aloxistatin Chemical compound CCOC(=O)[C@H]1O[C@@H]1C(=O)N[C@@H](CC(C)C)C(=O)NCCC(C)C SRVFFFJZQVENJC-IHRRRGAJSA-N 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000000737 periodic effect Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 235000006679 Mentha X verticillata Nutrition 0.000 description 2
- 235000002899 Mentha suaveolens Nutrition 0.000 description 2
- 235000001636 Mentha x rotundifolia Nutrition 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000009432 framing Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/08—Protocols specially adapted for terminal emulation, e.g. Telnet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
Description
（技術分野）
この発明は、汎用ネットワークを通じての、コンピュータとコンピュータ周辺装置のようなディジタル装置間の通信分野に関する。
（背景技術）
互いに遠く離れたディジタルコンピュータとコンピュータ周辺装置間で通信を行うことの必要性が、長い間感じられていた。多くの技術がこの必要性のために設計されてきた。アナログ電話網上での長距離接続を確立するためのモデムの使用や、データ伝送媒体上でコンピュータと周辺装置との通信を行わせるネットワーキングを作ることによって行われた。
モデムは、二つのコンピュータ間での通信を確立させるために一対で用いられ、各モデムはアナログ電話網に接続されるばかりでなく、そのローカルコンピュータのシリアルポートに取り付けられている。シリアルポートはコンピュータに、モデムあるいはプリンタのような周辺装置へ連続的なビットの流れを通過させるようにする。コンピュータや他のマルチユーザコンピュータシステムに基づくＵＮＩＸ上で、この同じシリアルポートは、ユーザにコンピュータとの通信を許容するターミナルとの通信のために用いられる。結果として、単純なことであるが、遠隔地のターミナルが電話線上でマルチユーザコンピュータシステムと通信できるモデムを使用しているということになる。
最新のマルチユーザコンピュータは、同時に多数のユーザをサポートすることができるので、ターミナルがコンピュータと通信できる多くのシリアルポートを有することが望ましい。
あいにくにも、マルチユーザが、しばしば５０以上のターミナル接続をサポートしているので、シリアルポートのすべてを、直接コンピュータ上に取り付けることは論理的に困難である。結果として、マルチプレクサは、多数の内部的に基準となるシリアルポートからの連続トラフィックを単一の通信チャンネルに結合するために用いられていた。このように、ただ一つの通信ケーブルが、コンピュータに接続されることが必要である。
通信ケーブルの他端には、他の多重化装置があり、その装置が、結合されたデータトラフィックを個々のシリアルポートのためのデータに分離してそのシリアルポートに送り、それによってこのデータをアクセスできる。ポートコンセントレータと呼ばれるこのタイプの多重化装置は、コンピュータからリモート側のターミナルへ多数のシリアルポートを供給するために用いられる。主な通信ケーブル上のデータが、モデムを用いる電話線上で伝送されるようなシステム内での多重化を使用することさえ可能である。これは、コンピュータから非常に離れた所でも、多数のマルチプルシリアルポートへのアクセスを可能にする。
ネットワーク技術は、また、あるコンピュータと他のコンピュータあるいは周辺装置間での遠隔通信を可能にするために使用される。比較的、小エリア内でのコンピュータと周辺装置を接続するネットワークは、ローカルエリアネットワークあるいはＬＡＮと呼ばれている。汎用ネットワークは、標準ハードウエアや標準通信プロトコルを用い、マルチベンダの環境で操作される通信システムである。汎用ネットワークのハードウエアは、イーサネット(Ethernet)やトークンリング(Token Ring)のようなＬＡＮの技術を含む。標準ネットワークプロトコルは、ＴＣＰ／ＩＰやＳＰＸ／ＩＰＸを含む。
ＬＡＮは、一般的に伝送媒体によってコンピュータや周辺装置を接続することによって形成され、標準化された通信プロトコルに従って、伝送媒体上で通信が行われる。これらのプロトコルは、データがどのようにフォーマットされるべきか、またデータが特定の装置のためにどのように名付けられるべきかについて、必要条件を明らかにしている。データは、これらのプロトコルに適合しないとネットワーク上に送られない。
ホストオペレーテングシステム上のアプリケーションプログラムは、概して、ホストオペレーテングシステムに従うローカル通信装置のための、応用プログラムインタフェース（ＡＰＩ）に強く依存する。これは、ＵＮＩＸの従来のユーザインタフェースがターミナルコマンドライン操作であるので、ＵＮＩＸのようなシステム上で重要である。
汎用ネットワークは、コネクションレス アンリライアブル データグラム サービス(connectionless unreliable datagram service)や、信頼性双方向バイトストリーム接続の、二つの通信タイプをサポートしている。これら両サービスのＡＰＩは、シリアルポートのＡＰＩとは非常に異なっており、概して（ＴＴＹｓのように知られた）シリアル装置上で実行されるように書かれたプログラムは、正しく実行されるように適合層を必要とする。
ＵＮＩＸの環境で、これは疑似ーｔｔｙあるいはＰＴＴＹ装置として知られる仮想ＴＴＹ装置を用いるネットワークプロトコルであるテルネット(Telnet)やＲログイン(Rlogin)と共に、一般的になされる。ＰＴＴＹ装置は、実質、ソフトウエアであり、ハードウエアではなく、最大コマンドラインプログラムは、それらを充分に実行するようにＵＮＩＸ ＴＴＹｓをエミュレート（模擬）する。
これらＰＴＴＹｓと、実際のシリアルポートハードウエアを制御し、関連する真のＴＴＹｓと区別することは重要である。ＰＴＴＹは、スレーブ部とマスター部を有する。ＰＴＴＹのスレーブ部はＴＴＹエミュレーション装置であり、シリアルポートＡＰＩを機能させるようにプログラムによって使用される。マスター部は、ネットワークにデータを送ることができるテルネットやＲログインのようなネットワークプログラムとやりとりする。
ＰＴＴＹのスレーブ部は、ライン編集用キャラクタ、タブ拡張、及びローカルオペレーテングシステムのライン規則によってなされる他の機能のようなユーザオプションを変更することを要求する。しかしながら、それはボーレート、キャラクタサイズ、受け取ったエラー、ＢＲＥＡＫ信号等を変更することは無視する。
ＰＴＴＹのマスター部は、読み込み、書き込み、及びデータがスレーブとマスターの装置間で前後に通過する方法を変えるための非常に限定された入出力制御のセット（ｉｏｃｔｌｓ）を受け入れる。ＰＴＴＹのマスター部に書かれたデータは、あたかもシリアルポートに受け取ったかのように、ＰＴＴＹのスレーブ部に、受け取られたシリアルデータとして現れる。また、オペレーテングシステムのライン規則によって入力シリアルデータとして処理される。そのときデータは、ＰＴＴＹのスレーブ部から読み込まれるとき、受け取られたデータとして現れる。ＰＴＴＹのスレーブ部に書き込まれたデータは、ＵＮＩＸのライン規則によって連続出力データとして処理され、その後、マスター部に読み込まれる。
ＰＴＴＹのスレーブ部で行われたｉｏｃｔｌ操作は、マスター部では見ることができない。よってＰＴＴＹのマスター部をアクセスするプログラムでは、これらのコールがなされたことを検出することはできない。インタフェースは、ローカルオペレーテングシステムのライン規則では実行できないいくつかの操作をサポートするに充分でない。
多くのインプリメンテーション（実装）において、物理的装置とＰＴＴＹｓとの間に、１対１の対応はない。接続がテルネットあるいはＲログインによってＵＮＩＸシステムになされるとき、これらのプログラムは単にセッションのために次の利用できるＰＴＴＹを割り当てる。よってセッションからセッションへネットワークユーザは、異なったＰＴＴＹ装置を、明らかなパターンでなく、もっともらしく得られる。
これは、疑似ｔｔｙ装置に基づくシステムの安全化あるいはユーザオプションを実行することを困難に、あるいは不可能にする。ある程度までこれを克服するために、特別なプログラムが、特別のＰＴＴＹのマスター部に所属するようなターミナルサーバーベンダによって、普通書かれる。そのＰＴＴＹのスレーブ部は、そのプログラムに所属されたままであり、他の使用に周期的に再割り当てされない。そのようなプログラムは、接続を受け入れ、ログインプログラムを実行するために用いられるが、しかし、しばしばダイアルアウトモデム、プリンタ、あるいは直結型シリアル装置に用いられる。この使用は、テルネットやＲログインより他の使用にＰＴＴＹを拡張する。しかし、真のＴＴＹ装置の制限されたエミュレーションのために、それらは変化したワークアラウンドを要求し、継続的なメインテナンスや両立性の問題を生じる。
テルネットは、また、ポートデータフローコントロールのためにＴＣＰ／ＩＰを使用し、データストリームの先頭データが処理されるまでコマンドが処理されないようにデータと連続してコマンドを送る。結果として、テルネットは、ユーザが割り込みを要求したような、あるコマンドを送るためにＴＣＰ／ＩＰの促進データ特性の使用を要求する。このインプリメンテーションは、中断が処理される前に、ユーザが中断した先頭データを捨てることを要求する。
あいにく、この実行はホストコンピュータばかりでなく、ネットワークそれ自体に非常に大きな負担を生じる。例えば、ネットワークに接続されたリモートターミナルでタイピング(typing)がなされると、個々のキーストローク(keystroke)が行われ、ネットワーク上のホストコンピュータに送られる。それから、ネットワーク上のリモートターミナルにエコーバック(echoed back)される。イーサネット ネットワーク上で、送信されたキャラクタが最少メッセージパケット６４バイトで送信されなければならない。又、アクノリッジ（承認）は６４バイトメッセージパケットである。そのように、二つの６４バイトパケットは、タイプされた各キャラクタに対して送信されなければならない。
さらに、ホストコンピュータによるキャラクタの受け取りは、キャラクタを受け取るためのＰＴＴＹ制御ソフトウエアを実行するタスクスイッチを要求し、また、エコーキャラクタを送信するためにＰＴＴＹ制御ソフトウエアへのタスクスイッチバックを要求する。
ターミナルサーバーと呼ばれる装置は、ネットワークのあるコンピュータへログされることをユーザに要求せずに、シリアルポートを通じてユーザにリモートログイン、テルネット及びＲログインの使用を可能にする。ターミナルサーバー上でシリアルポートに接続されるユーザは、ネットワークのマルチユーザコンピュータに接続するために、Ｒログインあるいはテルネットを使用することができる。
ターミナルサーバーのセカンドユーザは、また同じマルチユーザのコンピュータに接続可能であり、それによってそれに割り当てられたそれ自身のＰＴＴＹと第２の通信リンクを確立できる。テルネット、Ｒログイン、及び同様な手順を通じてターミナルサーバーによってなされた接続は、ネットワークの異なるコンピュータを通じてその手順を使用してなされた接続と同じ不利益を生じる。
（発明の要約）
本発明は、汎用ネットワークのリモートターミナルサーバーに配置された非同期ポートにホストコンピュータを全アクセスさせることによって、従来技術の不利益を克服する通信システムからなる。独特の装置ドライバーインタフェースを使用することによって、また通信プロトコルを多重化することによって、サーバーは単一の接続でマルチポートのためのデータ及び制御コマンドを送信することが可能である。それによって、ネットワーク上の要求を少なくする。
さらに、本発明はローカル通信ポートのすべての特性を有するネットワーク上の真のＴＴＹ装置を提供する。本発明は、モデムやプリンタのような共用装備に正しくアクセスしながら、ネットワークに配置された多数のホストコンピュータに、サーバー上のポートにアクセスすることを可能にする。結局、本発明はハードウエアにインプリメントされ、既存のホストコンピュータソフトウエアとの両立性を増進させ、さらにホストコンピュータのオーバーヘッドを減少させる。
本発明は、リモート通信ポートやそのようなポートを合体するサーバにアクセスする、あるいはアクセスを与えることを望むクライアント（通常ホストコンピュータ）間の汎用ネットワークによって供給される信頼性のある通信リンク上で動作する。
本発明は、汎用ネットワーク上の真のＴＴＹ装置が備えられた従来のＰＴＴＹ実装とは相違する。ＰＴＴＹ実装のようではなく、本発明のＴＴＹは１対１対応である。あたかも、シリアルポートがホストオペレーテングシステムに、直接に接続され、この使用に専念しているかのように、ホストオペレーテングシステムでそのハードウエアを制御させることができる。
それは、応用プログラムによってなされる仮定とを妨げることなく、本発明はこれら限定を緩める。そして、ネットワークの他のホストと共用してその機能を広げ、ＰＢＸ型追跡グループと動的ポートの割当てを共用する。本発明は、それぞれのオペレーテングシステムに真のＴＴＹｓと１対１の対応を維持させる。しかし、ＴＴＹｓが、本発明のオペレーテングシステムに使用されていないとき、他の目的に対してアクセスできるようにすることは任意である。
サーバー上で１あるいはそれ以上のポートを使いたいクライアントは、本発明の「通信プロトコル」によって準備されたプロトコルを使用するそのサーバーへ単一の接続をオープンする。クライアントと通信プロトコルを使用するサーバーとの間のすべての通信は、いかに多くのポートがクライアントによって使用されても、この単一接続を使用して続行する。クライアントとサーバ間の付加的接続がテルネットやＲログインのような従来技術のプロトコルのもとでオープンされてよい。しかし、これら従来技術のプロトコル接続の存在は、本発明の通信プロトコルの制御下でポートに影響しない。クライアントとサーバー間の接続が何らかの理由で破壊されるとき、通信プロトコル制御下ですべてのポートは閉鎖され、そのクライアントによって要求されているすべての資源はもどされる。
通信プロトコル接続の存在は、サーバー上のすべてのポート資源に、クライアントが自動的にアクセスすることを許さない。クライアントがポートにアクセスする前に、最初にポートを幸運にもオープンするに違いない。その後、クライアントがポートをクローズするまで、クライアントはポートへ排他的アクセスを許される。
一度、ポートがオープンされると、クライアントはボーレートを変更するために、要求を出してもよい。クライアントは、ポートにデータを送出し、そしてサーバーはポートに受け取られるすべてのデータを、クライアントに自動的に送る。通信プロトコル下で、クライアントはサーバーから最新のステータスを要求できる。最新のステータスは、要求すれば直ちに得られるか、あるいはクライアントは、クライアントの種々のステータスの状況の変化を知らせるようにサーバーに要求できる。
（発明を実施するための最良の形態）
図１は、ＵＮＩＸコンピュータ１２、デジタル エクィップメント社のＶＡＸコンピュータ１４および特別な場所で用いられる新規なＰＣのネットワーク１６を含む各種コンピュータを相互接続した、ネットワーク１０の概略を示したものである。
ネットワーク１０は、エラーフリー型バイトストリームのデータ伝送用に設けられたプロトコルであれば、ＴＣＰ／ＩＰ、ＳＰＸ／ＩＰＸあるいはＸ．２５等、標準的なネットワーク通信プロトコルを用いることができる。この通信プロトコルは、イーサネット（Ethernet）やトークンリング（Token Ring）のような特定の論理位相数学上で機能する。
図１に示した各種コンピュータとネットワークを接続する典型的なネットワークは、イーサネットのトップ上で作動するＴＣＰ／ＩＰプロトコルが用いられる。プロトコルのＴＣＰの部分は、バイトストリームデータを受け入れてパケットに変換する。ＩＰの部分はこのパケットを受け入れてデータグラムを形成し、その間にイーサネットがデータグラムを受け入れてフレームを形成する。本発明は、用いられるネットワークプロトコルには影響されないが、その説明の目的で典型的な形態が用いられている。
本発明のサーバー２０は、ネットワーク１０の種々のポート（図示を省略した）に接続するように作用する。これらのポートには、サーバー２０に対して複数の通信ライン２２を接続することができる。図１においては、たった５本の通信ライン２２しか示されていないが、サーバー２０は、典型的には１６本あるいはそれ以上をネットワーク１０に接続することができる。
図２は、１つまたはそれ以上のクライアント１８と汎用ネットワークを介して接続されるサーバー２０との間の通信の主な要素を示したものである。クライアント１８は、ＵＮＩＸコンピュータ１２やＶＡＸコンピュータ１４、あるいはローカルネットワーク１６のようなホストコンピュータとすることができる。サーバー２０は、そのネットワークインタフェース３０を通じてネットワーク１０に接続される。ネットワークインタフェース３０は、ネットワーク１０上の他の装置と同様に、サーバー２０がネットワーク１０と通信するために必要とする産業用の標準ハードウエア及びソフトウエアを備えている。すべての産業において標準となるネットワークインタフェースと同様に、このネットワークインタフェース３０は、ネットワーク１０からデータフレームを受け取り、サーバー２０に宛てられたデータかどうかを判断し、もしそうならば、そのデータのネットワークフォーマットをはずしてフレーム、データグラムおよびパケットを組み立てることにより、バイトストリームに有効な形式のデータを作る。すなわち、本発明のネットワークフェース３０は、送信、ネットワーク、リンクの機能と国際標準化機構のオープンシステム相互接続（ＩＳＯ／ＯＳＩ）モデルの物理的な階層を備えている。
ネットワークインタフェース３０によるバイトストリームのデータは、本発明の通信プロトコルの装置を調整する中央処理装置（ＣＰＵ）３２に供給される。通信プロトコルの装置の調整に必要なプログラムモジュールは、サーバーメモリ３４のプログラムメモリ部３６に記憶されている。
ネットワークインタフェース３０から受け取ったデータをＣＰＵ３２が分析した後、生データはサーバー２０の適当なポート４０に通される。ポート４０は、非同期、同期あるいは並列ポートとすることができる。ポート４０に取り付けられるものは、プリンタやモデム等の各種装置とすることができる。
クライアント１８から送信されてポート４０に送られるデータは、ポート４０がデータを送信する準備をするまで、出力または送信バッファ４２に記憶される。各ポート４０を通ってサーバー２０に送られるデータは、同様にして扱われる。ポート４０から来てクライアント１８に送信されるデータは、クライアント１８にネットワーク１０が送信する準備をするまで、入力あるいはレシーブバッファ４４に記憶される。
本発明の通信プロトコルは、ＣＰＵ３２によって実行され、バイトストリームの伝送をネットワーク１０に必要とされるフレーム、データグラムおよびパケット内でフォーマットするステップは、ネットワークインタフェース３０によって処理される。
サーバメモリ３４は、通信プロトコルの装置に完全に必要な状態情報を備えたサーバーのステートバリアブル（状態変数）３８も備えている。本発明の望ましい実施例においてサーバーの状態変数３８に記憶される種類は、表１に示されている。
これらの変数形式は、多数のデータ構造で表され、サーバー２０の働きを制御すると共にクライアント１８とサーバー２０との間の通信を容易にするためのいろいろな方法で用いられる。これらの変数の目的を明らかにするため、以下にその詳細を説明する。
クライアント接続のリストは、通信プロトコルの下で開くサーバー２０への接続を一般的に行うクライアント１８のリストを保存している。好ましい形態では、サーバー２０は、８以上のクライアント接続を同時にサポートできることが望ましい。
メッセージビルドインターバルは、通信プロトコルに従って構成される、あるいはクライアント１８に伝送される情報が必要であるか否かを決定するために、サーバー２０がその状態を内部的に何回ポーリングを行うかを決めるためのポーリング間隔を制御する。好ましい形態では、このポーリングは、１秒あたりほぼ５回行われることが望ましい。その結果、ポーリングは最低でも２０ミリセコンド後には行われ、平均では１０ミリセコンド後に行われる。この間隔は、末端ユーザーに十分であり、ほとんどのスライディング式ウインドウプロトコルにも十分である。
メッセージビルトインターバルでのみ情報を伝送することにより、サーバー２０はそのインターバルの間に情報を蓄積することができる。これにより、ネットワーク１０とクライアント１８の双方の要求により制限されて、一度に１キャラクタのデータしか送れない場合よりもより大きなパケットでデータが送られる。
ポートプンステート変数は、クライアント１８が既にオープンしたポート４０に接続され、あるいはクライアント１８がポート４０のオープンを待つ、複数のトラックのデータ構造となっている。すなわち、このデータは、オープンポート４０のために、一般にクライアント１８がポート４０を保持し、クライアント１８がオープン待ちリスト上にあるトラックを構築する。ポート４０のオープンのさらなる詳細を以下に説明する。
ポート・ボーレート変数は、ポート４０のボーレートを、例えば1,843,200というように、ポートボーレート変数によって分割されて記憶する。この表現は、５０ー１１５Ｋボーの標準的なボーレートをすべて表すために１６ビットだけ必要とする。
フラグ処理変数は、キャラクタサイズ、ハードウエア状態および各ポート４０の入力／出力キャラクタ処理を制御する。サーバーの状態変数に記憶されるフラグは４つの設定がある。すなわち、ＣＦＬＡＧＳ，ＩＦＬＡＧＳ，ＯＦＬＡＧＳ，およびＸＦＬＡＧＳ，である。ＧＦＬＡＧＳ，ＩＦＬＡＧＳ，ＯＦＬＡＧＳは、ＵＮＩＸオペレーテングシステムのターミオ（termio）インタフェースによって標準的に与えられており、本発明においても産業上標準的なものとして用いられている（ＵＮＩＸプログラマーマニュアルではTermio）。
ＣＦＬＡＧＳは、キャラクタサイズ、ストップビットおよびパリティを含むポート４０のＵＡＲＴハードウエアの設定を制御する設定を有している。サーバー２０の装置に理解させる実際のＣＦＬＡＧＳは、CBAUD,CSIZE,CSTOPB,CREAD,PARENB,PARODD,およびHUPCLを含んでいる。同様に、ＩＦＬＡＧＳの設定は、サーバー２０がポート４０から受け取ったデータの処理を制御する設定を有している。
ＩＦＬＡＧＳの設定は、ブレーク条件、エラーハンドリングおよびソフトウエアフロー制御設定の解釈上の制御を含む。サーバー２０で翻訳されるＩＦＬＡＧＳは、IGNBRK,IGNPAR,PARMRK,INPCK,ISTRIP,IXON,IXOFF,IXANY,DOSMODEである。
ＯＦＬＡＧＳは、ポート４０に出力されることによりサーバー２０のデータの処理を制御する。ＯＦＬＡＧＳの設定は、ＣＲおよびＮＬの設定やタブディレイといったことを制御し、OPOST,OLCUC,ONLCR,OCRNL,ONOCR,ONLRET,OFILL,OFDEL,NLDLY,CRDLY,TABDLY,ESDLY,VTDLY,FFDLYを占めるターミオによって定められる。
好ましい形態では、現在の通信設備ではもはや使用されない各種のフラグの設定は、サポートされていない。これらのフラグの設定は、OFILL,OFDEL,NLDLY,CRDLY,BSDLY,VTDLYおよびFFDLY、ＯＦＬＡＧＳからのすべてを含む。これらの各々の設定については、好ましい形態でわずかな修正のみを記載したが、本発明がこれらの記載された設定に限定されることはない。
ＸＦＬＡＧＳは、ターミオＬＦＬＡＧＳから取ったフラグの設定で、追加機能が加えられている。このＸＦＬＡＧＳの設定は、表２に記載されている。
ＸＦＬＡＧＳ変数（ＵＮＩＸラインの分野のXCASEおよびＬＦＬＡＧＳ変数を除く）は、ＵＮＩＸ機能の設定に拡がり、複数のオペレーテングシステムにインタフェースを拡張し、価値付加機能を備えている。ＸＦＬＡＧＳの設定は、ＣＦＬＡＧＳ、ＩＦＬＡＧＳおよびＯＦＬＡＧＳの設定と相互に作用する。この相互作用の詳細は、以下の通りである。
もし、ＸＦＬＡＧＳのＸＰＡＲ設定がリセットされ、あるいは基礎をなすハードウエアがマーク／スペースをサポートしていなければ、ＣＦＬＡＧＳのPARODDの設定がされている場合に残りのパリティを選択し、リセットされている場合にパリティさえも選択する。さもなければ、PARODDが設定されている場合にスペースパリティを、リセットされている場合にマークパリティを選択する。
もし、ＩＦＬＡＧＳのPARMRKおよびＸＦＬＡＧＳのXMODEMが設定されていれば、モデム信号の１またはそれ以上の変化が入力ストリームにFF80MM（書式送り）として入力される。なお、MMは、最新化されたモデム信号値である。
もし、ＸＦＬＡＧＳのXCASEが設定されていれば、所定のアルファベット化されない印刷キャラクタがＵＮＩＸ仕様の出力に相当する２つの文字に変換する。ＸＦＬＡＧＳのXTOSSは、制御の流れの間に出力を再開するキャラクタが無視されるかどうかを制御する。ＩＦＬＡＧＳのIXANYがリセットされると、キャラクタが受け取られたXONあるいはXXONと一致したときのみ、出力が再スタートされる。しかしながら、ＩＦＬＡＧＳのIXANYが設定されているときには、どのようなキャラクタを受け取っても出力を再開する。これにより、XTOSSが設定されていれば、出力を再開するキャラクタは捨てられる。もし、XTOSSがリセットされていれば、出力を開始するいかなる流れない制御キャラクタでもデータストリームに置かれる。
ＸＦＬＡＧＳのXIXONが設定されているときは、流れ制御キャラクタの出力の特別の設定が可能となる。XXOFFの受け取りは、これをXXONが再開している間に、出力を停止する。
フロー制御キャラクタ変数は、どのようなフロー制御キャラクタとなるかが決定される。２つのフロー制御キャラクタの出力の設定がサポートされ、１つのフロー制御キャラクタの入力の設定がサポートされている。さらに、フロー制御エスケープキャラクターは、インタープリテーションなしに、フロー制御キャラクターの入力を許すことをサポートしている。
フロー制御キャラクターは、1)フロー制御始動キャラクターの標準ソフトウエア（ＸＯＮ）、2)フロー制御停止キャラクターの標準ソフトウエア（ＸＯＦＦ）、3)フロー制御始動キャラクターの特別ソフトウエア（ＸＸＯＮ）、4)フロー制御停止キャラクターの特別ソフトウエア（ＸＸＯＦＦ）、5)フロー制御エスケープキャラクター（ＬＮＥＸＴ）を含むものである。
ＬＮＥＸＴキャラクタの受取後、次に受け取られるキャラクタはフロー制御キャラクタとして認識されない。そして両キャラクタは、入力ストリーム中に置かれる。
サーバー状態変数３８に戻ると、クライアント１８へのすべてのモデム制御ファシリティの準備は、８個のモデム制御変数により行われる。これら変数の各々はモデムの操作状態を表すために、マスクを使用する。７個のモデム変数は、表３のように明らかにされる。
表３に示されるすべての変数は、表４に示されるビット割り当てを用いて、モデム信号のセットを示す。
異なったモデム制御変数の使用は、以下のとおりである。ＭＯＵＴモデム制御変数は、クライアント１８によって要求される直近のＲＴＳ及びＤＴＲの値を含む。これらの値は、サーバー２０への要求をすることによって変更される。ＭＦＬＯＷでのＲＴＳ／ＤＴＲピットがセットされるとき、ＭＯＵＴでの対応する値のセットは一時、無視され、これらの信号は、サーバー２０がデータを受け取る準備ができているかどうかを示す。受領が止まると、これらの信号はローの状態にされる。受領が再始動されると、信号はハイの状態にされる。
ＭＦＬＯＷは、「インバンド」出力データを禁止するために使用される。データ、コマンド、及びデータポート内外のデータの通常フローとして同じシーケンス内で取り扱われる応答は、インバンドデータと呼ばれる。データ、コマンド、及び通常データの先頭で伝送され、直ちに受け取られる応答は、アウトオブバンドデータと呼ばれる。ＣＴＳ／ＤＳＲ／ＤＣＤ／ＲＩのいずれかが、ＭＦＬＯＷにセットされるとき、そして、少なくとも対応するハードウエア入力信号がローであるとき、インバンド出力は禁止される。
フロー制御キャラクタ及びトランスミット イミーディエイト キャラクタ（即時伝送キャラクタ）は、フロー制御のソフトウエアあるいはＭＦＬＯＷによって、支配されない。それらは、ＭＣＴＲＬによって与えられるＣＴＳ／ＤＳＲ／ＤＣＤ／ＲＩフロー制御の束縛によって、伝送される。サーバー２０は、ＭＦＬＯＷにセットされないＭＣＴＲＬに何かのビットをリセットする。
ＭＳＴＡＴは、入出力モデム信号の現在の状態を含む。
ＭＬＳＡＴは、クライアント１８に報告されるべき直近のモデムの状態を含む。
ＭＴＲＡＮはクライアント１８に最後に報告されてから、変化があるときのモデム信号
を含む。ＭＳＴＡＴがＭＬＡＳＴに等しくなることは可能であり、ＭＴＲＡＮにセットされたビットを有している。この状態は、ＭＳＴＡＴのいくつかの信号は、少なくとも一つのトランジションを作るということを示し、また、それからクライアント１８へ示した最後の値に戻ることを示している。６個のモデム信号のいずれかがＭＩＮＴにセットされるとき、それらモデム信号の対応する変化は、クライアント１８に報告される。
本発明のサーバー２０は、ポート４０に生じる受信キャラクタエラーの数を見失わないように、サーバー状態変数３８内のポート統計カウンタ毎を維持している。これらのカウンタは、ラインエラーカウンタとして、参照される。異なったカウンタは、以下のカウントのそれぞれを追跡するために使用される：ＵＡＲＴオーバーランエラーの数、バッファオーバーフローエラーの数、フレーミングエラーの数、パリティエラーの数、及び受信されたブレーク（区切り）の数。これら変数のそれぞれは、ポート４０のカテゴリー内で起ったラインエラーの数を見失わないように、１６ビットラップアラウンドのカウンターである。
付加的なラインエラーカウンターの変数は、ミリセカンドでの報告時間を追跡する。もし、この変数がゼロならば、ラインエラーは自動的にクライアント１８に報告されない。さもなければ、サーバー２０は特定インターバルごとにカウンタを検査し、最後の報告があってから、変化があったかどうか、クライアント１８に完全な報告をする。
センドブレーク及びセンドイミーディエイト変数は、ポート４０へブレークあるいは他のキャラクタを直ちに送るかどうかを、クライアント１８に、サーバー２０へ要求することをさせる。センドイミーディエイト変数はクライアント１８が送ることを欲するキャラクタを含む、ワン キャラクタ バッファである。センドブレーク変数は、要求されたブレークのミリセカンドの長さを含む。特殊なケースは、センドブレーク変数の内容にある。ＦＦＦＦの値がセンドブレークに送られるとき、これは無限のブレーク時間を示す。００００がセンドブレークに送られると、進行中のいかなるブレークもキャンセルされる。サーバー２０に送られた他のいかなる値も、センドブレーク時間に単に加えられ、ブレークは二つの要求の結合された時間の間、実行する。
この発明は、ポートフロー制御のためにＴＣＰ／ＩＰフロー制御を使用しないので、クライアント１８あるいはサーバー２０によって受け取られたデータは、いつも直ちに実行される。結果として、インバンドデータの流れを分裂させずに、アウトオブバンドコマンドやデータを送出することは容易である。
サーバー２０は、またサーバー状態変数３８のステータス状況のリストを維持している。これらのステータス状況は、イベント報告変数内に記憶され、クライアント１８に一般的に関心のある状況を示している。クライアント１８は、これらに登録することができ、あるいはサーバー２０が、いつ状況が変化しても、適当なイベント情報を自動的に送ることを要求することができる。イベント報告変数は、サーバー２０にこのイベント情報の送出を追跡することをさせる。表５は、種々のイベント報告変数を示している。
ＥＩＮＴはサーバー２０によってクライアント１８に送られるイベント情報を生じる所定条件を創出するために、クライアント１８によって送られることができる。イベント情報は、（ＥＬＡＳＴ及びＥＩＮＴ）がゼロでない時はいつでも、クライアント１８に送られる。
ＥＳＴＡＴがＥＬＡＳＴに等しく、また、ＥＴＲＡＮ内にビットセットを有しているままである時、可能であることを記しておく。この条件はＥＳＴＡＴ内のある条件が、少なくともワン トランジッションを作り、それからそれらがクライアント１８に報告できる前に、それらのＥＲＡＳＴの値にもどることを示している。
これらの変数に記録されるイベントは、指摘されるイベントがどのようなものであるかを示すマスクに沿って、表６に示されている。表６にあげたイベントは、この発明の文脈内でよく理解される通信イベントである。
サーバー状態変数３８内に記憶された最後の二つの変数は、入力シーケンス及び受信用バッファ・パラメータ変数であり、また関連する出力出力シーケンス及び伝送用バッファ・パラメータである。これら変数は、伝送用バッファ４２及び各ポート４０と関連する受信用バッファ４４の状態を示す。
バッファ４２、４４のデータの流れを通信するために、サーバー２０の好ましい実施例は、１６ビット・ラップアラウンド・シーケンスナンバーを使用している。二つのシーケンスナンバーは、各バッファは４２，４４と関連している。第１のシーケンスナンバーは、バッファ内におかれた次のバイトのシーケンスナンバーを伝達する。この最初のシーケンスナンバーは、伝送用バッファ４２のためのＴＩＮ及び受信用バッファ４４のためのＲＩＮというラベルである。第２のシーケンスナンバーは受信用バッファ４４のためのＲＯＵＴ及び伝送用バッファ４２のためのＴＯＵＴというラベルである。
これらシーケンスナンバーは、ゼロで始まり、送出されるあるいは受け取られるデータの各バイトに対して一つ進む。シーケンスナンバーがＦＦＦＦに達すると、データの次のバイトが送出され、あるいは受け取られるとき、それらはゼロにラップバックする。変数ＴＩＮ、ＴＯＵＴ、ＲＩＮ、及びＲＯＵＴは、クライアント１８とサーバー２０の間で通信するために用いられるシーケンスナンバー変数である、ということが注意されるべきである。それらは、伝送用及び受信用バッファ４２、４４内のデータの物理的位置を特定しない。これらバッファは周知の技術であり、ここでは特に記載しない。
これらシーケンスナンバー、そして入力シーケンス及び受信用バッファパラメータや、出力シーケンス及び伝送用バッファパラメータの変数型をまとめる他の変数は、表７及び８に示されている。
ＴＩＮ、ＴＯＵＴ、ＲＩＮ及びＲＯＵＴのようなラップアラウンドシーケンスナンバーは、いくつかの非常に有効な数学的性質を有する。
しかしながら、シーケンスナンバーはこれらの関数の特別な定義がラップアラウンド特性の結果として使用されなければならないので、加減が行われるとき、特に混乱する。
それらの用途を明らかにするため、伝送用バッファ４２の実施例が図３及び４に図示され、検討されている。実施例３において、ＴＯＵＴシーケンスポインタ（バッファ４２からポート４０へ送出されるデータの次のバイトを示している。そして、矢印５０によって図３に示される。）は、バイトＳにセットされる。ｎバイトのデータが送出されるとき、送出されたバイトは、Ｓ＋（ｎ−１）であるけれども、ナンバーＳとされる。約束によって、われわれは、バッファがＳがＳ＋（ｎ−１）との間の送出バイトを有するということができる。しかしながら、われわれはＯｘＦＦＦＦでラップするシーケンスナンバーに通常の数を加えているので、われわれは次の公式を用いる表現Ｓ＋ｎを計算しなければならない：
（Ｓ＋ｎ）＆０ｘＦＦＦＦ
ここで、＆は、理論的ＡＮＤ操作を示す。このようにして、Ｓが０ｘＦＦＦ８で、ｎが５であれば、Ｓ＋ｎを計算する公式は、０ｘＦＦＦＣを与える。同様に、Ｓが０ｘＦＦＦ８でｎが９であれば、Ｓ＋ｎは２である。
ｎバイトを伝送した後、ＴＯＵＴシーケンスポインターは、伝送されるべき次のバイトの新しい位置に前進させなければならない。これは、古いＴＯＵＴの値を計算された結果Ｓ＋ｎに置き換えることにより行われる。
２つのシーケンスナンバーの間に存在するバイト数を決定するために、引き算が用いられる。しかしながら、特別の規則では、あるシーケンス数を他のシーケンス数から減算する結果を決定することは用いるに違いない。シーケンスナンバーｓ1，ｓ2の間のバイトの数を決定するために、次の公式が用いられる。
（ｓ1−ｓ2）＆0xffff
この公式は、シーケンスナンバーｓ1がシーケンスナンバーｓ2よりも数値的に大きい場合には有効である。例えば、ｓ1＝0xffffかつｓ2＝３であるならば、その時、（ｓ1−ｓ2）＆0xFFFFは、0x13が正しい答である。
実際、シーケンスナンバー間の距離の概念は、次のように定義すると有効となることが重要である。
ＤＩＳＴ(from, to)＝(((to)−(from))＆0xffff)
一対のシーケンスナンバーｓ1，ｓ2を与えると、次の式の条件では、ｓ3は、シーケンスナンバーｓ1，ｓ2の間のバイトのシーケンス位置にあることは真である。
ＤＩＳＴ（ｓ1，ｓ3）＜ＤＩＳＴ（ｓ1，ｓ2）
この公式は、ｓ3は、ｓ1とｓ2の間にあり、ｓ1からｓ3までの距離がｓ1からｓ2までの距離よりも小さい場合に当たる。
シーケンスナンバーは、データの量、すなわち、リモートバッファ内の自由空間の量を伝達できる。図４に示す特定ポート４０に対する伝送用バッファ４２において、ＴＯＵＴシーケンスナンバー５０がｓ1に設定され、一方ポート４０から伝送されるべき次のバイトを表すＴＩＮシーケンスナンバー５２がｓ2に設定される。図４において、ＴＯＵＴとＴＩＮの両方は、伝送用バッファ４２における位置に矢印で示されている。伝送用バッファ４２におけるバイトの数は、そのポートに対して決めることができる。
ＤＩＳＴ（ｓ1，ｓ2）
さらに、そのポートに対する伝送用バッファが、固定サイズＳＩＺＥを有する場合、そのバッファ内の自由バイト数は、次式で定まる。
ＳＩＺＥ−ＤＩＳＴ（ｓ1，ｓ2）
本発明におけるクライアント１８とサーバー２０は、ラップアラウンド・シーケンスナンバーの特性を利用して、両者間の情報のバンド単位の流れを制御することができる。クライアント１８とサーバー２０は、予めそうすることが定められているときにのみ、インバンド−データを他方に送る。この予権限は、データの量を伝送することにより完成するが、他方はそのデータ量に伝送することが許されている。送り手がこのスペースを満たすのに十分なデータを送ったとき、この送り手は、受け手がいくらかのデータを移送し、かつ送り手に追加スペースが利用できることを知らせるまで、伝送を休止する。
クライアント１８からサーバー２０への流れを制御するために、サーバー２０は、クライアント１８にバッファに伝送するサイズを与え、また伝送用バッファ４２(TOUT)における現在の第１バイトのシーケンスを与える。クライアント１８は、クライアント自身のシーケンスナンバーを送り続けながら、以前にサーバーに送ったデータのトラックを保持する。この送られたシーケンスナンバーを用いることによって、そのサーバー２０に与えられた情報に沿って、クライアント１８は、サーバーの伝送用バッファ４２内に残った空のスペースの量を計算することができる。それゆえ、クライアント１８は、その空きスペースに適合するデータ以上のデータを送らなくなる。
このプロセスは、図５のフローチャート図に示されている。伝送スライドを始めるための指示は、図のボックス100に示されている。第１ステップは、データがクライアント１８からサーバー２０のネットワークを介して受信されたか否かを決定する。もしそうであるなら、ボックス102に示すようにデータを受け取り、そしてそのデータを最適なポート４０に対する伝送用バッファ４２に格納される。データは、伝送用バッファに格納されると、ボックス104に示すように、ＴＩＮは、インクリメントされる
データをクライアント１８から受信したか否かに係わらず伝送用バッファ４２内にあるデータは、ポート４０から送り出すことができる。データがある場合、バッファ４２内のデータは、ポート４０上に送り出さなければならない(ボックス108)。そして、ＴＯＵＴは、インクリメントされる(ボックス110)。
この時点で、サーバー２０は、ＴＯＵＴをクライアント１８に報告することが必要であるかどうかを決定しなければならない。判断ボックス112,114,116によって示された３つの判断は、好ましい実施例において利用される。第１の判断112は、伝送されるべき次の出力バイトを示すＴＯＵＴとＴＰＯＳとを比較する。ＴＰＯＳは、出力シーケンス及び伝送用バッファの変数パラメータの１つで、サーバーの状態変数３８内に格納されている。ＴＰＯＳは、クライアント１８に報告された最終ＴＯＵＴの値を示す。上記減算公式のシーケンスナンバーを用いて計算されたＴＯＵＴとＴＭＡＸ間の差が、ＴＭＡＸよりも大きい場合、ＴＯＵＴはクライアントに報告される。ＴＭＡＸは、サーバーの状態変数３８内に格納され、そしてクライアント１８によって、ＴＯＵＴが報告された時点で伝送間隔を決定するために設定される。ＴＯＵＴがクライアント１８に報告されているときは、いつもボックス120で示すように、ＴＰＯＳがその時ボックス122でＴＯＵＴの値が設定される。
ボックス114において、ＴＯＵＴを報告するための第２の判定は、データがバッファ４２内に少なくともＴＴＩＭＥミリセコンド前にあったかを決定し、そして、時間ＴＯＵＴが報告されなかったので、サーバーの状態変数３８であるＴＴＩＭＥが、クライアント１８によって設定される。その場合、ＴＯＵＴはクライアント１８に報告される。
最後の判定116は、ＴＯＵＴの値とＴＲＥＱの値とを比較する。サーバーの状態変数３８の１つとして格納されたＴＲＥＱは、クライアント１８に設定され、その結果、ＴＯＵＴはＴＲＥＱを通過するとき、ＴＯＵＴはクライアント１８に報告される。数学的に、ラップアラウンド・シーケンスナンバーＴＯＵＴとＴＲＥＱを比較すると、上記シーケンスナンバーの減算公式を用いることにより、(TIN−TREQ)が(TIN−TOUT)より大きいか又は等しいかどうかを比較して両者の関係を判定することが必要である。ＴＯＵＴがＴＲＥＱを通過した場合、その時、ＴＲＥＱは、無効にされ（ボックス118）、ＴＯＵＴはクライアント１８に報告される(ボックス120)。
クライアント１８のドライバソフトウエアにおける柔軟性を許容するために、クライアント１８はそうすることが便利である場合には、クライアント１８がサーバーの伝送用バッファ４２がオーバーフローでない限りは、サーバー２０にデータを送ることができる。伝送用バッファ４２がオーバーフローでないことを確実にするための手順は、図６に示されている。
クライアント１８がデータをポート４０に伝送することを望む場合、クライアント１８用の通信プロトコルを処理するクライアント１８側のドライバは、サーバー２０がポートを開くことを要求しなければならない。うまく開くと、クライアント１８は伝送用バッファ４２のサイズＴＳＩＺＥがオープンポート４０に接続され、ＴＯＵＴはゼロとなる。
さらに、クライアント１８は、それ自身の伝送用シーケンスナンバーをリセットし、このシーケンスナンバーは、クライアント１８側に格納され、かつ維持されたラップアラウンドシーケンスナンバーである。
クライアント１８は、その時ボックス132で示すように、サーバーからＴＳＩＺＥを要求する。クライアントは、ボックス140で示すように、ＴＳＴＺＥが以下で説明するようにサーバー２０から受信するまで実際にデータを送ることができない。
クライアント１８は、次に、ホストコンピュータからデータを受信したかどうかを判断する(ボックス134)。データが受信されると、データは伝送用として待機しなければならない(ボックス135)。この伝送の待機については、詳細に後述される。
クライアント１８は、次にボックス136で送られるべきデータがあるかどうかを判定する。送るべきデータが準備されている場合、クライアントのドライバは、伝送用バッファ４２をオーバーフローさせることなくサーバー２０が受け入れることができるバイトの最大数を計算しなければならない(ボックス138)。これは、クライアントの伝送用シーケンスナンバーと最も近時に報告されたＴＯＵＴの値とを比較し、そして、この差を、ＴＳＩＺＥから減算する。
送るべき最大バイト数＝
ＴＳＩＺＥ−（伝送シーケンスナンバー−ＴＯＵＴ）
もちろん、シーケンスナンバーＴＯＵＴのクライアントの伝送シーケンスナンバーからの減算は、減算シーケンスナンバーのための公式に従って行わなければならない。もし、送るべきバイトの計算最大値が、ゼロよりも大きい場合(ボックス140)、バイトの計算最大値まで、サーバー２０に伝送することができる(ボックス144)。クライアント１８の伝送シーケンスナンバーは、その時、送られたバイト数によりインクリメントされる(ボックス146)。
データが送られたか否かに係わらず、クライアント１８は、サーバー２０がボックス148で示すように、ＴＯＵＴまたはＴＳＩＺＥに対する値を伝送したかどうかを次に判定しなければならない。
その場合、クライアント１８で格納されたＴＯＵＴまたはＴＳＩＺＥの値が最新である(ボックス149)。
送信機がだめで、それが報告がされずに、偽りの報告を避けるために、サーバー２０は、非常にまれなケースを認識する。伝送用バッファ４２が空のときで、ＵＡＲＴがまだインバンドーデータを送るのに忙しいときには、サーバー２０は、ＴＯＵＴの代わりに(TOUT−1)を報告する。この変換により、クライアント１８は、サーバー２０に伝送された最後のデータの伝送シーケンスナンバーに等しいＴＯＵＴをクライアントが受けるとき、全てのデータをうまく送ることができるようすることができる。
ポート４０から受け取られ、かつサーバー２０からクライアント１８に伝送される処理は、図７に示されている。このサーバー２０は、サーバーがボックス150で示すようにＲＷＩＮに対する値を受け取るまで、そのデータをクライアント１８に伝送することを許されていない。ＲＷＩＮは、クライアント１８により送られる入力シーケンス及び受信用バッファ変数であり、クライアント１８が受入を望む最高のシーケンスナンバーを示すものである。
初期ＲＷＩＮがクライアント１８から受信した時、サーバー２０、入来データが受信用バッファ４４内に格納されるべく利用できるかどうかを判断するために、ポート４０を調べる(ボックス152)。データが受信されると、受信用バッファ４４内にデータが格納され、そして、ＲＩＮシーケンスナンバーは、従ってインクリメントされる。これは、ボックス154とボックス156に示されている。
クライアント１８が如何に早くサーバー２０からデータを受信できるかということはサーバー２０にとっては知ることができないが、サーバー２０は、ポート上の入力フロー制御を実現する能力を有している。
フロー制御は、受信用バッファ４４内に残るデータの量（(RIN−ROUT)として計算される）がもう１つの入力シーケンス及び受信用バッファのＲＨＩＧＨの値を越える時に開始される。こうして、データが受信用バッファ４４内に格納され、かつＲＩＮがインクリメントされた後、サーバー２０は、入力制御が実施できるか否かを判断する(ボックス162,164)。
フロー制御は、受信用バッファ４４内のデータ量が、入力シーケンス及び受信用バッファ、ＲＬＯＷの値以下に降下するときに解放される。このことは、ボックス158,160で示すように、データがクライアント１８に送られた後に判断する。ステップ152におけるポート４０の検査でポート４０上に新しいデータが見つけられなかった場合、サーバー２０は、データが受信用バッファ４４に送られて利用できるかどうかを決定する。もし利用できない場合には、図７でボックス166に示すように、サーバー２０は、ポート４０にデータが送られるまで再待機する。
データが受信用バッファ４４で利用できるならば、その時、サーバー２０は、クライアント１８に送ることができるバイトの最大数を計算しなければならない(ボックス168)。この最大数は、シーケンスナンバーの減算公式に従って、単純な式(RWIN−ROUT)によって決定できる。この送られるべきバイトの最大数がゼロならば、サーバー２０は、判断ボックス170で示された最新となるべきＲＷＩＮのために待機しなければならない。この計算機がゼロよりも大きければ、サーバー２０は、データバイトをその時点でクライアント１８に送ることが適当であるか否かを判断しなければならない。
２つの判定は、データを伝送するトリガとして使用する。第１の判定(ボックス172)は、受信用バッファ４４内のバイト数(RIN−ROUT)と、クライアント１８によって送ることができる入力シーケンス及び受信用バッファのＲＭＡＸとを比較する。
受信用バッファ４４内のバイトがＲＭＡＸを越えると、バイトの最大数まで、クライアント１８は、送ることができる(ボックス176)。したがって、ＲＯＵＴは、インクリメントされる(ボックス178)。
受信用バッファ４４内のバイト数がＲＭＡＸを越えない場合、サーバー２０は、データが少なくともＲＴＩＭＥミリセコンド前にあったか否かを、さらに、時間データがクライアント１８に送られなかったかを判断する。その場合、判断ボックス174で示すように、データはクライアント１８に送られる。
データがクライアント１８に送られていない場合、データを送るための２つの条件172または174の１つが真となるまで受信用バッファ４４内にデータが残る。
ポート４０が開くと、ＲＭＡＸは１に、ＲＴＩＭＥはゼロに、ＲＬＯＷは１／４に、ＲＳＩＺ，ＲＨＩＧＨは３／４に、全てのシーケンスナンバーはゼロに初期化される。しかし、これらの変数は望ましい値に変更できる。
一般的に、サーバー２０は、そのポート４０にデータを送る時、送ることができるバイトの計算最大数によって制限されなければ、各ポート４０に対して全ての利用可能なデータを送る。この規定は、サーバー２０とクライアント１８の両方が処理しなければならないパケット数を減少させ、そしてクライアント１８の効率を改善する。
クライアント１８側では、ホストコンピュータにおいて、本発明のオペレーションは、ホストコンピュータのオペレーテングシステムにより大いに変化させることができる。本発明のオペレーションを開示するために、クライアント１８側では、ＵＮＩＸホストシステム上の実行は、図８に示すように概略が示されている。本発明は、クライアントドライバ200を用いることでサーバー２０側のポート４０にアクセスでき、このクライアントドライバは、ローカルに接続された１組のシリアルポート204に対して１つのドライバを対応させることによってホストオペレーテングシステムのＡＰＩを実行する。これを行うために、クライアントドライバ200は、各リモートサーバーボート204に対して入力用または受信用バッファ206、出力用または伝送用バッファ208、及びリモートサーバー２０の状態に関する情報並びに状態メモリ210に格納されるホストコンピュータへのインタフェースに対してサポートする。
また、このドライバ200は、汎用ネットワークに接続される標準ネットワークインタフェース212に対しても接続できる。クライアントドライバ200からサーバー２０への全ての通信は、ネットワーク10上で伝送される。ネットワークインタフェース212は、通信プロトコルの下でドライバ200が接続される多数のポート４０に関わらず、各サーバー２０のためのネットワーク上の１つポートだけに接続が可能である。
このシステムが放逐されたとき、このオペレーテングシステムの立ち上げ処理はドライバ200を始動させる。そして、各サーバー２０のために、STREAMS接続部218をサーバー２０に接続するユーザモードのデーモン214を始動させる。このデーモン214は、STREAMS接続部218をドライバ200と連動する制御装置202に接続する。
次に、デーモン214は、STREAMSインタフェースを用いて、ドライバ200がネットワーク接続上のデータをデーモン214からの相互作用でサーバー２０のＷ／Ｏに直接に送受信できるように、制御装置202より下位のオペレーテングシステムリンクのストリーム218を要求する。そうすることにより、ドライバ200は、制御装置のSTREAMSの待機サービスルーチンにおいて、サーバー２０からのＴＣＰ／ＩＰのデータを送受信することができる。これは、従来技術で得られたタスク切換用オーバーヘッドオペレーションを削除する。
接続モードは、バイトフロー接続であり、ドライバ200がサーバー２０へ信頼性のあるシーケンスデータの送受信を行えるようにする。ドライバ200は、この接続の信頼性に完全に頼っており、失われたパケット及び同等物を回復させる機能は備えていない。このドライバ200は、サーバー２０から受信下データ内のエラーまでも保護するとすると、ドライバ200はデーモン214までのハングアップ信号を通過させ、その時、サーバー２８への接続を閉じたりまた再び開くようにする。このようなエラーは通常のオペレーション中に起こすことはできない。このエラーは、リモートサーバーソフトウエア、ネットワークソフトウエア、ドライバソフトウエア等の失敗、あるいは、ある種のコンピュータの失敗によってのみ起こる。ホストコンピュータ内の標準ＴＣＰ／ＩＰソフトウエアは、汎用コンピュータネットワーク上で通常起こるような失なわれたまたは歪曲したパケットニよるこの種のエラーが起こらないように有効に保証している。
一旦、ドライバ200がネットワーク接続にアクセスすると、ドライバは、サーバー２０にサーバー２０上の多数のシリアルポート４０及びサーバー２０の他のハードウエア及びソフトウエアの両特性に関する情報を戻すように要求する。
ユーザーモードタスク216は、ＴＴＹシリアルタスク204を接続しようとするとき、ホストオペレーテングシステム215は、ドライバ200にオープンコールする。このポート204は他のユーザモードタスク216によってすでに接続されていない場合、ドライバは、サーバー２０へのオープン要求を送り、ドライバ200のＴＴＹポート204に連動するサーバー２０上のポート４０への独占的アクセスを得る。ポート４０が利用可能である場合、サーバー２０は、クライアント１８がポート４０を閉じるまで、あるいはクライアント１８の接続が失われるまで、独占的なアクセスを許すように応答する。
ポート４０が利用できない場合、ユーザモードタスク216によって作られたオリジナルのオープン要求のタイプに従ってアクションが取られる。ユーザモードタスク216は、要求が直ちに行うことができない場合にオープン失敗であるという要求を行うことができ、あるいはポート４０が利用可能となるまで、要求を待機させるという要求を行うことができる。前者の場合、ドライバ200は、サーバー２０に迅速なオープンを要求し、このサーバー２０は、ポート４０が混んでいる場合にその要求を拒絶し、その時、ドライバ200は、ユーザモードタスク216にエラーを戻す。後者の場合、ドライバ200は、サーバー２０にオープン待機中であることを知らせ、ポート４０が最終的に利用可能となるまでクライアントが待機の順番を待つようにするかを尋ねる。その時、サーバー２０は要求が順番待ちであるという指示を伝え、ドライバー200は、ポート４０が利用可能であることをサーバー２０がドライバ200に知らせるまで、ユーザモードタスク216を休止状態に置く。
ドライバ200は、サーバーポート４０がうまく開かれると、サーバー２０へ照会パケットを送り、ボーレート発生器の周波数値及びポート４０マーク及びスペースパリティーをサポートできるかどうかを含む、ポート４０のハードウエア及びソフトウエアの特性を学習する。
また、ドライバ200が、サーバー２０にポート204のための受信用バッファ206のサイズを送ることから、サーバー２０は、更なる規定なしでクライアント１８により送られるデータがどれ位かを知ることになる。
サーバー２０は、照会に応じて、またポート４０の伝送用及び受信用バッファ４２，４４のサイズを含む、ポート４０の特性を送る。
ドライバ200がサーバー２０からの返答を受け取った時、ドライバ200は、ポート４０に送受信用データを送る準備をし、かつホストオペレーテングシステムのオープン／クロース／ｉｏｃｔｌ（入力／出力制御）インタフェースによって所望の要求を行う時、ユーザモードタスク216のために制御及び状態の照会をする。
その後、サーバー２０のポート４０上に受信した全てのデータは、自動的にクライアント１８に送られ、そこで、データは受信用バッファ206に格納される。サーバー２０は、受信用バッファ206に適合できるだけの入力ポートデータを最初に送るように定められており、それ以上のバッファのオーバーランの可能性はない。
ユーザモードタスク216がデータの読取りを要求すると、ホストオペレーテングシステムは、ドライバ200の読取ルーチンを呼び出す。読取り要求のパラメータに従って十分なデータがサーバー２０から受信された時、ドライバ200はホストオペレーテングシステム215にそのデータを戻し、順次データをユーザモードタスク216へ通過させる。十分なデータが利用できない場合、ドライバ200は、データが到着するまで、あるいはホストオペレーテングシステム215のＡＰＩに従って中断されるまで、ユーザモードタスク216を休止状態に置く。
ドライバ200が受信用バッファ206からデータを転送したとき、ドライバ200は、このデータがシーケンスナンバーＲＷＩＮを転送させたバイト数だけインクリメントすることによって転送されたことをサーバー２０に知らせる。サーバー２０は、その時、そのデータがシーケンスナンバーＲＷＩＮに達した後に付加的なデータを送ることができる。
ユーザモードタスク216がデータを書き込むために要求されるとき、ホストオペレーテングシステム215は、ドライバ200の書込みルーチンを呼び出す。ドライバ200がそれをコピーする場合、伝送用バッファ208に適合するだけの量のユーザデータをコピーする。全てのデータが伝送用バッファ208に置かれたならば、サーバー２０は要求を実行し、ユーザモードタスク216を続行することができる。もし、伝送用バッファ208に適合する全てのデータがない場合、ドライバ200はデータがサーバー２０に送られるまでユーザモードタスク216を休止状態にする。そして、伝送用バッファ208内の空きスペースが十分となって、残りのデータがバッファ208内に格納できるようになる。
ユーザモードタスク216が、ｉｏｃｔｌ要求として知られている制限または照会要求をするとき、ホストオペレーテングシステム215は、ドライバ200内のｉｏｃｔｌルーチンを呼び出す。この要求が、ポート204のハードウエア及びソフトウエアの両特性を変える場合、ドライバ200は、状態メモリ210における変化を示す。そして、サーバー２０に必要な変更をさせるために命令を送る。この要求が、ドライバ200がサーバー２０に問い合わせることなく応答できる照会要求である場合、ドライバ200はこれを行う。この要求が、サーバー２０内のデータを必要とする場合、ドライバ200は、この情報のためにサーバー２０に照会要求を送り、そして、ユーザモードタスク216の要求を満足させるために戻された情報を用いる。
ユーザモードタスク216によって作ることができるこの種の要求は、非常に多様であり、その動作も広く変化する。ある場合、この要求は、直ちに満足できるが、また、ある場合には、この要求が完了するまでユーザモードタスク216が休止状態に置かれる。
ユーザモードタスク216がＴＴＹポート204に最後のクローズをするとき、ホストオペレーテングシステムは、ドライバ200のクローズルーチンを呼び出す。これにより、ドライバ200は、ユーザモードタスク216を休止状態にさせ、伝送用バッファ208内の全てのデータが伝送されるまで待機させ、また、サーバー２０に継続中の要求が完了するまで待機させる。
ドライバ200は、その時、サーバー２０にクローズ要求を送る。このクローズ要求が受け入れられると、サーバー２０は、ポート４０を割り当てそしてのクライアント１８にそのポートの再割り当てを可能にする。ドライバ200は、クローズを完了し、そしてユーザモードタスク216を続行する。
ドライバ200のオペレーションの効率を最適化し、かつホストオペレーションシステム215上の負荷を最小化するために、ドライバ200はサーバーとの通信を約５０回／秒の周期間隔で行う。この各間隔で、ドライバ200は、そのサーバー２０に接続されている各活動ポート204を調べ、このようなポート204，４０のすべてに対して要求及びデータを共通のメッセージとして与え、さらにこのメッセージを１つのオペレーションとしてサーバー２０に送る。この動作は、サーバー２０に送らなければならないＴＰＣ／ＩＰメッセージの総数、あるい他の汎用ネットワークメッセージを最小化し、またシステムのオペレーションを高める。
本発明は、ネットワーク１０間のシリアルポートハードウエアをシミュレートさせるために用いられるプロトコルを提供することである。このように使用するとき、ボードあるいは他のハードウエアは、ホストコンピュータに設置され、ローカルシリアルポートボードに類似するホストコンピュータへのシリアルポートインタフェースを備えている。
本実施例では、ボードは、汎用ネットワークのプロトコルスタックを含み、さらに、シリアルポートインタフェースを備え、またクライアントドライバ200と接続した上記機能を備えるソフトウエアを付加する。このボードを用いて、複数のドライバは、シリアルポートインタフェースだけが知られかつネットワーク１０の存在が知られていない、ホストオペレーテングシステム上で使用することができる。
このようなハードウエアのインプリメンテーション（実装）は、いくつかの利点がある。第１に、ハードウエア用またはソフトウエア用のインタフェースをエミュレートさせて使用することができ、このため各ドライバは、ホストオペレーテングシステム上で利用可能または容易に採用することができる。第２に、このインターフェースボード（またはカード）は、コンピュータに設置することができ、そこでたやすく利用できないハードウエアまたはソフトウエアをネットワークさせ、これにより、ホストコンピュータにネットワークサービスを提供できる。第３に、このインターフェースカードは、カード上にオーバーヘッドされる多くのシリアルポートをオフロードする付加的なプロセッサ及びハードウエアを含ませることができる。最後に、このようなカードは、本来、多機能であり、例えば、ローカルコンピュータのためにリザーブされ、あるいはアクセス可能なネットワークとなることができる小さな物理的装置を含んでいる。
サーバー２０とクライアント１８の間で交換可能なデータ及びコマンドを含む全ての情報は、パケットと呼ばれる小さな単位でネットワークプロトコルによって与えられるバイトフローよって送られる。これらのパケットのフォーマットは、本発明の通信プロトコルを作り上げる。この通信プロトコルパケットは、フォーマットにおいてＣＲＴターミナルのエスケープシーケンスと類似しており、その中で、シーケンスのわずかな第１バイト数が次に続くデータのフォーマット及び長さを決定する。
サーバー２０からクライアント１８への通信用パケットの形成は、サーバー２０のＣＰＵ３２において行われる。クライアント１８からサーバー２０に送られるパケットは、クライアント１８側で動作する特定ドライバによって作り出される。このパケットは、それ自体、パレットに含まれる情報の種類による可変フォーマット及び可変長さを有している。各パケットのフォーマットは、パケットを順次アクセスする処理によって決定される。より前のバイトの値が次に続くバイトのフォーマット及び内容をすべて決定する。
表９は、サーバー２０とクライアント１８との間で伝送される各パケットの異なる形式を示す。この表は、１つのパケットを主たる特殊形に分解された第１バイトがどのようになるかを示している。禁止(illegal)を示す各値は、本発明の好ましい実施例としては用いられない。
データパケットは、クライアント１８とサーバー２０との間のインバンドーデータのすべてを伝送するのに使用される。サーバー２０によって受信されると、このデータパケットのデータは、上記のように適当なポート４０を介して伝送される。
ウインドウ・シーケンスパケットは、受け手に送り手のシーケンスナンバーの状態について知らせる。この情報の伝送は、上記で概略説明したように、本発明のデータフロー制御の働きに関して重要である。ウインドウ・シーケンスパケットは、クライアント１８にＴＯＵＴを送るためにサーバー２０によって用いられ、そして、サーバー２０にＲＷＩＮを送るためにクライアント１８によって用いられる。
コマンドパケットも、１バイトにおけるコマンド型フィールドの値により、異なるフォーマットと異なる長さを有している。各コマンドは、サーバー２０の状態変数３８の各値について設定しかつ照会するために伝送される。さらに、コマンドパケットは、ポートを開くために利用され、クライアント１８がサーバー２０と同期が取れるように、またサーバーの送受信用バッファ４２，４４のサイズを確かめるために、特定ポート４０の容量を確かめるために、サーバー２０のバッファ４２，４４をフラッシュするために、ブレーク又は中間のキャラクタを伝送するために、また、入力または出力を休止あるいは再始動させるために利用される。このコマンドパケットは、表１０において設定されている。
２つの最も重要なコマンドパケットは、開いているポート４０と接続する場合のクライアント１８とサーバー２０との間の通信を包含している。ポート４０を開くための要求コマンドは、サーバー２０上のポート４０に独占的にアクセスすることを望むクライアント１８によって送られる。サーバー２０が、このオープン要求コマンドを受け取ると、サーバー２０は、クライアント１８のためにポート４０を開くように試み、そして、クライアント１８にオープン要求の結果を知らせるオープン応答パケットによって返答する。
オープン要求コマンドパケット及びオープン応答コマンドパケットのフォーマットは、表１１，１２に設定されている。
ポート４０を開くためのコマンドパケットは、要求するクライアント１８によって望むオープンコマンドの形式に従って異なる形式を取ることができる。オープンコマンドの可能な形式は、即時オープン、持続オープン、入来オープンがある。即時オープンのための要求は、ポート４０が有効であって直ちに利用可能である場合にのみ、受け入れられ、そして、ポート４０が要求するクライアント１８に割り与えられる。ポート４０か直ちに利用可能でない場合、要求は拒絶される。持続オープン要求がなされると、この要求は、ポート４０が利用可能であるならは、受け入れられ、そしてポート４０はクライアント１８に割り与えられる。もし、ポート４０が混んでいる場合、サーバー２０は、クライアント１８へのオープン応答パケットに戻り、クライアントにポート４０が混んでいることを示し、そして、クライアント１８をそのポート４０に対する待機リスト上に置く。ポート４０が順次利用可能になると、ポート４０は開かれ、そして、クライアント１８は、第２のオープン応答が受け入れ可能であることを知ることができる。
オープン要求の第３形式は、入来オープンとして要求である。この要求は、ポート４０が利用可能であるならば、直ちに受け入れられ、そして、キャリアがポート４０上に現れる。ポート４０が混んでいる場合、またはキャリアが現れない場合、サーバー２０は、対応するオープン応答コードに戻り、そして、クライアント１８をそのポート４０のための待機リスト上に置く。ポート４０が続いてキャリアの出現とともに利用可能になると、ポート４０は開かれ、クライアント１８は、第２のオープン応答が受け入れ可能であることを知ることができる。
クライアント１８は、特定ポート４０に対するオープン要求のキャンセル待機形式を送ることもできる。このコマンドをクライアント１８から受け取ったとき、サーバー２０は、クライアント１８がそのポート４０の待機リスト上にあるかどうかをチェックできる。
クライアント１８がそのリスト上にあることがわかると、クライアント１８は、取り除かれ、サーバー２０はオープン応答が受け入れ可能である指示に戻す。サーバー２０上のポート４０を追跡用ポートに組織化することが可能である。
このようにすると、サーバー２０は、追跡用ポートとして指定した１つ又はそれ以上の論理ポートを用意し、その結果、追跡用ポート群の１つをオープンにするための試行によって、追跡用ポート群の１つとして形成される物理的ポート４０を開く。こうして、クライアント１８が追跡用ポート群の一部であるポート４０を要求する場合、開かれた実際のポート４０は、要求されたポート４０とは異なることになる。クライアント１８は、オープンが受け入れられたのち、オープン応答のＰＮＵＭを調べなければならない。そして、そのポートの番号がポート４０に当たるか順次参照する。
同期要求コマンドは、その受け手が同期応答コマンドに応答するようにさせる。これは、その他のことに関しては何の効果もない。このコマンドの第１の目的は、クライアント１８がサーバーと同期できるように保証することである。例えば、クライアント１８は、呼び出しプログラムに戻る前に、要求したボーレート変更を一致させることを望む。クライアント１８は、第１にボーレート変更をサーバー２０に伝送することによりこれを達成する。そして、それに続いて同期要求を行う。サーバー２０は順次コマンドを処理するので、クライアント１８が同期応答のマッチングを受けると、クライアント１８はボーレート変更が完了したことがわかる。
シーケンス要求と応答パケットが与えられて、クライアント１８はサーバー２０へ入出力するデータの流れを正確に追跡することができる。サーバー２０は、クライアント１８にＲＩＮ及びＴＯＵＴを与えることによりこのパケットに応答する。
クライアント１８は、状態要求パケットを送り、サーバー２０におけるＥＳＴＡＴとＭＳＴＡＲＴの現在の常識を識別する。サーバー２０は、状態応答パケットにおける要求データを戻し、そして他の動作は取らない。このコマンドは、クライアント１８がサーバー２０の状態を学習する２つの方法のうちの１つである。クライアント１８は、選択された状態変化をサーバーによって自動的に報告させるために、選択イベント条件パケットを用いることができる。
クライアント１８は、ラインエラーカウンタを選ぶために、このラインエラーカウンタの周期的報告を形成し、そして、カウンタをクリアにするためにラインエラー要求パケットを送る。サーバー２０は、エラーカウンタの選別に応答してラインエラー応答を送り、そして、これは、変数ＬＴＩＭＥとして形成される周期的間隔で送られる。ラインエラー要求パケットは、すべてサーバーの変数ＬＴＩＭＥとして設定される。ＬＴＩＭＥの値が０では、自動的に報告を行わない。ＬＴＩＭＥの値がＦＦＦＦでは、ＬＴＩＭＥは変化しない。
クライアント１８がＬＴＩＭＥを０でない値に設定した後、サーバー２０は、ＬＴＩＭＥミリセコンド毎に（ほぼ２０ミリセコンドの正確さで）各エラーカウンタの状態を調べる。そして、その状態が最後の報告まで変わらないならば、自動ラインエラー応答パケットを送る。
バッファ要求パケットは、クライアント１８によって送られ、サーバーの伝送用バッファ４２及び受信用バッファ４４のサイズを学習する。サーバー２０は、バッファ応答パケットに応答する。ポートがうまく開いた後、そしてサーバー２０にデータを送る前、クライアント１８は、サーバーのバッファ４２，４４のサイズを確認する必要がある。伝送用バッファ４２のサイズは、クライアント１８が伝送できるデータがどの位かを知るために必要である。受信用バッファ４４のサイズは、サーバー２０がフロー制御の流れ容量の高低を設定するのに必要である。
ポートの能力要求パケットは、ポート４０のハードウエア及びソフトウエアの各能力を学習するためにクライアント１８によって送られる。他のポートのコマンドはそのレベルが違っており、このコマンドが発生しても、ポート４０は開くことはできない。
設定ボーレートコマンドは、クライアント１８がポートのボーレート、すなわち、ポート４０のＣＦＬＡＧＳ，ＩＦＬＡＧＳ，ＯＦＬＡＧＳ，ＸＦＬＡＧＳを設定するのに使用する。
クライアント１８は、選択イベント条件コマンドを送り、どのＥＳＴＡＴ，ＭＳＴＡＴの条件がサーバー２０に１つのイベントパケットを送らせることができるかを特定する。このクライアント１８は、また、状態要求パケットを用いてＥＳＴＡＲＴ及びＭＳＴＡＲＴを調査することができる。
設定ウインドウトリガーコマンドにより、クライアント１８はサーバーの状態変数３８の１つであるＴＲＥＱを設定することができる。ＴＲＥＱは、ウインドウシーケンスパケットが送られる時点で、クライアント１８が要求したレベルである。ＴＲＥＱが出力バッファにおける現在のデータ範囲から外れている場合、サーバー２０は直ちに１つのウインドウシーケンスパケットに応答する。
設定モデム出力及びフロー制御パケットは、クライアント１８がモデム出力を設定し、そして、モデム信号ハードウエア用のフロー制御を選択するするために送られる。ＲＴＳとＤＴＲのモデムフロー制御が選択されたとき、ＭＯＵＴにおけるＲＴＳとＤＴＲの値は無視される。
クライアント１８は、設定受信用の（高／低）ウオーター指示パケットを送り、受信用の（高／低）フオーター指示のフロー制御を設定する。このパケットはサーバー２０によって処理されると、直ちに影響を与える。入力バッファにおけるキャラクタの数がＲＨＩＧＨを越えると、フロー制御は、直ちに実施が強制される。入力バッファがＲＬＯＷより小さいと、フロー制御は、直ちに緩やかに実施される。
クライアント１８は、設定フロー制御キャラクタパケットを送り、サーバー２０にソフトウエアフロー制御キャラクタを設定する。同様に、クライアント１８は、設定ＲＭＡＸとＲＴＩＭＥコマンドを送り、各パラメータＲＭＡＸ，ＲＴＩＭＥを設定し、さらに設定ＴＭＡＸとＲＴＩＭＥコマンドを、ＴＭＡＸとＴＴＩＭＥに設定する。
クライアント１８は、インバンドーデータの頭文字を送るために、伝送用キャラクタ即時パケットを送る。伝送用即時データにおいて、ソフトウエアフロー制御は、無視され、ハードウエアフロー制御は、ＭＦＬＯＷの代わりに変数ＭＣＴＲＬに用いられる。クライアント１８は、ハードウエアブレーク信号を送るために伝送用ブレーク即時パケットを利用する。このブレーク信号は、また、すべてのインバンドーデータの前に送られ、そして、ソフトウエアまたはハードウエアのフロー制御に関わらず送られる。
クライアント１８は、サーバーの入力及び出力バッファの両方またはいずれか一方をフラッシュするためにフラッシュバッファパケットを送る。休止（入力／出力）パケットは、サーバーにおけるソフトウエアフロー制御条件の幾組かを休止する。受信用バッファ内のキャラクタの数がＲＬＯＷより少ない場合、入力を休止するための試みは無駄になる。最後に、反休止（入力／出力）パケットは、サーバーにおけるソフトウエアフロー制御条件の幾組かを休止させない。受信用バッファ内のキャラクタの数がＲＨＩＧＨより多い場合、入力を休止させないための試みは無駄になる。
イベントパケットがサーバー２０によって送られて、ＥＳＴＡＴとＭＳＴＡＴの状況の変化をクライアント１８に知らせる。サーバー２０は、（ＥＴＲＡＮ及びＥＩＮＴ)あるいは（ＭＴＲＡＮ及びＭＩＮＴ）が非ゼロであるときはいつでも、各ポート４０にイベントパケットを送る。
この要求を確実にすることがイベントパケットに、別な方法で報告され、失われるようなトランジッションを引き起こさない。すなわち、サーバー２０は、最初にＥＬＡＳＴを設定し、続けてＭＬＡＳＴを設定する。それから、ＥＬＡＳＴ及びＭＬＡＳＴをクライアント１８に報告する。
モジュール選択は、ポート４０の特定グループを選択するために使用される。通信の帯域幅を減少するために、ポート４０は１６のポート４０（ポート０−１５）のみを含む各モジュールと共に、論理モジュールにグループ化される。論理モジュール群とサーバ（６）上のポート４０の物理的配置の間には、関係がない。ポート４０をモジュールに一括することによって、すべてのコマンド及び応答リファレンスにおけるアドレッシングは、ポート（０−１５）が、このモジュール内で望まれることに関連していることのみが重要である。モジュール０は不履行の際、選択される。
モジュール０−７は、１バイトモジュール選択パケットと共に選択可能である。モジュール８−２５５は、２バイトのパケットを要求する。モジュールとポートペアと物理的ポートナンバーとの間で、転換することが可能である。モジュールｎが選択されるとき、すべてのそれに続くパケットのポートＫは、物理的ポート１６＊ｎ＋Ｋに関連する。
ＩＤ要求パケットは、リモート側からの機器構成の情報あるいは一致を得るため、クライアント１８あるいはサーバー２０のどちらかに送られる。リモート側はＩＤ応答パケットに応じる。
デバッキングパケット型は、クライアント１８とサーバー２０との間で、デバッキングデータを伝送するような、デバッグをする目的でサーバー２０のポート４０にアクセスすることをサポートする。これらのパケットはクライアント１８がサーバープログラムメモリ３６にアクセスすることも可能にし、プログラムメモリ３６に記憶されているようなサーバ２０のプログラムを代えること、あるいはプログラムメモリ３６の内容をレビューすることを許容する。
リセットパケット型は、接続が停止される前に、クライアント１８あるいはサーバー２０によって、リモート側にプロトコルエラーを報告するために送られる。パケットはＡＳＣＩＩフォーマットのリセットのための理由の説明を含む。リセットパケットは、対話で送られた直前のパケットでなければならない。
この議論は、ＵＮＩＸ以外の他のオペレーテングシステムについて特になされていないが、ノーベル、ウインドウズ、ウインドウズＮＴ、ＯＳ／２及びＤＯＳのアプリケーションプログラミングインタフェースを満足させるために要求されるＸＦＬＡＧＳ、エラーカウンタやイベントフラグで実証される特徴は、当業者に明らかである。結果として、これらオペレーテングシステムのいずれでも、本発明のインプリメンテーションは、当業者に明らかである。
本発明はそのすべての詳細に制限されることはなく、本発明の精神あるいは範囲内でなされる変形や修正されたものにも制限されない。
【図面の簡単な説明】
図１は、種々のホストコンピュータと本発明のサーバーを、汎用コンピュータにネットワーク接続することを示す。
図２は、汎用ネットワーク上のクライアントのコンピュータに、サーバーの主要構成要素を含む、本発明のサーバーを取り付けたことを示す。
図３は、シーケンス空間内の位置に向けて指定する単一のシーケンスナンバーを有するラップアラウンド・シーケンス空間を示す。
図４は、シーケンス空間内の位置に向けて指定する２つのシーケンスナンバーを有するラップアラウンド・シーケンス空間を示す。
図５は、サーバーが、クライアントからサーバーを通じてポートへ伝送されるデータの流れを、制御する過程を示す。
図６は、クライアントからサーバーを通じてポートへ伝送されるデータの流れを、クライアントが制御する過程を示す。
図７は、サーバーが、ポートからサーバーを通じてクライアントへ伝送されるデータの流れを、制御する過程を示す。
図８は、汎用ネットワーク上のクライアントのコンピュータに、クライアントのドライバーの主要構成要素を含む、本発明のサーバーを取り付けたことを示す。
この発明は、汎用ネットワークを通じての、コンピュータとコンピュータ周辺装置のようなディジタル装置間の通信分野に関する。
（背景技術）
互いに遠く離れたディジタルコンピュータとコンピュータ周辺装置間で通信を行うことの必要性が、長い間感じられていた。多くの技術がこの必要性のために設計されてきた。アナログ電話網上での長距離接続を確立するためのモデムの使用や、データ伝送媒体上でコンピュータと周辺装置との通信を行わせるネットワーキングを作ることによって行われた。
モデムは、二つのコンピュータ間での通信を確立させるために一対で用いられ、各モデムはアナログ電話網に接続されるばかりでなく、そのローカルコンピュータのシリアルポートに取り付けられている。シリアルポートはコンピュータに、モデムあるいはプリンタのような周辺装置へ連続的なビットの流れを通過させるようにする。コンピュータや他のマルチユーザコンピュータシステムに基づくＵＮＩＸ上で、この同じシリアルポートは、ユーザにコンピュータとの通信を許容するターミナルとの通信のために用いられる。結果として、単純なことであるが、遠隔地のターミナルが電話線上でマルチユーザコンピュータシステムと通信できるモデムを使用しているということになる。
最新のマルチユーザコンピュータは、同時に多数のユーザをサポートすることができるので、ターミナルがコンピュータと通信できる多くのシリアルポートを有することが望ましい。
あいにくにも、マルチユーザが、しばしば５０以上のターミナル接続をサポートしているので、シリアルポートのすべてを、直接コンピュータ上に取り付けることは論理的に困難である。結果として、マルチプレクサは、多数の内部的に基準となるシリアルポートからの連続トラフィックを単一の通信チャンネルに結合するために用いられていた。このように、ただ一つの通信ケーブルが、コンピュータに接続されることが必要である。
通信ケーブルの他端には、他の多重化装置があり、その装置が、結合されたデータトラフィックを個々のシリアルポートのためのデータに分離してそのシリアルポートに送り、それによってこのデータをアクセスできる。ポートコンセントレータと呼ばれるこのタイプの多重化装置は、コンピュータからリモート側のターミナルへ多数のシリアルポートを供給するために用いられる。主な通信ケーブル上のデータが、モデムを用いる電話線上で伝送されるようなシステム内での多重化を使用することさえ可能である。これは、コンピュータから非常に離れた所でも、多数のマルチプルシリアルポートへのアクセスを可能にする。
ネットワーク技術は、また、あるコンピュータと他のコンピュータあるいは周辺装置間での遠隔通信を可能にするために使用される。比較的、小エリア内でのコンピュータと周辺装置を接続するネットワークは、ローカルエリアネットワークあるいはＬＡＮと呼ばれている。汎用ネットワークは、標準ハードウエアや標準通信プロトコルを用い、マルチベンダの環境で操作される通信システムである。汎用ネットワークのハードウエアは、イーサネット(Ethernet)やトークンリング(Token Ring)のようなＬＡＮの技術を含む。標準ネットワークプロトコルは、ＴＣＰ／ＩＰやＳＰＸ／ＩＰＸを含む。
ＬＡＮは、一般的に伝送媒体によってコンピュータや周辺装置を接続することによって形成され、標準化された通信プロトコルに従って、伝送媒体上で通信が行われる。これらのプロトコルは、データがどのようにフォーマットされるべきか、またデータが特定の装置のためにどのように名付けられるべきかについて、必要条件を明らかにしている。データは、これらのプロトコルに適合しないとネットワーク上に送られない。
ホストオペレーテングシステム上のアプリケーションプログラムは、概して、ホストオペレーテングシステムに従うローカル通信装置のための、応用プログラムインタフェース（ＡＰＩ）に強く依存する。これは、ＵＮＩＸの従来のユーザインタフェースがターミナルコマンドライン操作であるので、ＵＮＩＸのようなシステム上で重要である。
汎用ネットワークは、コネクションレス アンリライアブル データグラム サービス(connectionless unreliable datagram service)や、信頼性双方向バイトストリーム接続の、二つの通信タイプをサポートしている。これら両サービスのＡＰＩは、シリアルポートのＡＰＩとは非常に異なっており、概して（ＴＴＹｓのように知られた）シリアル装置上で実行されるように書かれたプログラムは、正しく実行されるように適合層を必要とする。
ＵＮＩＸの環境で、これは疑似ーｔｔｙあるいはＰＴＴＹ装置として知られる仮想ＴＴＹ装置を用いるネットワークプロトコルであるテルネット(Telnet)やＲログイン(Rlogin)と共に、一般的になされる。ＰＴＴＹ装置は、実質、ソフトウエアであり、ハードウエアではなく、最大コマンドラインプログラムは、それらを充分に実行するようにＵＮＩＸ ＴＴＹｓをエミュレート（模擬）する。
これらＰＴＴＹｓと、実際のシリアルポートハードウエアを制御し、関連する真のＴＴＹｓと区別することは重要である。ＰＴＴＹは、スレーブ部とマスター部を有する。ＰＴＴＹのスレーブ部はＴＴＹエミュレーション装置であり、シリアルポートＡＰＩを機能させるようにプログラムによって使用される。マスター部は、ネットワークにデータを送ることができるテルネットやＲログインのようなネットワークプログラムとやりとりする。
ＰＴＴＹのスレーブ部は、ライン編集用キャラクタ、タブ拡張、及びローカルオペレーテングシステムのライン規則によってなされる他の機能のようなユーザオプションを変更することを要求する。しかしながら、それはボーレート、キャラクタサイズ、受け取ったエラー、ＢＲＥＡＫ信号等を変更することは無視する。
ＰＴＴＹのマスター部は、読み込み、書き込み、及びデータがスレーブとマスターの装置間で前後に通過する方法を変えるための非常に限定された入出力制御のセット（ｉｏｃｔｌｓ）を受け入れる。ＰＴＴＹのマスター部に書かれたデータは、あたかもシリアルポートに受け取ったかのように、ＰＴＴＹのスレーブ部に、受け取られたシリアルデータとして現れる。また、オペレーテングシステムのライン規則によって入力シリアルデータとして処理される。そのときデータは、ＰＴＴＹのスレーブ部から読み込まれるとき、受け取られたデータとして現れる。ＰＴＴＹのスレーブ部に書き込まれたデータは、ＵＮＩＸのライン規則によって連続出力データとして処理され、その後、マスター部に読み込まれる。
ＰＴＴＹのスレーブ部で行われたｉｏｃｔｌ操作は、マスター部では見ることができない。よってＰＴＴＹのマスター部をアクセスするプログラムでは、これらのコールがなされたことを検出することはできない。インタフェースは、ローカルオペレーテングシステムのライン規則では実行できないいくつかの操作をサポートするに充分でない。
多くのインプリメンテーション（実装）において、物理的装置とＰＴＴＹｓとの間に、１対１の対応はない。接続がテルネットあるいはＲログインによってＵＮＩＸシステムになされるとき、これらのプログラムは単にセッションのために次の利用できるＰＴＴＹを割り当てる。よってセッションからセッションへネットワークユーザは、異なったＰＴＴＹ装置を、明らかなパターンでなく、もっともらしく得られる。
これは、疑似ｔｔｙ装置に基づくシステムの安全化あるいはユーザオプションを実行することを困難に、あるいは不可能にする。ある程度までこれを克服するために、特別なプログラムが、特別のＰＴＴＹのマスター部に所属するようなターミナルサーバーベンダによって、普通書かれる。そのＰＴＴＹのスレーブ部は、そのプログラムに所属されたままであり、他の使用に周期的に再割り当てされない。そのようなプログラムは、接続を受け入れ、ログインプログラムを実行するために用いられるが、しかし、しばしばダイアルアウトモデム、プリンタ、あるいは直結型シリアル装置に用いられる。この使用は、テルネットやＲログインより他の使用にＰＴＴＹを拡張する。しかし、真のＴＴＹ装置の制限されたエミュレーションのために、それらは変化したワークアラウンドを要求し、継続的なメインテナンスや両立性の問題を生じる。
テルネットは、また、ポートデータフローコントロールのためにＴＣＰ／ＩＰを使用し、データストリームの先頭データが処理されるまでコマンドが処理されないようにデータと連続してコマンドを送る。結果として、テルネットは、ユーザが割り込みを要求したような、あるコマンドを送るためにＴＣＰ／ＩＰの促進データ特性の使用を要求する。このインプリメンテーションは、中断が処理される前に、ユーザが中断した先頭データを捨てることを要求する。
あいにく、この実行はホストコンピュータばかりでなく、ネットワークそれ自体に非常に大きな負担を生じる。例えば、ネットワークに接続されたリモートターミナルでタイピング(typing)がなされると、個々のキーストローク(keystroke)が行われ、ネットワーク上のホストコンピュータに送られる。それから、ネットワーク上のリモートターミナルにエコーバック(echoed back)される。イーサネット ネットワーク上で、送信されたキャラクタが最少メッセージパケット６４バイトで送信されなければならない。又、アクノリッジ（承認）は６４バイトメッセージパケットである。そのように、二つの６４バイトパケットは、タイプされた各キャラクタに対して送信されなければならない。
さらに、ホストコンピュータによるキャラクタの受け取りは、キャラクタを受け取るためのＰＴＴＹ制御ソフトウエアを実行するタスクスイッチを要求し、また、エコーキャラクタを送信するためにＰＴＴＹ制御ソフトウエアへのタスクスイッチバックを要求する。
ターミナルサーバーと呼ばれる装置は、ネットワークのあるコンピュータへログされることをユーザに要求せずに、シリアルポートを通じてユーザにリモートログイン、テルネット及びＲログインの使用を可能にする。ターミナルサーバー上でシリアルポートに接続されるユーザは、ネットワークのマルチユーザコンピュータに接続するために、Ｒログインあるいはテルネットを使用することができる。
ターミナルサーバーのセカンドユーザは、また同じマルチユーザのコンピュータに接続可能であり、それによってそれに割り当てられたそれ自身のＰＴＴＹと第２の通信リンクを確立できる。テルネット、Ｒログイン、及び同様な手順を通じてターミナルサーバーによってなされた接続は、ネットワークの異なるコンピュータを通じてその手順を使用してなされた接続と同じ不利益を生じる。
（発明の要約）
本発明は、汎用ネットワークのリモートターミナルサーバーに配置された非同期ポートにホストコンピュータを全アクセスさせることによって、従来技術の不利益を克服する通信システムからなる。独特の装置ドライバーインタフェースを使用することによって、また通信プロトコルを多重化することによって、サーバーは単一の接続でマルチポートのためのデータ及び制御コマンドを送信することが可能である。それによって、ネットワーク上の要求を少なくする。
さらに、本発明はローカル通信ポートのすべての特性を有するネットワーク上の真のＴＴＹ装置を提供する。本発明は、モデムやプリンタのような共用装備に正しくアクセスしながら、ネットワークに配置された多数のホストコンピュータに、サーバー上のポートにアクセスすることを可能にする。結局、本発明はハードウエアにインプリメントされ、既存のホストコンピュータソフトウエアとの両立性を増進させ、さらにホストコンピュータのオーバーヘッドを減少させる。
本発明は、リモート通信ポートやそのようなポートを合体するサーバにアクセスする、あるいはアクセスを与えることを望むクライアント（通常ホストコンピュータ）間の汎用ネットワークによって供給される信頼性のある通信リンク上で動作する。
本発明は、汎用ネットワーク上の真のＴＴＹ装置が備えられた従来のＰＴＴＹ実装とは相違する。ＰＴＴＹ実装のようではなく、本発明のＴＴＹは１対１対応である。あたかも、シリアルポートがホストオペレーテングシステムに、直接に接続され、この使用に専念しているかのように、ホストオペレーテングシステムでそのハードウエアを制御させることができる。
それは、応用プログラムによってなされる仮定とを妨げることなく、本発明はこれら限定を緩める。そして、ネットワークの他のホストと共用してその機能を広げ、ＰＢＸ型追跡グループと動的ポートの割当てを共用する。本発明は、それぞれのオペレーテングシステムに真のＴＴＹｓと１対１の対応を維持させる。しかし、ＴＴＹｓが、本発明のオペレーテングシステムに使用されていないとき、他の目的に対してアクセスできるようにすることは任意である。
サーバー上で１あるいはそれ以上のポートを使いたいクライアントは、本発明の「通信プロトコル」によって準備されたプロトコルを使用するそのサーバーへ単一の接続をオープンする。クライアントと通信プロトコルを使用するサーバーとの間のすべての通信は、いかに多くのポートがクライアントによって使用されても、この単一接続を使用して続行する。クライアントとサーバ間の付加的接続がテルネットやＲログインのような従来技術のプロトコルのもとでオープンされてよい。しかし、これら従来技術のプロトコル接続の存在は、本発明の通信プロトコルの制御下でポートに影響しない。クライアントとサーバー間の接続が何らかの理由で破壊されるとき、通信プロトコル制御下ですべてのポートは閉鎖され、そのクライアントによって要求されているすべての資源はもどされる。
通信プロトコル接続の存在は、サーバー上のすべてのポート資源に、クライアントが自動的にアクセスすることを許さない。クライアントがポートにアクセスする前に、最初にポートを幸運にもオープンするに違いない。その後、クライアントがポートをクローズするまで、クライアントはポートへ排他的アクセスを許される。
一度、ポートがオープンされると、クライアントはボーレートを変更するために、要求を出してもよい。クライアントは、ポートにデータを送出し、そしてサーバーはポートに受け取られるすべてのデータを、クライアントに自動的に送る。通信プロトコル下で、クライアントはサーバーから最新のステータスを要求できる。最新のステータスは、要求すれば直ちに得られるか、あるいはクライアントは、クライアントの種々のステータスの状況の変化を知らせるようにサーバーに要求できる。
（発明を実施するための最良の形態）
図１は、ＵＮＩＸコンピュータ１２、デジタル エクィップメント社のＶＡＸコンピュータ１４および特別な場所で用いられる新規なＰＣのネットワーク１６を含む各種コンピュータを相互接続した、ネットワーク１０の概略を示したものである。
ネットワーク１０は、エラーフリー型バイトストリームのデータ伝送用に設けられたプロトコルであれば、ＴＣＰ／ＩＰ、ＳＰＸ／ＩＰＸあるいはＸ．２５等、標準的なネットワーク通信プロトコルを用いることができる。この通信プロトコルは、イーサネット（Ethernet）やトークンリング（Token Ring）のような特定の論理位相数学上で機能する。
図１に示した各種コンピュータとネットワークを接続する典型的なネットワークは、イーサネットのトップ上で作動するＴＣＰ／ＩＰプロトコルが用いられる。プロトコルのＴＣＰの部分は、バイトストリームデータを受け入れてパケットに変換する。ＩＰの部分はこのパケットを受け入れてデータグラムを形成し、その間にイーサネットがデータグラムを受け入れてフレームを形成する。本発明は、用いられるネットワークプロトコルには影響されないが、その説明の目的で典型的な形態が用いられている。
本発明のサーバー２０は、ネットワーク１０の種々のポート（図示を省略した）に接続するように作用する。これらのポートには、サーバー２０に対して複数の通信ライン２２を接続することができる。図１においては、たった５本の通信ライン２２しか示されていないが、サーバー２０は、典型的には１６本あるいはそれ以上をネットワーク１０に接続することができる。
図２は、１つまたはそれ以上のクライアント１８と汎用ネットワークを介して接続されるサーバー２０との間の通信の主な要素を示したものである。クライアント１８は、ＵＮＩＸコンピュータ１２やＶＡＸコンピュータ１４、あるいはローカルネットワーク１６のようなホストコンピュータとすることができる。サーバー２０は、そのネットワークインタフェース３０を通じてネットワーク１０に接続される。ネットワークインタフェース３０は、ネットワーク１０上の他の装置と同様に、サーバー２０がネットワーク１０と通信するために必要とする産業用の標準ハードウエア及びソフトウエアを備えている。すべての産業において標準となるネットワークインタフェースと同様に、このネットワークインタフェース３０は、ネットワーク１０からデータフレームを受け取り、サーバー２０に宛てられたデータかどうかを判断し、もしそうならば、そのデータのネットワークフォーマットをはずしてフレーム、データグラムおよびパケットを組み立てることにより、バイトストリームに有効な形式のデータを作る。すなわち、本発明のネットワークフェース３０は、送信、ネットワーク、リンクの機能と国際標準化機構のオープンシステム相互接続（ＩＳＯ／ＯＳＩ）モデルの物理的な階層を備えている。
ネットワークインタフェース３０によるバイトストリームのデータは、本発明の通信プロトコルの装置を調整する中央処理装置（ＣＰＵ）３２に供給される。通信プロトコルの装置の調整に必要なプログラムモジュールは、サーバーメモリ３４のプログラムメモリ部３６に記憶されている。
ネットワークインタフェース３０から受け取ったデータをＣＰＵ３２が分析した後、生データはサーバー２０の適当なポート４０に通される。ポート４０は、非同期、同期あるいは並列ポートとすることができる。ポート４０に取り付けられるものは、プリンタやモデム等の各種装置とすることができる。
クライアント１８から送信されてポート４０に送られるデータは、ポート４０がデータを送信する準備をするまで、出力または送信バッファ４２に記憶される。各ポート４０を通ってサーバー２０に送られるデータは、同様にして扱われる。ポート４０から来てクライアント１８に送信されるデータは、クライアント１８にネットワーク１０が送信する準備をするまで、入力あるいはレシーブバッファ４４に記憶される。
本発明の通信プロトコルは、ＣＰＵ３２によって実行され、バイトストリームの伝送をネットワーク１０に必要とされるフレーム、データグラムおよびパケット内でフォーマットするステップは、ネットワークインタフェース３０によって処理される。
サーバメモリ３４は、通信プロトコルの装置に完全に必要な状態情報を備えたサーバーのステートバリアブル（状態変数）３８も備えている。本発明の望ましい実施例においてサーバーの状態変数３８に記憶される種類は、表１に示されている。
これらの変数形式は、多数のデータ構造で表され、サーバー２０の働きを制御すると共にクライアント１８とサーバー２０との間の通信を容易にするためのいろいろな方法で用いられる。これらの変数の目的を明らかにするため、以下にその詳細を説明する。
クライアント接続のリストは、通信プロトコルの下で開くサーバー２０への接続を一般的に行うクライアント１８のリストを保存している。好ましい形態では、サーバー２０は、８以上のクライアント接続を同時にサポートできることが望ましい。
メッセージビルドインターバルは、通信プロトコルに従って構成される、あるいはクライアント１８に伝送される情報が必要であるか否かを決定するために、サーバー２０がその状態を内部的に何回ポーリングを行うかを決めるためのポーリング間隔を制御する。好ましい形態では、このポーリングは、１秒あたりほぼ５回行われることが望ましい。その結果、ポーリングは最低でも２０ミリセコンド後には行われ、平均では１０ミリセコンド後に行われる。この間隔は、末端ユーザーに十分であり、ほとんどのスライディング式ウインドウプロトコルにも十分である。
メッセージビルトインターバルでのみ情報を伝送することにより、サーバー２０はそのインターバルの間に情報を蓄積することができる。これにより、ネットワーク１０とクライアント１８の双方の要求により制限されて、一度に１キャラクタのデータしか送れない場合よりもより大きなパケットでデータが送られる。
ポートプンステート変数は、クライアント１８が既にオープンしたポート４０に接続され、あるいはクライアント１８がポート４０のオープンを待つ、複数のトラックのデータ構造となっている。すなわち、このデータは、オープンポート４０のために、一般にクライアント１８がポート４０を保持し、クライアント１８がオープン待ちリスト上にあるトラックを構築する。ポート４０のオープンのさらなる詳細を以下に説明する。
ポート・ボーレート変数は、ポート４０のボーレートを、例えば1,843,200というように、ポートボーレート変数によって分割されて記憶する。この表現は、５０ー１１５Ｋボーの標準的なボーレートをすべて表すために１６ビットだけ必要とする。
フラグ処理変数は、キャラクタサイズ、ハードウエア状態および各ポート４０の入力／出力キャラクタ処理を制御する。サーバーの状態変数に記憶されるフラグは４つの設定がある。すなわち、ＣＦＬＡＧＳ，ＩＦＬＡＧＳ，ＯＦＬＡＧＳ，およびＸＦＬＡＧＳ，である。ＧＦＬＡＧＳ，ＩＦＬＡＧＳ，ＯＦＬＡＧＳは、ＵＮＩＸオペレーテングシステムのターミオ（termio）インタフェースによって標準的に与えられており、本発明においても産業上標準的なものとして用いられている（ＵＮＩＸプログラマーマニュアルではTermio）。
ＣＦＬＡＧＳは、キャラクタサイズ、ストップビットおよびパリティを含むポート４０のＵＡＲＴハードウエアの設定を制御する設定を有している。サーバー２０の装置に理解させる実際のＣＦＬＡＧＳは、CBAUD,CSIZE,CSTOPB,CREAD,PARENB,PARODD,およびHUPCLを含んでいる。同様に、ＩＦＬＡＧＳの設定は、サーバー２０がポート４０から受け取ったデータの処理を制御する設定を有している。
ＩＦＬＡＧＳの設定は、ブレーク条件、エラーハンドリングおよびソフトウエアフロー制御設定の解釈上の制御を含む。サーバー２０で翻訳されるＩＦＬＡＧＳは、IGNBRK,IGNPAR,PARMRK,INPCK,ISTRIP,IXON,IXOFF,IXANY,DOSMODEである。
ＯＦＬＡＧＳは、ポート４０に出力されることによりサーバー２０のデータの処理を制御する。ＯＦＬＡＧＳの設定は、ＣＲおよびＮＬの設定やタブディレイといったことを制御し、OPOST,OLCUC,ONLCR,OCRNL,ONOCR,ONLRET,OFILL,OFDEL,NLDLY,CRDLY,TABDLY,ESDLY,VTDLY,FFDLYを占めるターミオによって定められる。
好ましい形態では、現在の通信設備ではもはや使用されない各種のフラグの設定は、サポートされていない。これらのフラグの設定は、OFILL,OFDEL,NLDLY,CRDLY,BSDLY,VTDLYおよびFFDLY、ＯＦＬＡＧＳからのすべてを含む。これらの各々の設定については、好ましい形態でわずかな修正のみを記載したが、本発明がこれらの記載された設定に限定されることはない。
ＸＦＬＡＧＳは、ターミオＬＦＬＡＧＳから取ったフラグの設定で、追加機能が加えられている。このＸＦＬＡＧＳの設定は、表２に記載されている。
ＸＦＬＡＧＳ変数（ＵＮＩＸラインの分野のXCASEおよびＬＦＬＡＧＳ変数を除く）は、ＵＮＩＸ機能の設定に拡がり、複数のオペレーテングシステムにインタフェースを拡張し、価値付加機能を備えている。ＸＦＬＡＧＳの設定は、ＣＦＬＡＧＳ、ＩＦＬＡＧＳおよびＯＦＬＡＧＳの設定と相互に作用する。この相互作用の詳細は、以下の通りである。
もし、ＸＦＬＡＧＳのＸＰＡＲ設定がリセットされ、あるいは基礎をなすハードウエアがマーク／スペースをサポートしていなければ、ＣＦＬＡＧＳのPARODDの設定がされている場合に残りのパリティを選択し、リセットされている場合にパリティさえも選択する。さもなければ、PARODDが設定されている場合にスペースパリティを、リセットされている場合にマークパリティを選択する。
もし、ＩＦＬＡＧＳのPARMRKおよびＸＦＬＡＧＳのXMODEMが設定されていれば、モデム信号の１またはそれ以上の変化が入力ストリームにFF80MM（書式送り）として入力される。なお、MMは、最新化されたモデム信号値である。
もし、ＸＦＬＡＧＳのXCASEが設定されていれば、所定のアルファベット化されない印刷キャラクタがＵＮＩＸ仕様の出力に相当する２つの文字に変換する。ＸＦＬＡＧＳのXTOSSは、制御の流れの間に出力を再開するキャラクタが無視されるかどうかを制御する。ＩＦＬＡＧＳのIXANYがリセットされると、キャラクタが受け取られたXONあるいはXXONと一致したときのみ、出力が再スタートされる。しかしながら、ＩＦＬＡＧＳのIXANYが設定されているときには、どのようなキャラクタを受け取っても出力を再開する。これにより、XTOSSが設定されていれば、出力を再開するキャラクタは捨てられる。もし、XTOSSがリセットされていれば、出力を開始するいかなる流れない制御キャラクタでもデータストリームに置かれる。
ＸＦＬＡＧＳのXIXONが設定されているときは、流れ制御キャラクタの出力の特別の設定が可能となる。XXOFFの受け取りは、これをXXONが再開している間に、出力を停止する。
フロー制御キャラクタ変数は、どのようなフロー制御キャラクタとなるかが決定される。２つのフロー制御キャラクタの出力の設定がサポートされ、１つのフロー制御キャラクタの入力の設定がサポートされている。さらに、フロー制御エスケープキャラクターは、インタープリテーションなしに、フロー制御キャラクターの入力を許すことをサポートしている。
フロー制御キャラクターは、1)フロー制御始動キャラクターの標準ソフトウエア（ＸＯＮ）、2)フロー制御停止キャラクターの標準ソフトウエア（ＸＯＦＦ）、3)フロー制御始動キャラクターの特別ソフトウエア（ＸＸＯＮ）、4)フロー制御停止キャラクターの特別ソフトウエア（ＸＸＯＦＦ）、5)フロー制御エスケープキャラクター（ＬＮＥＸＴ）を含むものである。
ＬＮＥＸＴキャラクタの受取後、次に受け取られるキャラクタはフロー制御キャラクタとして認識されない。そして両キャラクタは、入力ストリーム中に置かれる。
サーバー状態変数３８に戻ると、クライアント１８へのすべてのモデム制御ファシリティの準備は、８個のモデム制御変数により行われる。これら変数の各々はモデムの操作状態を表すために、マスクを使用する。７個のモデム変数は、表３のように明らかにされる。
表３に示されるすべての変数は、表４に示されるビット割り当てを用いて、モデム信号のセットを示す。
異なったモデム制御変数の使用は、以下のとおりである。ＭＯＵＴモデム制御変数は、クライアント１８によって要求される直近のＲＴＳ及びＤＴＲの値を含む。これらの値は、サーバー２０への要求をすることによって変更される。ＭＦＬＯＷでのＲＴＳ／ＤＴＲピットがセットされるとき、ＭＯＵＴでの対応する値のセットは一時、無視され、これらの信号は、サーバー２０がデータを受け取る準備ができているかどうかを示す。受領が止まると、これらの信号はローの状態にされる。受領が再始動されると、信号はハイの状態にされる。
ＭＦＬＯＷは、「インバンド」出力データを禁止するために使用される。データ、コマンド、及びデータポート内外のデータの通常フローとして同じシーケンス内で取り扱われる応答は、インバンドデータと呼ばれる。データ、コマンド、及び通常データの先頭で伝送され、直ちに受け取られる応答は、アウトオブバンドデータと呼ばれる。ＣＴＳ／ＤＳＲ／ＤＣＤ／ＲＩのいずれかが、ＭＦＬＯＷにセットされるとき、そして、少なくとも対応するハードウエア入力信号がローであるとき、インバンド出力は禁止される。
フロー制御キャラクタ及びトランスミット イミーディエイト キャラクタ（即時伝送キャラクタ）は、フロー制御のソフトウエアあるいはＭＦＬＯＷによって、支配されない。それらは、ＭＣＴＲＬによって与えられるＣＴＳ／ＤＳＲ／ＤＣＤ／ＲＩフロー制御の束縛によって、伝送される。サーバー２０は、ＭＦＬＯＷにセットされないＭＣＴＲＬに何かのビットをリセットする。
ＭＳＴＡＴは、入出力モデム信号の現在の状態を含む。
ＭＬＳＡＴは、クライアント１８に報告されるべき直近のモデムの状態を含む。
ＭＴＲＡＮはクライアント１８に最後に報告されてから、変化があるときのモデム信号
を含む。ＭＳＴＡＴがＭＬＡＳＴに等しくなることは可能であり、ＭＴＲＡＮにセットされたビットを有している。この状態は、ＭＳＴＡＴのいくつかの信号は、少なくとも一つのトランジションを作るということを示し、また、それからクライアント１８へ示した最後の値に戻ることを示している。６個のモデム信号のいずれかがＭＩＮＴにセットされるとき、それらモデム信号の対応する変化は、クライアント１８に報告される。
本発明のサーバー２０は、ポート４０に生じる受信キャラクタエラーの数を見失わないように、サーバー状態変数３８内のポート統計カウンタ毎を維持している。これらのカウンタは、ラインエラーカウンタとして、参照される。異なったカウンタは、以下のカウントのそれぞれを追跡するために使用される：ＵＡＲＴオーバーランエラーの数、バッファオーバーフローエラーの数、フレーミングエラーの数、パリティエラーの数、及び受信されたブレーク（区切り）の数。これら変数のそれぞれは、ポート４０のカテゴリー内で起ったラインエラーの数を見失わないように、１６ビットラップアラウンドのカウンターである。
付加的なラインエラーカウンターの変数は、ミリセカンドでの報告時間を追跡する。もし、この変数がゼロならば、ラインエラーは自動的にクライアント１８に報告されない。さもなければ、サーバー２０は特定インターバルごとにカウンタを検査し、最後の報告があってから、変化があったかどうか、クライアント１８に完全な報告をする。
センドブレーク及びセンドイミーディエイト変数は、ポート４０へブレークあるいは他のキャラクタを直ちに送るかどうかを、クライアント１８に、サーバー２０へ要求することをさせる。センドイミーディエイト変数はクライアント１８が送ることを欲するキャラクタを含む、ワン キャラクタ バッファである。センドブレーク変数は、要求されたブレークのミリセカンドの長さを含む。特殊なケースは、センドブレーク変数の内容にある。ＦＦＦＦの値がセンドブレークに送られるとき、これは無限のブレーク時間を示す。００００がセンドブレークに送られると、進行中のいかなるブレークもキャンセルされる。サーバー２０に送られた他のいかなる値も、センドブレーク時間に単に加えられ、ブレークは二つの要求の結合された時間の間、実行する。
この発明は、ポートフロー制御のためにＴＣＰ／ＩＰフロー制御を使用しないので、クライアント１８あるいはサーバー２０によって受け取られたデータは、いつも直ちに実行される。結果として、インバンドデータの流れを分裂させずに、アウトオブバンドコマンドやデータを送出することは容易である。
サーバー２０は、またサーバー状態変数３８のステータス状況のリストを維持している。これらのステータス状況は、イベント報告変数内に記憶され、クライアント１８に一般的に関心のある状況を示している。クライアント１８は、これらに登録することができ、あるいはサーバー２０が、いつ状況が変化しても、適当なイベント情報を自動的に送ることを要求することができる。イベント報告変数は、サーバー２０にこのイベント情報の送出を追跡することをさせる。表５は、種々のイベント報告変数を示している。
ＥＩＮＴはサーバー２０によってクライアント１８に送られるイベント情報を生じる所定条件を創出するために、クライアント１８によって送られることができる。イベント情報は、（ＥＬＡＳＴ及びＥＩＮＴ）がゼロでない時はいつでも、クライアント１８に送られる。
ＥＳＴＡＴがＥＬＡＳＴに等しく、また、ＥＴＲＡＮ内にビットセットを有しているままである時、可能であることを記しておく。この条件はＥＳＴＡＴ内のある条件が、少なくともワン トランジッションを作り、それからそれらがクライアント１８に報告できる前に、それらのＥＲＡＳＴの値にもどることを示している。
これらの変数に記録されるイベントは、指摘されるイベントがどのようなものであるかを示すマスクに沿って、表６に示されている。表６にあげたイベントは、この発明の文脈内でよく理解される通信イベントである。
サーバー状態変数３８内に記憶された最後の二つの変数は、入力シーケンス及び受信用バッファ・パラメータ変数であり、また関連する出力出力シーケンス及び伝送用バッファ・パラメータである。これら変数は、伝送用バッファ４２及び各ポート４０と関連する受信用バッファ４４の状態を示す。
バッファ４２、４４のデータの流れを通信するために、サーバー２０の好ましい実施例は、１６ビット・ラップアラウンド・シーケンスナンバーを使用している。二つのシーケンスナンバーは、各バッファは４２，４４と関連している。第１のシーケンスナンバーは、バッファ内におかれた次のバイトのシーケンスナンバーを伝達する。この最初のシーケンスナンバーは、伝送用バッファ４２のためのＴＩＮ及び受信用バッファ４４のためのＲＩＮというラベルである。第２のシーケンスナンバーは受信用バッファ４４のためのＲＯＵＴ及び伝送用バッファ４２のためのＴＯＵＴというラベルである。
これらシーケンスナンバーは、ゼロで始まり、送出されるあるいは受け取られるデータの各バイトに対して一つ進む。シーケンスナンバーがＦＦＦＦに達すると、データの次のバイトが送出され、あるいは受け取られるとき、それらはゼロにラップバックする。変数ＴＩＮ、ＴＯＵＴ、ＲＩＮ、及びＲＯＵＴは、クライアント１８とサーバー２０の間で通信するために用いられるシーケンスナンバー変数である、ということが注意されるべきである。それらは、伝送用及び受信用バッファ４２、４４内のデータの物理的位置を特定しない。これらバッファは周知の技術であり、ここでは特に記載しない。
これらシーケンスナンバー、そして入力シーケンス及び受信用バッファパラメータや、出力シーケンス及び伝送用バッファパラメータの変数型をまとめる他の変数は、表７及び８に示されている。
ＴＩＮ、ＴＯＵＴ、ＲＩＮ及びＲＯＵＴのようなラップアラウンドシーケンスナンバーは、いくつかの非常に有効な数学的性質を有する。
しかしながら、シーケンスナンバーはこれらの関数の特別な定義がラップアラウンド特性の結果として使用されなければならないので、加減が行われるとき、特に混乱する。
それらの用途を明らかにするため、伝送用バッファ４２の実施例が図３及び４に図示され、検討されている。実施例３において、ＴＯＵＴシーケンスポインタ（バッファ４２からポート４０へ送出されるデータの次のバイトを示している。そして、矢印５０によって図３に示される。）は、バイトＳにセットされる。ｎバイトのデータが送出されるとき、送出されたバイトは、Ｓ＋（ｎ−１）であるけれども、ナンバーＳとされる。約束によって、われわれは、バッファがＳがＳ＋（ｎ−１）との間の送出バイトを有するということができる。しかしながら、われわれはＯｘＦＦＦＦでラップするシーケンスナンバーに通常の数を加えているので、われわれは次の公式を用いる表現Ｓ＋ｎを計算しなければならない：
（Ｓ＋ｎ）＆０ｘＦＦＦＦ
ここで、＆は、理論的ＡＮＤ操作を示す。このようにして、Ｓが０ｘＦＦＦ８で、ｎが５であれば、Ｓ＋ｎを計算する公式は、０ｘＦＦＦＣを与える。同様に、Ｓが０ｘＦＦＦ８でｎが９であれば、Ｓ＋ｎは２である。
ｎバイトを伝送した後、ＴＯＵＴシーケンスポインターは、伝送されるべき次のバイトの新しい位置に前進させなければならない。これは、古いＴＯＵＴの値を計算された結果Ｓ＋ｎに置き換えることにより行われる。
２つのシーケンスナンバーの間に存在するバイト数を決定するために、引き算が用いられる。しかしながら、特別の規則では、あるシーケンス数を他のシーケンス数から減算する結果を決定することは用いるに違いない。シーケンスナンバーｓ1，ｓ2の間のバイトの数を決定するために、次の公式が用いられる。
（ｓ1−ｓ2）＆0xffff
この公式は、シーケンスナンバーｓ1がシーケンスナンバーｓ2よりも数値的に大きい場合には有効である。例えば、ｓ1＝0xffffかつｓ2＝３であるならば、その時、（ｓ1−ｓ2）＆0xFFFFは、0x13が正しい答である。
実際、シーケンスナンバー間の距離の概念は、次のように定義すると有効となることが重要である。
ＤＩＳＴ(from, to)＝(((to)−(from))＆0xffff)
一対のシーケンスナンバーｓ1，ｓ2を与えると、次の式の条件では、ｓ3は、シーケンスナンバーｓ1，ｓ2の間のバイトのシーケンス位置にあることは真である。
ＤＩＳＴ（ｓ1，ｓ3）＜ＤＩＳＴ（ｓ1，ｓ2）
この公式は、ｓ3は、ｓ1とｓ2の間にあり、ｓ1からｓ3までの距離がｓ1からｓ2までの距離よりも小さい場合に当たる。
シーケンスナンバーは、データの量、すなわち、リモートバッファ内の自由空間の量を伝達できる。図４に示す特定ポート４０に対する伝送用バッファ４２において、ＴＯＵＴシーケンスナンバー５０がｓ1に設定され、一方ポート４０から伝送されるべき次のバイトを表すＴＩＮシーケンスナンバー５２がｓ2に設定される。図４において、ＴＯＵＴとＴＩＮの両方は、伝送用バッファ４２における位置に矢印で示されている。伝送用バッファ４２におけるバイトの数は、そのポートに対して決めることができる。
ＤＩＳＴ（ｓ1，ｓ2）
さらに、そのポートに対する伝送用バッファが、固定サイズＳＩＺＥを有する場合、そのバッファ内の自由バイト数は、次式で定まる。
ＳＩＺＥ−ＤＩＳＴ（ｓ1，ｓ2）
本発明におけるクライアント１８とサーバー２０は、ラップアラウンド・シーケンスナンバーの特性を利用して、両者間の情報のバンド単位の流れを制御することができる。クライアント１８とサーバー２０は、予めそうすることが定められているときにのみ、インバンド−データを他方に送る。この予権限は、データの量を伝送することにより完成するが、他方はそのデータ量に伝送することが許されている。送り手がこのスペースを満たすのに十分なデータを送ったとき、この送り手は、受け手がいくらかのデータを移送し、かつ送り手に追加スペースが利用できることを知らせるまで、伝送を休止する。
クライアント１８からサーバー２０への流れを制御するために、サーバー２０は、クライアント１８にバッファに伝送するサイズを与え、また伝送用バッファ４２(TOUT)における現在の第１バイトのシーケンスを与える。クライアント１８は、クライアント自身のシーケンスナンバーを送り続けながら、以前にサーバーに送ったデータのトラックを保持する。この送られたシーケンスナンバーを用いることによって、そのサーバー２０に与えられた情報に沿って、クライアント１８は、サーバーの伝送用バッファ４２内に残った空のスペースの量を計算することができる。それゆえ、クライアント１８は、その空きスペースに適合するデータ以上のデータを送らなくなる。
このプロセスは、図５のフローチャート図に示されている。伝送スライドを始めるための指示は、図のボックス100に示されている。第１ステップは、データがクライアント１８からサーバー２０のネットワークを介して受信されたか否かを決定する。もしそうであるなら、ボックス102に示すようにデータを受け取り、そしてそのデータを最適なポート４０に対する伝送用バッファ４２に格納される。データは、伝送用バッファに格納されると、ボックス104に示すように、ＴＩＮは、インクリメントされる
データをクライアント１８から受信したか否かに係わらず伝送用バッファ４２内にあるデータは、ポート４０から送り出すことができる。データがある場合、バッファ４２内のデータは、ポート４０上に送り出さなければならない(ボックス108)。そして、ＴＯＵＴは、インクリメントされる(ボックス110)。
この時点で、サーバー２０は、ＴＯＵＴをクライアント１８に報告することが必要であるかどうかを決定しなければならない。判断ボックス112,114,116によって示された３つの判断は、好ましい実施例において利用される。第１の判断112は、伝送されるべき次の出力バイトを示すＴＯＵＴとＴＰＯＳとを比較する。ＴＰＯＳは、出力シーケンス及び伝送用バッファの変数パラメータの１つで、サーバーの状態変数３８内に格納されている。ＴＰＯＳは、クライアント１８に報告された最終ＴＯＵＴの値を示す。上記減算公式のシーケンスナンバーを用いて計算されたＴＯＵＴとＴＭＡＸ間の差が、ＴＭＡＸよりも大きい場合、ＴＯＵＴはクライアントに報告される。ＴＭＡＸは、サーバーの状態変数３８内に格納され、そしてクライアント１８によって、ＴＯＵＴが報告された時点で伝送間隔を決定するために設定される。ＴＯＵＴがクライアント１８に報告されているときは、いつもボックス120で示すように、ＴＰＯＳがその時ボックス122でＴＯＵＴの値が設定される。
ボックス114において、ＴＯＵＴを報告するための第２の判定は、データがバッファ４２内に少なくともＴＴＩＭＥミリセコンド前にあったかを決定し、そして、時間ＴＯＵＴが報告されなかったので、サーバーの状態変数３８であるＴＴＩＭＥが、クライアント１８によって設定される。その場合、ＴＯＵＴはクライアント１８に報告される。
最後の判定116は、ＴＯＵＴの値とＴＲＥＱの値とを比較する。サーバーの状態変数３８の１つとして格納されたＴＲＥＱは、クライアント１８に設定され、その結果、ＴＯＵＴはＴＲＥＱを通過するとき、ＴＯＵＴはクライアント１８に報告される。数学的に、ラップアラウンド・シーケンスナンバーＴＯＵＴとＴＲＥＱを比較すると、上記シーケンスナンバーの減算公式を用いることにより、(TIN−TREQ)が(TIN−TOUT)より大きいか又は等しいかどうかを比較して両者の関係を判定することが必要である。ＴＯＵＴがＴＲＥＱを通過した場合、その時、ＴＲＥＱは、無効にされ（ボックス118）、ＴＯＵＴはクライアント１８に報告される(ボックス120)。
クライアント１８のドライバソフトウエアにおける柔軟性を許容するために、クライアント１８はそうすることが便利である場合には、クライアント１８がサーバーの伝送用バッファ４２がオーバーフローでない限りは、サーバー２０にデータを送ることができる。伝送用バッファ４２がオーバーフローでないことを確実にするための手順は、図６に示されている。
クライアント１８がデータをポート４０に伝送することを望む場合、クライアント１８用の通信プロトコルを処理するクライアント１８側のドライバは、サーバー２０がポートを開くことを要求しなければならない。うまく開くと、クライアント１８は伝送用バッファ４２のサイズＴＳＩＺＥがオープンポート４０に接続され、ＴＯＵＴはゼロとなる。
さらに、クライアント１８は、それ自身の伝送用シーケンスナンバーをリセットし、このシーケンスナンバーは、クライアント１８側に格納され、かつ維持されたラップアラウンドシーケンスナンバーである。
クライアント１８は、その時ボックス132で示すように、サーバーからＴＳＩＺＥを要求する。クライアントは、ボックス140で示すように、ＴＳＴＺＥが以下で説明するようにサーバー２０から受信するまで実際にデータを送ることができない。
クライアント１８は、次に、ホストコンピュータからデータを受信したかどうかを判断する(ボックス134)。データが受信されると、データは伝送用として待機しなければならない(ボックス135)。この伝送の待機については、詳細に後述される。
クライアント１８は、次にボックス136で送られるべきデータがあるかどうかを判定する。送るべきデータが準備されている場合、クライアントのドライバは、伝送用バッファ４２をオーバーフローさせることなくサーバー２０が受け入れることができるバイトの最大数を計算しなければならない(ボックス138)。これは、クライアントの伝送用シーケンスナンバーと最も近時に報告されたＴＯＵＴの値とを比較し、そして、この差を、ＴＳＩＺＥから減算する。
送るべき最大バイト数＝
ＴＳＩＺＥ−（伝送シーケンスナンバー−ＴＯＵＴ）
もちろん、シーケンスナンバーＴＯＵＴのクライアントの伝送シーケンスナンバーからの減算は、減算シーケンスナンバーのための公式に従って行わなければならない。もし、送るべきバイトの計算最大値が、ゼロよりも大きい場合(ボックス140)、バイトの計算最大値まで、サーバー２０に伝送することができる(ボックス144)。クライアント１８の伝送シーケンスナンバーは、その時、送られたバイト数によりインクリメントされる(ボックス146)。
データが送られたか否かに係わらず、クライアント１８は、サーバー２０がボックス148で示すように、ＴＯＵＴまたはＴＳＩＺＥに対する値を伝送したかどうかを次に判定しなければならない。
その場合、クライアント１８で格納されたＴＯＵＴまたはＴＳＩＺＥの値が最新である(ボックス149)。
送信機がだめで、それが報告がされずに、偽りの報告を避けるために、サーバー２０は、非常にまれなケースを認識する。伝送用バッファ４２が空のときで、ＵＡＲＴがまだインバンドーデータを送るのに忙しいときには、サーバー２０は、ＴＯＵＴの代わりに(TOUT−1)を報告する。この変換により、クライアント１８は、サーバー２０に伝送された最後のデータの伝送シーケンスナンバーに等しいＴＯＵＴをクライアントが受けるとき、全てのデータをうまく送ることができるようすることができる。
ポート４０から受け取られ、かつサーバー２０からクライアント１８に伝送される処理は、図７に示されている。このサーバー２０は、サーバーがボックス150で示すようにＲＷＩＮに対する値を受け取るまで、そのデータをクライアント１８に伝送することを許されていない。ＲＷＩＮは、クライアント１８により送られる入力シーケンス及び受信用バッファ変数であり、クライアント１８が受入を望む最高のシーケンスナンバーを示すものである。
初期ＲＷＩＮがクライアント１８から受信した時、サーバー２０、入来データが受信用バッファ４４内に格納されるべく利用できるかどうかを判断するために、ポート４０を調べる(ボックス152)。データが受信されると、受信用バッファ４４内にデータが格納され、そして、ＲＩＮシーケンスナンバーは、従ってインクリメントされる。これは、ボックス154とボックス156に示されている。
クライアント１８が如何に早くサーバー２０からデータを受信できるかということはサーバー２０にとっては知ることができないが、サーバー２０は、ポート上の入力フロー制御を実現する能力を有している。
フロー制御は、受信用バッファ４４内に残るデータの量（(RIN−ROUT)として計算される）がもう１つの入力シーケンス及び受信用バッファのＲＨＩＧＨの値を越える時に開始される。こうして、データが受信用バッファ４４内に格納され、かつＲＩＮがインクリメントされた後、サーバー２０は、入力制御が実施できるか否かを判断する(ボックス162,164)。
フロー制御は、受信用バッファ４４内のデータ量が、入力シーケンス及び受信用バッファ、ＲＬＯＷの値以下に降下するときに解放される。このことは、ボックス158,160で示すように、データがクライアント１８に送られた後に判断する。ステップ152におけるポート４０の検査でポート４０上に新しいデータが見つけられなかった場合、サーバー２０は、データが受信用バッファ４４に送られて利用できるかどうかを決定する。もし利用できない場合には、図７でボックス166に示すように、サーバー２０は、ポート４０にデータが送られるまで再待機する。
データが受信用バッファ４４で利用できるならば、その時、サーバー２０は、クライアント１８に送ることができるバイトの最大数を計算しなければならない(ボックス168)。この最大数は、シーケンスナンバーの減算公式に従って、単純な式(RWIN−ROUT)によって決定できる。この送られるべきバイトの最大数がゼロならば、サーバー２０は、判断ボックス170で示された最新となるべきＲＷＩＮのために待機しなければならない。この計算機がゼロよりも大きければ、サーバー２０は、データバイトをその時点でクライアント１８に送ることが適当であるか否かを判断しなければならない。
２つの判定は、データを伝送するトリガとして使用する。第１の判定(ボックス172)は、受信用バッファ４４内のバイト数(RIN−ROUT)と、クライアント１８によって送ることができる入力シーケンス及び受信用バッファのＲＭＡＸとを比較する。
受信用バッファ４４内のバイトがＲＭＡＸを越えると、バイトの最大数まで、クライアント１８は、送ることができる(ボックス176)。したがって、ＲＯＵＴは、インクリメントされる(ボックス178)。
受信用バッファ４４内のバイト数がＲＭＡＸを越えない場合、サーバー２０は、データが少なくともＲＴＩＭＥミリセコンド前にあったか否かを、さらに、時間データがクライアント１８に送られなかったかを判断する。その場合、判断ボックス174で示すように、データはクライアント１８に送られる。
データがクライアント１８に送られていない場合、データを送るための２つの条件172または174の１つが真となるまで受信用バッファ４４内にデータが残る。
ポート４０が開くと、ＲＭＡＸは１に、ＲＴＩＭＥはゼロに、ＲＬＯＷは１／４に、ＲＳＩＺ，ＲＨＩＧＨは３／４に、全てのシーケンスナンバーはゼロに初期化される。しかし、これらの変数は望ましい値に変更できる。
一般的に、サーバー２０は、そのポート４０にデータを送る時、送ることができるバイトの計算最大数によって制限されなければ、各ポート４０に対して全ての利用可能なデータを送る。この規定は、サーバー２０とクライアント１８の両方が処理しなければならないパケット数を減少させ、そしてクライアント１８の効率を改善する。
クライアント１８側では、ホストコンピュータにおいて、本発明のオペレーションは、ホストコンピュータのオペレーテングシステムにより大いに変化させることができる。本発明のオペレーションを開示するために、クライアント１８側では、ＵＮＩＸホストシステム上の実行は、図８に示すように概略が示されている。本発明は、クライアントドライバ200を用いることでサーバー２０側のポート４０にアクセスでき、このクライアントドライバは、ローカルに接続された１組のシリアルポート204に対して１つのドライバを対応させることによってホストオペレーテングシステムのＡＰＩを実行する。これを行うために、クライアントドライバ200は、各リモートサーバーボート204に対して入力用または受信用バッファ206、出力用または伝送用バッファ208、及びリモートサーバー２０の状態に関する情報並びに状態メモリ210に格納されるホストコンピュータへのインタフェースに対してサポートする。
また、このドライバ200は、汎用ネットワークに接続される標準ネットワークインタフェース212に対しても接続できる。クライアントドライバ200からサーバー２０への全ての通信は、ネットワーク10上で伝送される。ネットワークインタフェース212は、通信プロトコルの下でドライバ200が接続される多数のポート４０に関わらず、各サーバー２０のためのネットワーク上の１つポートだけに接続が可能である。
このシステムが放逐されたとき、このオペレーテングシステムの立ち上げ処理はドライバ200を始動させる。そして、各サーバー２０のために、STREAMS接続部218をサーバー２０に接続するユーザモードのデーモン214を始動させる。このデーモン214は、STREAMS接続部218をドライバ200と連動する制御装置202に接続する。
次に、デーモン214は、STREAMSインタフェースを用いて、ドライバ200がネットワーク接続上のデータをデーモン214からの相互作用でサーバー２０のＷ／Ｏに直接に送受信できるように、制御装置202より下位のオペレーテングシステムリンクのストリーム218を要求する。そうすることにより、ドライバ200は、制御装置のSTREAMSの待機サービスルーチンにおいて、サーバー２０からのＴＣＰ／ＩＰのデータを送受信することができる。これは、従来技術で得られたタスク切換用オーバーヘッドオペレーションを削除する。
接続モードは、バイトフロー接続であり、ドライバ200がサーバー２０へ信頼性のあるシーケンスデータの送受信を行えるようにする。ドライバ200は、この接続の信頼性に完全に頼っており、失われたパケット及び同等物を回復させる機能は備えていない。このドライバ200は、サーバー２０から受信下データ内のエラーまでも保護するとすると、ドライバ200はデーモン214までのハングアップ信号を通過させ、その時、サーバー２８への接続を閉じたりまた再び開くようにする。このようなエラーは通常のオペレーション中に起こすことはできない。このエラーは、リモートサーバーソフトウエア、ネットワークソフトウエア、ドライバソフトウエア等の失敗、あるいは、ある種のコンピュータの失敗によってのみ起こる。ホストコンピュータ内の標準ＴＣＰ／ＩＰソフトウエアは、汎用コンピュータネットワーク上で通常起こるような失なわれたまたは歪曲したパケットニよるこの種のエラーが起こらないように有効に保証している。
一旦、ドライバ200がネットワーク接続にアクセスすると、ドライバは、サーバー２０にサーバー２０上の多数のシリアルポート４０及びサーバー２０の他のハードウエア及びソフトウエアの両特性に関する情報を戻すように要求する。
ユーザーモードタスク216は、ＴＴＹシリアルタスク204を接続しようとするとき、ホストオペレーテングシステム215は、ドライバ200にオープンコールする。このポート204は他のユーザモードタスク216によってすでに接続されていない場合、ドライバは、サーバー２０へのオープン要求を送り、ドライバ200のＴＴＹポート204に連動するサーバー２０上のポート４０への独占的アクセスを得る。ポート４０が利用可能である場合、サーバー２０は、クライアント１８がポート４０を閉じるまで、あるいはクライアント１８の接続が失われるまで、独占的なアクセスを許すように応答する。
ポート４０が利用できない場合、ユーザモードタスク216によって作られたオリジナルのオープン要求のタイプに従ってアクションが取られる。ユーザモードタスク216は、要求が直ちに行うことができない場合にオープン失敗であるという要求を行うことができ、あるいはポート４０が利用可能となるまで、要求を待機させるという要求を行うことができる。前者の場合、ドライバ200は、サーバー２０に迅速なオープンを要求し、このサーバー２０は、ポート４０が混んでいる場合にその要求を拒絶し、その時、ドライバ200は、ユーザモードタスク216にエラーを戻す。後者の場合、ドライバ200は、サーバー２０にオープン待機中であることを知らせ、ポート４０が最終的に利用可能となるまでクライアントが待機の順番を待つようにするかを尋ねる。その時、サーバー２０は要求が順番待ちであるという指示を伝え、ドライバー200は、ポート４０が利用可能であることをサーバー２０がドライバ200に知らせるまで、ユーザモードタスク216を休止状態に置く。
ドライバ200は、サーバーポート４０がうまく開かれると、サーバー２０へ照会パケットを送り、ボーレート発生器の周波数値及びポート４０マーク及びスペースパリティーをサポートできるかどうかを含む、ポート４０のハードウエア及びソフトウエアの特性を学習する。
また、ドライバ200が、サーバー２０にポート204のための受信用バッファ206のサイズを送ることから、サーバー２０は、更なる規定なしでクライアント１８により送られるデータがどれ位かを知ることになる。
サーバー２０は、照会に応じて、またポート４０の伝送用及び受信用バッファ４２，４４のサイズを含む、ポート４０の特性を送る。
ドライバ200がサーバー２０からの返答を受け取った時、ドライバ200は、ポート４０に送受信用データを送る準備をし、かつホストオペレーテングシステムのオープン／クロース／ｉｏｃｔｌ（入力／出力制御）インタフェースによって所望の要求を行う時、ユーザモードタスク216のために制御及び状態の照会をする。
その後、サーバー２０のポート４０上に受信した全てのデータは、自動的にクライアント１８に送られ、そこで、データは受信用バッファ206に格納される。サーバー２０は、受信用バッファ206に適合できるだけの入力ポートデータを最初に送るように定められており、それ以上のバッファのオーバーランの可能性はない。
ユーザモードタスク216がデータの読取りを要求すると、ホストオペレーテングシステムは、ドライバ200の読取ルーチンを呼び出す。読取り要求のパラメータに従って十分なデータがサーバー２０から受信された時、ドライバ200はホストオペレーテングシステム215にそのデータを戻し、順次データをユーザモードタスク216へ通過させる。十分なデータが利用できない場合、ドライバ200は、データが到着するまで、あるいはホストオペレーテングシステム215のＡＰＩに従って中断されるまで、ユーザモードタスク216を休止状態に置く。
ドライバ200が受信用バッファ206からデータを転送したとき、ドライバ200は、このデータがシーケンスナンバーＲＷＩＮを転送させたバイト数だけインクリメントすることによって転送されたことをサーバー２０に知らせる。サーバー２０は、その時、そのデータがシーケンスナンバーＲＷＩＮに達した後に付加的なデータを送ることができる。
ユーザモードタスク216がデータを書き込むために要求されるとき、ホストオペレーテングシステム215は、ドライバ200の書込みルーチンを呼び出す。ドライバ200がそれをコピーする場合、伝送用バッファ208に適合するだけの量のユーザデータをコピーする。全てのデータが伝送用バッファ208に置かれたならば、サーバー２０は要求を実行し、ユーザモードタスク216を続行することができる。もし、伝送用バッファ208に適合する全てのデータがない場合、ドライバ200はデータがサーバー２０に送られるまでユーザモードタスク216を休止状態にする。そして、伝送用バッファ208内の空きスペースが十分となって、残りのデータがバッファ208内に格納できるようになる。
ユーザモードタスク216が、ｉｏｃｔｌ要求として知られている制限または照会要求をするとき、ホストオペレーテングシステム215は、ドライバ200内のｉｏｃｔｌルーチンを呼び出す。この要求が、ポート204のハードウエア及びソフトウエアの両特性を変える場合、ドライバ200は、状態メモリ210における変化を示す。そして、サーバー２０に必要な変更をさせるために命令を送る。この要求が、ドライバ200がサーバー２０に問い合わせることなく応答できる照会要求である場合、ドライバ200はこれを行う。この要求が、サーバー２０内のデータを必要とする場合、ドライバ200は、この情報のためにサーバー２０に照会要求を送り、そして、ユーザモードタスク216の要求を満足させるために戻された情報を用いる。
ユーザモードタスク216によって作ることができるこの種の要求は、非常に多様であり、その動作も広く変化する。ある場合、この要求は、直ちに満足できるが、また、ある場合には、この要求が完了するまでユーザモードタスク216が休止状態に置かれる。
ユーザモードタスク216がＴＴＹポート204に最後のクローズをするとき、ホストオペレーテングシステムは、ドライバ200のクローズルーチンを呼び出す。これにより、ドライバ200は、ユーザモードタスク216を休止状態にさせ、伝送用バッファ208内の全てのデータが伝送されるまで待機させ、また、サーバー２０に継続中の要求が完了するまで待機させる。
ドライバ200は、その時、サーバー２０にクローズ要求を送る。このクローズ要求が受け入れられると、サーバー２０は、ポート４０を割り当てそしてのクライアント１８にそのポートの再割り当てを可能にする。ドライバ200は、クローズを完了し、そしてユーザモードタスク216を続行する。
ドライバ200のオペレーションの効率を最適化し、かつホストオペレーションシステム215上の負荷を最小化するために、ドライバ200はサーバーとの通信を約５０回／秒の周期間隔で行う。この各間隔で、ドライバ200は、そのサーバー２０に接続されている各活動ポート204を調べ、このようなポート204，４０のすべてに対して要求及びデータを共通のメッセージとして与え、さらにこのメッセージを１つのオペレーションとしてサーバー２０に送る。この動作は、サーバー２０に送らなければならないＴＰＣ／ＩＰメッセージの総数、あるい他の汎用ネットワークメッセージを最小化し、またシステムのオペレーションを高める。
本発明は、ネットワーク１０間のシリアルポートハードウエアをシミュレートさせるために用いられるプロトコルを提供することである。このように使用するとき、ボードあるいは他のハードウエアは、ホストコンピュータに設置され、ローカルシリアルポートボードに類似するホストコンピュータへのシリアルポートインタフェースを備えている。
本実施例では、ボードは、汎用ネットワークのプロトコルスタックを含み、さらに、シリアルポートインタフェースを備え、またクライアントドライバ200と接続した上記機能を備えるソフトウエアを付加する。このボードを用いて、複数のドライバは、シリアルポートインタフェースだけが知られかつネットワーク１０の存在が知られていない、ホストオペレーテングシステム上で使用することができる。
このようなハードウエアのインプリメンテーション（実装）は、いくつかの利点がある。第１に、ハードウエア用またはソフトウエア用のインタフェースをエミュレートさせて使用することができ、このため各ドライバは、ホストオペレーテングシステム上で利用可能または容易に採用することができる。第２に、このインターフェースボード（またはカード）は、コンピュータに設置することができ、そこでたやすく利用できないハードウエアまたはソフトウエアをネットワークさせ、これにより、ホストコンピュータにネットワークサービスを提供できる。第３に、このインターフェースカードは、カード上にオーバーヘッドされる多くのシリアルポートをオフロードする付加的なプロセッサ及びハードウエアを含ませることができる。最後に、このようなカードは、本来、多機能であり、例えば、ローカルコンピュータのためにリザーブされ、あるいはアクセス可能なネットワークとなることができる小さな物理的装置を含んでいる。
サーバー２０とクライアント１８の間で交換可能なデータ及びコマンドを含む全ての情報は、パケットと呼ばれる小さな単位でネットワークプロトコルによって与えられるバイトフローよって送られる。これらのパケットのフォーマットは、本発明の通信プロトコルを作り上げる。この通信プロトコルパケットは、フォーマットにおいてＣＲＴターミナルのエスケープシーケンスと類似しており、その中で、シーケンスのわずかな第１バイト数が次に続くデータのフォーマット及び長さを決定する。
サーバー２０からクライアント１８への通信用パケットの形成は、サーバー２０のＣＰＵ３２において行われる。クライアント１８からサーバー２０に送られるパケットは、クライアント１８側で動作する特定ドライバによって作り出される。このパケットは、それ自体、パレットに含まれる情報の種類による可変フォーマット及び可変長さを有している。各パケットのフォーマットは、パケットを順次アクセスする処理によって決定される。より前のバイトの値が次に続くバイトのフォーマット及び内容をすべて決定する。
表９は、サーバー２０とクライアント１８との間で伝送される各パケットの異なる形式を示す。この表は、１つのパケットを主たる特殊形に分解された第１バイトがどのようになるかを示している。禁止(illegal)を示す各値は、本発明の好ましい実施例としては用いられない。
データパケットは、クライアント１８とサーバー２０との間のインバンドーデータのすべてを伝送するのに使用される。サーバー２０によって受信されると、このデータパケットのデータは、上記のように適当なポート４０を介して伝送される。
ウインドウ・シーケンスパケットは、受け手に送り手のシーケンスナンバーの状態について知らせる。この情報の伝送は、上記で概略説明したように、本発明のデータフロー制御の働きに関して重要である。ウインドウ・シーケンスパケットは、クライアント１８にＴＯＵＴを送るためにサーバー２０によって用いられ、そして、サーバー２０にＲＷＩＮを送るためにクライアント１８によって用いられる。
コマンドパケットも、１バイトにおけるコマンド型フィールドの値により、異なるフォーマットと異なる長さを有している。各コマンドは、サーバー２０の状態変数３８の各値について設定しかつ照会するために伝送される。さらに、コマンドパケットは、ポートを開くために利用され、クライアント１８がサーバー２０と同期が取れるように、またサーバーの送受信用バッファ４２，４４のサイズを確かめるために、特定ポート４０の容量を確かめるために、サーバー２０のバッファ４２，４４をフラッシュするために、ブレーク又は中間のキャラクタを伝送するために、また、入力または出力を休止あるいは再始動させるために利用される。このコマンドパケットは、表１０において設定されている。
２つの最も重要なコマンドパケットは、開いているポート４０と接続する場合のクライアント１８とサーバー２０との間の通信を包含している。ポート４０を開くための要求コマンドは、サーバー２０上のポート４０に独占的にアクセスすることを望むクライアント１８によって送られる。サーバー２０が、このオープン要求コマンドを受け取ると、サーバー２０は、クライアント１８のためにポート４０を開くように試み、そして、クライアント１８にオープン要求の結果を知らせるオープン応答パケットによって返答する。
オープン要求コマンドパケット及びオープン応答コマンドパケットのフォーマットは、表１１，１２に設定されている。
ポート４０を開くためのコマンドパケットは、要求するクライアント１８によって望むオープンコマンドの形式に従って異なる形式を取ることができる。オープンコマンドの可能な形式は、即時オープン、持続オープン、入来オープンがある。即時オープンのための要求は、ポート４０が有効であって直ちに利用可能である場合にのみ、受け入れられ、そして、ポート４０が要求するクライアント１８に割り与えられる。ポート４０か直ちに利用可能でない場合、要求は拒絶される。持続オープン要求がなされると、この要求は、ポート４０が利用可能であるならは、受け入れられ、そしてポート４０はクライアント１８に割り与えられる。もし、ポート４０が混んでいる場合、サーバー２０は、クライアント１８へのオープン応答パケットに戻り、クライアントにポート４０が混んでいることを示し、そして、クライアント１８をそのポート４０に対する待機リスト上に置く。ポート４０が順次利用可能になると、ポート４０は開かれ、そして、クライアント１８は、第２のオープン応答が受け入れ可能であることを知ることができる。
オープン要求の第３形式は、入来オープンとして要求である。この要求は、ポート４０が利用可能であるならば、直ちに受け入れられ、そして、キャリアがポート４０上に現れる。ポート４０が混んでいる場合、またはキャリアが現れない場合、サーバー２０は、対応するオープン応答コードに戻り、そして、クライアント１８をそのポート４０のための待機リスト上に置く。ポート４０が続いてキャリアの出現とともに利用可能になると、ポート４０は開かれ、クライアント１８は、第２のオープン応答が受け入れ可能であることを知ることができる。
クライアント１８は、特定ポート４０に対するオープン要求のキャンセル待機形式を送ることもできる。このコマンドをクライアント１８から受け取ったとき、サーバー２０は、クライアント１８がそのポート４０の待機リスト上にあるかどうかをチェックできる。
クライアント１８がそのリスト上にあることがわかると、クライアント１８は、取り除かれ、サーバー２０はオープン応答が受け入れ可能である指示に戻す。サーバー２０上のポート４０を追跡用ポートに組織化することが可能である。
このようにすると、サーバー２０は、追跡用ポートとして指定した１つ又はそれ以上の論理ポートを用意し、その結果、追跡用ポート群の１つをオープンにするための試行によって、追跡用ポート群の１つとして形成される物理的ポート４０を開く。こうして、クライアント１８が追跡用ポート群の一部であるポート４０を要求する場合、開かれた実際のポート４０は、要求されたポート４０とは異なることになる。クライアント１８は、オープンが受け入れられたのち、オープン応答のＰＮＵＭを調べなければならない。そして、そのポートの番号がポート４０に当たるか順次参照する。
同期要求コマンドは、その受け手が同期応答コマンドに応答するようにさせる。これは、その他のことに関しては何の効果もない。このコマンドの第１の目的は、クライアント１８がサーバーと同期できるように保証することである。例えば、クライアント１８は、呼び出しプログラムに戻る前に、要求したボーレート変更を一致させることを望む。クライアント１８は、第１にボーレート変更をサーバー２０に伝送することによりこれを達成する。そして、それに続いて同期要求を行う。サーバー２０は順次コマンドを処理するので、クライアント１８が同期応答のマッチングを受けると、クライアント１８はボーレート変更が完了したことがわかる。
シーケンス要求と応答パケットが与えられて、クライアント１８はサーバー２０へ入出力するデータの流れを正確に追跡することができる。サーバー２０は、クライアント１８にＲＩＮ及びＴＯＵＴを与えることによりこのパケットに応答する。
クライアント１８は、状態要求パケットを送り、サーバー２０におけるＥＳＴＡＴとＭＳＴＡＲＴの現在の常識を識別する。サーバー２０は、状態応答パケットにおける要求データを戻し、そして他の動作は取らない。このコマンドは、クライアント１８がサーバー２０の状態を学習する２つの方法のうちの１つである。クライアント１８は、選択された状態変化をサーバーによって自動的に報告させるために、選択イベント条件パケットを用いることができる。
クライアント１８は、ラインエラーカウンタを選ぶために、このラインエラーカウンタの周期的報告を形成し、そして、カウンタをクリアにするためにラインエラー要求パケットを送る。サーバー２０は、エラーカウンタの選別に応答してラインエラー応答を送り、そして、これは、変数ＬＴＩＭＥとして形成される周期的間隔で送られる。ラインエラー要求パケットは、すべてサーバーの変数ＬＴＩＭＥとして設定される。ＬＴＩＭＥの値が０では、自動的に報告を行わない。ＬＴＩＭＥの値がＦＦＦＦでは、ＬＴＩＭＥは変化しない。
クライアント１８がＬＴＩＭＥを０でない値に設定した後、サーバー２０は、ＬＴＩＭＥミリセコンド毎に（ほぼ２０ミリセコンドの正確さで）各エラーカウンタの状態を調べる。そして、その状態が最後の報告まで変わらないならば、自動ラインエラー応答パケットを送る。
バッファ要求パケットは、クライアント１８によって送られ、サーバーの伝送用バッファ４２及び受信用バッファ４４のサイズを学習する。サーバー２０は、バッファ応答パケットに応答する。ポートがうまく開いた後、そしてサーバー２０にデータを送る前、クライアント１８は、サーバーのバッファ４２，４４のサイズを確認する必要がある。伝送用バッファ４２のサイズは、クライアント１８が伝送できるデータがどの位かを知るために必要である。受信用バッファ４４のサイズは、サーバー２０がフロー制御の流れ容量の高低を設定するのに必要である。
ポートの能力要求パケットは、ポート４０のハードウエア及びソフトウエアの各能力を学習するためにクライアント１８によって送られる。他のポートのコマンドはそのレベルが違っており、このコマンドが発生しても、ポート４０は開くことはできない。
設定ボーレートコマンドは、クライアント１８がポートのボーレート、すなわち、ポート４０のＣＦＬＡＧＳ，ＩＦＬＡＧＳ，ＯＦＬＡＧＳ，ＸＦＬＡＧＳを設定するのに使用する。
クライアント１８は、選択イベント条件コマンドを送り、どのＥＳＴＡＴ，ＭＳＴＡＴの条件がサーバー２０に１つのイベントパケットを送らせることができるかを特定する。このクライアント１８は、また、状態要求パケットを用いてＥＳＴＡＲＴ及びＭＳＴＡＲＴを調査することができる。
設定ウインドウトリガーコマンドにより、クライアント１８はサーバーの状態変数３８の１つであるＴＲＥＱを設定することができる。ＴＲＥＱは、ウインドウシーケンスパケットが送られる時点で、クライアント１８が要求したレベルである。ＴＲＥＱが出力バッファにおける現在のデータ範囲から外れている場合、サーバー２０は直ちに１つのウインドウシーケンスパケットに応答する。
設定モデム出力及びフロー制御パケットは、クライアント１８がモデム出力を設定し、そして、モデム信号ハードウエア用のフロー制御を選択するするために送られる。ＲＴＳとＤＴＲのモデムフロー制御が選択されたとき、ＭＯＵＴにおけるＲＴＳとＤＴＲの値は無視される。
クライアント１８は、設定受信用の（高／低）ウオーター指示パケットを送り、受信用の（高／低）フオーター指示のフロー制御を設定する。このパケットはサーバー２０によって処理されると、直ちに影響を与える。入力バッファにおけるキャラクタの数がＲＨＩＧＨを越えると、フロー制御は、直ちに実施が強制される。入力バッファがＲＬＯＷより小さいと、フロー制御は、直ちに緩やかに実施される。
クライアント１８は、設定フロー制御キャラクタパケットを送り、サーバー２０にソフトウエアフロー制御キャラクタを設定する。同様に、クライアント１８は、設定ＲＭＡＸとＲＴＩＭＥコマンドを送り、各パラメータＲＭＡＸ，ＲＴＩＭＥを設定し、さらに設定ＴＭＡＸとＲＴＩＭＥコマンドを、ＴＭＡＸとＴＴＩＭＥに設定する。
クライアント１８は、インバンドーデータの頭文字を送るために、伝送用キャラクタ即時パケットを送る。伝送用即時データにおいて、ソフトウエアフロー制御は、無視され、ハードウエアフロー制御は、ＭＦＬＯＷの代わりに変数ＭＣＴＲＬに用いられる。クライアント１８は、ハードウエアブレーク信号を送るために伝送用ブレーク即時パケットを利用する。このブレーク信号は、また、すべてのインバンドーデータの前に送られ、そして、ソフトウエアまたはハードウエアのフロー制御に関わらず送られる。
クライアント１８は、サーバーの入力及び出力バッファの両方またはいずれか一方をフラッシュするためにフラッシュバッファパケットを送る。休止（入力／出力）パケットは、サーバーにおけるソフトウエアフロー制御条件の幾組かを休止する。受信用バッファ内のキャラクタの数がＲＬＯＷより少ない場合、入力を休止するための試みは無駄になる。最後に、反休止（入力／出力）パケットは、サーバーにおけるソフトウエアフロー制御条件の幾組かを休止させない。受信用バッファ内のキャラクタの数がＲＨＩＧＨより多い場合、入力を休止させないための試みは無駄になる。
イベントパケットがサーバー２０によって送られて、ＥＳＴＡＴとＭＳＴＡＴの状況の変化をクライアント１８に知らせる。サーバー２０は、（ＥＴＲＡＮ及びＥＩＮＴ)あるいは（ＭＴＲＡＮ及びＭＩＮＴ）が非ゼロであるときはいつでも、各ポート４０にイベントパケットを送る。
この要求を確実にすることがイベントパケットに、別な方法で報告され、失われるようなトランジッションを引き起こさない。すなわち、サーバー２０は、最初にＥＬＡＳＴを設定し、続けてＭＬＡＳＴを設定する。それから、ＥＬＡＳＴ及びＭＬＡＳＴをクライアント１８に報告する。
モジュール０−７は、１バイトモジュール選択パケットと共に選択可能である。モジュール８−２５５は、２バイトのパケットを要求する。モジュールとポートペアと物理的ポートナンバーとの間で、転換することが可能である。モジュールｎが選択されるとき、すべてのそれに続くパケットのポートＫは、物理的ポート１６＊ｎ＋Ｋに関連する。
ＩＤ要求パケットは、リモート側からの機器構成の情報あるいは一致を得るため、クライアント１８あるいはサーバー２０のどちらかに送られる。リモート側はＩＤ応答パケットに応じる。
デバッキングパケット型は、クライアント１８とサーバー２０との間で、デバッキングデータを伝送するような、デバッグをする目的でサーバー２０のポート４０にアクセスすることをサポートする。これらのパケットはクライアント１８がサーバープログラムメモリ３６にアクセスすることも可能にし、プログラムメモリ３６に記憶されているようなサーバ２０のプログラムを代えること、あるいはプログラムメモリ３６の内容をレビューすることを許容する。
リセットパケット型は、接続が停止される前に、クライアント１８あるいはサーバー２０によって、リモート側にプロトコルエラーを報告するために送られる。パケットはＡＳＣＩＩフォーマットのリセットのための理由の説明を含む。リセットパケットは、対話で送られた直前のパケットでなければならない。
この議論は、ＵＮＩＸ以外の他のオペレーテングシステムについて特になされていないが、ノーベル、ウインドウズ、ウインドウズＮＴ、ＯＳ／２及びＤＯＳのアプリケーションプログラミングインタフェースを満足させるために要求されるＸＦＬＡＧＳ、エラーカウンタやイベントフラグで実証される特徴は、当業者に明らかである。結果として、これらオペレーテングシステムのいずれでも、本発明のインプリメンテーションは、当業者に明らかである。
本発明はそのすべての詳細に制限されることはなく、本発明の精神あるいは範囲内でなされる変形や修正されたものにも制限されない。
【図面の簡単な説明】
図１は、種々のホストコンピュータと本発明のサーバーを、汎用コンピュータにネットワーク接続することを示す。
図２は、汎用ネットワーク上のクライアントのコンピュータに、サーバーの主要構成要素を含む、本発明のサーバーを取り付けたことを示す。
図３は、シーケンス空間内の位置に向けて指定する単一のシーケンスナンバーを有するラップアラウンド・シーケンス空間を示す。
図４は、シーケンス空間内の位置に向けて指定する２つのシーケンスナンバーを有するラップアラウンド・シーケンス空間を示す。
図５は、サーバーが、クライアントからサーバーを通じてポートへ伝送されるデータの流れを、制御する過程を示す。
図６は、クライアントからサーバーを通じてポートへ伝送されるデータの流れを、クライアントが制御する過程を示す。
図７は、サーバーが、ポートからサーバーを通じてクライアントへ伝送されるデータの流れを、制御する過程を示す。
図８は、汎用ネットワーク上のクライアントのコンピュータに、クライアントのドライバーの主要構成要素を含む、本発明のサーバーを取り付けたことを示す。
Claims (17)
- 複数の通信ポートを有するサーバーと、ネットワークを介してホストコンピュータを前記サーバーに接続するドライバを含む通信システムであって、
前記ドライバが前記サーバーの通信ポートの各々に対応するローカル通信ポートを形成することによって前記サーバーの通信ポートをエミュレートし、
さらに、前記ドライバは、アプリケーション・プログラム・インターフェース（ＡＰＩ）を含み、このインターフェースにより、前記ホストコンピュータ上で実行される応用プログラムが、前記サーバーの複数の通信ポートの１つを十分に制御可能であり、前記サーバーの複数の通信ポートが、ホストコンピュータに対してローカルであるようにハードウエアとソフトウエアのフロー制御を含んでいることを特徴とするシステム。 - 前記ドライバは、応用プログラムが前記ドライバから付加的なローカル通信ポートを要求されたとき、前記ホストコンピュータから前記サーバーへの単一のネットワーク接続を維持することを特徴とする請求項第１項記載のシステム。
- 前記ドライバは、ローカル通信ポートとしてＴＴＹ装置を形成することを特徴とする請求項第１項記載のシステム。
- 前記ドライバは、アプリケーション・プログラム・インターフェースを介して応用プログラムからの設定された入出力値（Ｉ／Ｏ）を受信し、更に、前記ドライバは、許可されたサーバーの通信ポートのハードウエア特性を形作るために前記サーバーに前記入出力値を通信することを特徴とする請求項第１項記載のシステム。
- 前記サーバーの通信ポートは、シリアルポートであることを特徴とする請求項第１項記載のシステム。
- ネットワーク接続は、ＴＣＰ接続であることを特徴とする請求項第１項記載のシステム。
- さらに、ネットワーク上で信頼性のある双方向のバイトフロー接続として、前記ネットワーク接続を確立するために前記ホストコンピュータ上で実行するデーモン（214）を含み、該デーモンは、ＳＴＲＥＡＭＳインターフェース（218）を介して前記ドライバと連動する制御装置に接続し、前記信頼性があるバイトフロー接続のネットワーク接続を前記ドライバにリンクさせるために前記ＳＴＲＥＡＭＳインターフェース（218）を用いていることを特徴とする請求項第１項記載のシステム。
- ネットワーク接続を介して前記ホストコンピュータに接続されるリモートサーバーの複数の通信ポートをエミュレートするドライバを含む、ホストコンピュータ用のハードウエア装置であって、
前記ドライバは、前記サーバーの通信ポートの各々に対応するローカル通信ポートを形成し、さらに、前記ドライバは、アプリケーション・プログラム・インターフェース（ＡＰＩ）を含み、このインターフェースにより、ホストコンピュータ上で実行される応用プログラムが、前記サーバーの通信ポートの１つを十分に制御可能であり、前記サーバーの通信ポートが、ホストコンピュータに対してローカルであるように、ハードウエアとソフトウエアのフロー制御を含んでいることを特徴とするハードウエア装置。 - 前記ドライバは、標準のアプリケーション・プログラム・インターフェース（ＡＰＩ）を介して前記ホストコンピュータ上で実行する応用プログラムからローカル通信ポートの１つを制御する要求を受信することを特徴とする請求項第８項記載のハードウエア装置。
- 前記ドライバは、ターミナルサーバーの通信ポートの１つに、ホストコンピュータに独占的にアクセスできるように、前記ターミナルサーバーにその要求を送受信することを特徴とする請求項第９項記載のハードウエア装置。
- 前記ターミナルサーバーは、要求されたローカル通信ポートに対応する前記サーバーの通信ポートに独占的にアクセスできるようにすることを特徴とする請求項第１０項記載のハードウエア装置。
- 前記ドライバは、応用プログラムが付加的なローカル通信ポートを要求するとき、前記ホストコンピュータから前記サーバーに単一のネットワーク接続を維持することを特徴とする請求項第８項記載のハードウエア装置。
- 前記ドライバは、ローカル通信ポートとしてＴＴＹ装置を形成することを特徴とする請求項第８項記載のハードウエア装置。
- 前記ドライバは、アプリケーション・プログラム・インターフェースを介して応用プログラムからの設定された入出力値（Ｉ／Ｏ）を受信し、更に、前記ドライバは、前記ターミナルサーバーの通信ポートのハードウエア特性を形作るためのターミナルサーバーに前記入出力値を通信することを特徴とする請求項第９項記載のハードウエア装置。
- ターミナルサーバーの通信ポートは、シリアルポートであることを特徴とする請求項第８項記載のハードウエア装置。
- ネットワーク接続は、ＴＣＰ接続であることを特徴とする請求項第８項記載のハードウエア装置。
- さらに、ネットワーク上で信頼性のある双方向のバイトフロー接続として、前記ネットワーク接続を確立するために前記ホストコンピュータ上で実行するデーモン（214）を含み、該デーモンは、ＳＴＲＥＡＭＳインターフェース（218）を介して前記ドライバと連動する制御装置に接続し、前記信頼性があるバイトフロー接続のネットワーク接続を前記ドライバにリンクさせるために前記ＳＴＲＥＡＭＳインターフェース（218）を用いていることを特徴とする請求項第８項記載のハードウエア装置。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US21319794A | 1994-03-15 | 1994-03-15 | |
| US08/213,197 | 1994-03-15 | ||
| PCT/US1995/003183 WO1995025311A1 (en) | 1994-03-15 | 1995-03-15 | System and method for communication with a remote network device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09510562A JPH09510562A (ja) | 1997-10-21 |
| JP3743963B2 true JP3743963B2 (ja) | 2006-02-08 |
Family
ID=22794111
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP52414295A Expired - Lifetime JP3743963B2 (ja) | 1994-03-15 | 1995-03-15 | リモートネットワーク装置を用いる通信システム及び方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6047319A (ja) |
| EP (1) | EP0750768B1 (ja) |
| JP (1) | JP3743963B2 (ja) |
| KR (1) | KR100387207B1 (ja) |
| AU (1) | AU706132B2 (ja) |
| DE (1) | DE69527948T2 (ja) |
| WO (1) | WO1995025311A1 (ja) |
Families Citing this family (62)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5694546A (en) | 1994-05-31 | 1997-12-02 | Reisman; Richard R. | System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list |
| US6393496B1 (en) * | 1995-11-09 | 2002-05-21 | Curtis A. Schwaderer | Operating system and network independent application program interface for use in an intelligent communication device |
| US6278705B1 (en) * | 1997-04-08 | 2001-08-21 | 3Com Corporation | Integrated architecture to support a single system image across multiple network access servers |
| JP3809255B2 (ja) * | 1997-07-26 | 2006-08-16 | スター精密株式会社 | プリンタ |
| US6697868B2 (en) * | 2000-02-28 | 2004-02-24 | Alacritech, Inc. | Protocol processing stack for use with intelligent network interface device |
| US7055173B1 (en) | 1997-12-19 | 2006-05-30 | Avaya Technology Corp. | Firewall pooling in a network flowswitch |
| US6266335B1 (en) * | 1997-12-19 | 2001-07-24 | Cyberiq Systems | Cross-platform server clustering using a network flow switch |
| US6209032B1 (en) | 1998-10-19 | 2001-03-27 | International Business Machines Corporation | Enabling target servers to control determination of full user synchronization |
| US6374288B1 (en) * | 1999-01-19 | 2002-04-16 | At&T Corp | Digital subscriber line server system and method for dynamically changing bit rates in response to user requests and to message types |
| US6820115B1 (en) * | 1999-04-09 | 2004-11-16 | Nortel Networks Limited | Apparatus and method for mediating message transmission across a network |
| WO2001025934A1 (fr) * | 1999-10-05 | 2001-04-12 | Fujitsu Limited | Systeme serveur/client |
| AT410376B (de) * | 2000-01-25 | 2003-04-25 | Wieland Martin | Anordnung und verfahren zur datenübertragung von und zu cnc-steuerungen über ein standardnetzwerk und einen leitrechner |
| AT413246B (de) * | 2000-01-25 | 2005-12-15 | Wieland Martin | Verfahren zur erfassung, übertragung und speicherung von schaltzuständen elektrischer schaltgeräte |
| US6779039B1 (en) | 2000-03-31 | 2004-08-17 | Avaya Technology Corp. | System and method for routing message traffic using a cluster of routers sharing a single logical IP address distinct from unique IP addresses of the routers |
| US6880089B1 (en) | 2000-03-31 | 2005-04-12 | Avaya Technology Corp. | Firewall clustering for multiple network servers |
| US7526775B2 (en) * | 2000-05-17 | 2009-04-28 | Aol Llc, A Delaware Limited Liability Company | Component installation tool |
| US7047196B2 (en) | 2000-06-08 | 2006-05-16 | Agiletv Corporation | System and method of voice recognition near a wireline node of a network supporting cable television and/or video delivery |
| JP2002099495A (ja) * | 2000-09-26 | 2002-04-05 | Fujitsu Ltd | クライアントサーバシステム、サーバ及びクライアント |
| US20020040391A1 (en) * | 2000-10-04 | 2002-04-04 | David Chaiken | Server farm formed of systems on a chip |
| US6763387B1 (en) * | 2000-10-12 | 2004-07-13 | Hewlett-Packard Development Company, L.P. | Method and system for sharing a single communication port between a plurality of servers |
| DE50000986D1 (de) * | 2000-11-06 | 2003-01-30 | Nkl Nordwestdeutsche Klassenlo | Datenverarbeitungssystem |
| US8095370B2 (en) | 2001-02-16 | 2012-01-10 | Agiletv Corporation | Dual compression voice recordation non-repudiation system |
| US7552216B2 (en) * | 2001-03-27 | 2009-06-23 | Lexmark International, Inc. | Method of sharing a printer |
| US6996833B1 (en) * | 2001-03-27 | 2006-02-07 | Microsoft Corporation | Protocol agnostic request response pattern |
| US7293075B2 (en) * | 2001-04-12 | 2007-11-06 | Unisys Corporation | Method and apparatus for operating a data processing system using multiple console views |
| US7457847B2 (en) * | 2002-01-02 | 2008-11-25 | International Business Machines Corporation | Serial redirection through a service processor |
| US6971042B2 (en) * | 2002-04-18 | 2005-11-29 | Huge Systems, Inc. | Media server with single chip storage controller |
| JP4259036B2 (ja) * | 2002-05-14 | 2009-04-30 | 株式会社日立製作所 | ネットワークデータのキャッシュ方法およびシステム |
| JP4095352B2 (ja) * | 2002-06-14 | 2008-06-04 | キヤノン株式会社 | 情報処理装置、情報処理装置の制御方法、及び当該制御方法を実行するためのコンピュータプログラム |
| US20040158635A1 (en) * | 2003-01-23 | 2004-08-12 | Digi International Inc.. | Secure terminal transmission system and method |
| US20040156370A1 (en) * | 2003-02-07 | 2004-08-12 | Lockheed Martin Corporation | System for evolutionary adaptation |
| KR100552509B1 (ko) | 2003-10-13 | 2006-02-14 | 삼성전자주식회사 | 이동 애드 혹 네트워크에서의 브로드캐스트 데이터 처리방법 |
| US8010789B2 (en) * | 2003-11-13 | 2011-08-30 | Lantronix, Inc. | Secure data transfer using an embedded system |
| US20050108434A1 (en) * | 2003-11-13 | 2005-05-19 | Witchey Nicholas J. | In-band firewall for an embedded system |
| US20050149624A1 (en) * | 2003-11-21 | 2005-07-07 | Daniel Jakubiec | Modular communication server |
| US20050137838A1 (en) * | 2003-12-18 | 2005-06-23 | Medlyn Dayne H. | Dial-up resource simulator |
| US9219729B2 (en) * | 2004-05-19 | 2015-12-22 | Philip Drope | Multimedia network system with content importation, content exportation, and integrated content management |
| US7590710B1 (en) * | 2004-06-17 | 2009-09-15 | Wavetrix, Inc. | Method and system for extending a communication port via a general purpose network |
| US7660910B2 (en) * | 2004-08-30 | 2010-02-09 | Lantronix, Inc. | Secure communication port redirector |
| US20060095546A1 (en) * | 2004-10-07 | 2006-05-04 | Nokia Corporation | Method and system for locating services in proximity networks for legacy application |
| US7644160B2 (en) | 2004-10-20 | 2010-01-05 | Digi International Inc. | Login specific virtual ports |
| US7721047B2 (en) * | 2004-12-07 | 2010-05-18 | International Business Machines Corporation | System, method and computer program product for application-level cache-mapping awareness and reallocation requests |
| US8145870B2 (en) | 2004-12-07 | 2012-03-27 | International Business Machines Corporation | System, method and computer program product for application-level cache-mapping awareness and reallocation |
| JPWO2006082782A1 (ja) * | 2005-02-02 | 2008-06-26 | サイレックス・テクノロジー株式会社 | 周辺機器利用方法および周辺機器サーバ |
| JP4709966B2 (ja) * | 2006-06-28 | 2011-06-29 | サイレックス・テクノロジー株式会社 | リモートコントロールシステム及びリモートコントロール装置 |
| US8190868B2 (en) | 2006-08-07 | 2012-05-29 | Webroot Inc. | Malware management through kernel detection |
| US7769992B2 (en) * | 2006-08-18 | 2010-08-03 | Webroot Software, Inc. | File manipulation during early boot time |
| US7761621B2 (en) * | 2006-09-14 | 2010-07-20 | Digi International Inc. | Embedded virtual serial port |
| US7650444B2 (en) * | 2006-09-28 | 2010-01-19 | Digi International, Inc. | Systems and methods for remotely managing an application-specific display device |
| EP2195969A2 (en) * | 2007-09-14 | 2010-06-16 | Softkvm, Llc | Software method and system for controlling and observing computer networking devices |
| WO2009085011A1 (en) * | 2007-12-28 | 2009-07-09 | St Electronics (Info-Comm Systems) Pte Ltd | Radio gateway network |
| US20090228733A1 (en) * | 2008-03-06 | 2009-09-10 | Integrated Device Technology, Inc. | Power Management On sRIO Endpoint |
| US8625621B2 (en) * | 2008-03-06 | 2014-01-07 | Integrated Device Technology, Inc. | Method to support flexible data transport on serial protocols |
| US8213448B2 (en) * | 2008-03-06 | 2012-07-03 | Integrated Device Technology, Inc. | Method to support lossless real time data sampling and processing on rapid I/O end-point |
| US20090225775A1 (en) * | 2008-03-06 | 2009-09-10 | Integrated Device Technology, Inc. | Serial Buffer To Support Reliable Connection Between Rapid I/O End-Point And FPGA Lite-Weight Protocols |
| US8312190B2 (en) * | 2008-03-06 | 2012-11-13 | Integrated Device Technology, Inc. | Protocol translation in a serial buffer |
| US8312241B2 (en) * | 2008-03-06 | 2012-11-13 | Integrated Device Technology, Inc. | Serial buffer to support request packets with out of order response packets |
| US11489857B2 (en) | 2009-04-21 | 2022-11-01 | Webroot Inc. | System and method for developing a risk profile for an internet resource |
| CN102546347B (zh) * | 2010-12-17 | 2016-03-30 | 中兴通讯股份有限公司 | 基于proc技术的虚拟串口热插拔的实现方法及系统 |
| US11368760B2 (en) | 2012-08-17 | 2022-06-21 | Flextronics Ap, Llc | Applications generating statistics for user behavior |
| US8863198B2 (en) | 2012-08-17 | 2014-10-14 | Flextronics Ap, Llc | Television having silos that animate content source searching and selection |
| US20160119675A1 (en) | 2012-09-06 | 2016-04-28 | Flextronics Ap, Llc | Programming user behavior reporting |
Family Cites Families (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3676858A (en) * | 1970-09-30 | 1972-07-11 | Honeywell Inf Systems | Method, apparatus and computer program for determining the transmission rate and coding configuration of remote terminals |
| FR2478913A1 (fr) * | 1980-03-20 | 1981-09-25 | Telediffusion Fse | Concentrateur de systeme de communication pour relier plusieurs terminaux asynchrones de teleinformatique |
| US4547880A (en) * | 1983-05-13 | 1985-10-15 | Able Computer | Communication control apparatus for digital devices |
| US4975905A (en) * | 1984-06-01 | 1990-12-04 | Digital Equipment Corporation | Message transmission control arrangement for node in local area network |
| US4975904A (en) * | 1984-06-01 | 1990-12-04 | Digital Equipment Corporation | Local area network for digital data processing system including timer-regulated message transfer arrangement |
| US4823122A (en) * | 1984-06-01 | 1989-04-18 | Digital Equipment Corporation | Local area network for digital data processing system |
| US5228137A (en) * | 1985-10-29 | 1993-07-13 | Mitem Corporation | Method for controlling execution of host computer application programs through a second computer by establishing relevant parameters having variable time of occurrence and context |
| US5426421A (en) * | 1986-04-21 | 1995-06-20 | Gray; William F. | Method of automatically managing a network or remote function-excecuting apparatus from a programable network control center |
| US4817130A (en) * | 1986-09-11 | 1989-03-28 | International Telesystems Corporation | Call management system with protocol converter and port controller |
| US4885789A (en) * | 1988-02-01 | 1989-12-05 | International Business Machines Corporation | Remote trusted path mechanism for telnet |
| US4972368A (en) * | 1988-03-04 | 1990-11-20 | Stallion Technologies, Pty. Ltd. | Intelligent serial I/O subsystem |
| US5257369A (en) * | 1990-10-22 | 1993-10-26 | Skeen Marion D | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| US5163131A (en) * | 1989-09-08 | 1992-11-10 | Auspex Systems, Inc. | Parallel i/o network file server architecture |
| JPH03123244A (ja) * | 1989-10-06 | 1991-05-27 | Matsushita Electric Ind Co Ltd | 通信装置 |
| FR2661300B1 (fr) * | 1990-04-23 | 1994-06-17 | Bull Sa | Convertisseur multiprotocoles de raccordement d'une pluralite de terminaux asynchrones a un reseau de telecommunications. |
| FR2670925B1 (fr) * | 1990-12-20 | 1995-01-27 | Bull Sa | Architecture informatique distribuee utilisant un reseau local de type csma/cd. |
| US5265239A (en) * | 1991-04-08 | 1993-11-23 | Ardolino Anthony A | Method for remotely accessing service programs of a local processing system supporting multiple protocol stacks and multiple device drivers |
| US5559958A (en) * | 1991-06-24 | 1996-09-24 | Compaq Computer Corporation | Graphical user interface for computer management system and an associated management information base |
| US5301275A (en) * | 1991-10-03 | 1994-04-05 | Compaq Computer Corporation | Data transfer system with variable data buffer size and programmable interrupt frequency |
| US5469545A (en) * | 1991-10-03 | 1995-11-21 | Compaq Computer Corp. | Expandable communication system with data flow control |
| US5222062A (en) * | 1991-10-03 | 1993-06-22 | Compaq Computer Corporation | Expandable communication system with automatic data concentrator detection |
| US5341499A (en) * | 1992-04-02 | 1994-08-23 | International Business Machines Corporation | Method and apparatus for processing multiple file system server requests in a data processing network |
| US5323393A (en) * | 1992-11-18 | 1994-06-21 | Canon Information Systems, Inc. | Method and apparatus for obtaining and for controlling the status of a networked peripheral |
| US5379296A (en) * | 1992-12-31 | 1995-01-03 | Unisys Corporation | Method and apparatus for interfacing a workstation to a plurality of computer platforms |
| US5544320A (en) * | 1993-01-08 | 1996-08-06 | Konrad; Allan M. | Remote information service access system based on a client-server-service model |
| DE4306031C2 (de) * | 1993-02-26 | 1995-11-02 | Siemens Ag | Verfahren zum ferngesteuerten Administrieren von Kommunikationssystemen |
| US5355365A (en) * | 1993-03-31 | 1994-10-11 | Multi-Tech Systems, Inc. | Intelligent local area network modem node |
| US5812879A (en) * | 1993-04-19 | 1998-09-22 | Moro; Ricardo J. | External multiple peripheral interface to computer serial port using individually configured parallel port terminals |
| US5640595A (en) * | 1993-06-29 | 1997-06-17 | International Business Machines Corporation | Multimedia resource reservation system with graphical interface for manual input of resource reservation value |
| US5666534A (en) * | 1993-06-29 | 1997-09-09 | Bull Hn Information Systems Inc. | Method and appartus for use by a host system for mechanizing highly configurable capabilities in carrying out remote support for such system |
| US5581703A (en) * | 1993-06-29 | 1996-12-03 | International Business Machines Corporation | Method and apparatus for reserving system resources to assure quality of service |
| GB2280820A (en) * | 1993-07-29 | 1995-02-08 | Ibm | Distributed system for call processing |
| KR100304063B1 (ko) * | 1993-08-04 | 2001-11-22 | 썬 마이크로시스템즈, 인코포레이티드 | 2지점간상호접속통신유틸리티 |
| US5568525A (en) * | 1993-08-19 | 1996-10-22 | International Business Machines Corporation | System and method for connection of multiple protocol terminals |
| CA2107299C (en) * | 1993-09-29 | 1997-02-25 | Mehrad Yasrebi | High performance machine for switched communications in a heterogenous data processing network gateway |
| US5596579A (en) * | 1993-10-01 | 1997-01-21 | International Business Machines Corporation | High performance machine for switched communications in a heterogeneous data processing network gateway |
| US5475601A (en) * | 1994-02-15 | 1995-12-12 | Emhart Glass Machinery Investments Inc. | Control for glassware forming system including bidirectional network gateway |
| US5754830A (en) * | 1996-04-01 | 1998-05-19 | Openconnect Systems, Incorporated | Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation |
-
1995
- 1995-03-15 JP JP52414295A patent/JP3743963B2/ja not_active Expired - Lifetime
- 1995-03-15 EP EP95913686A patent/EP0750768B1/en not_active Expired - Lifetime
- 1995-03-15 DE DE69527948T patent/DE69527948T2/de not_active Expired - Lifetime
- 1995-03-15 WO PCT/US1995/003183 patent/WO1995025311A1/en active IP Right Grant
- 1995-03-15 KR KR1019960705125A patent/KR100387207B1/ko not_active IP Right Cessation
- 1995-03-15 AU AU19979/95A patent/AU706132B2/en not_active Expired
-
1996
- 1996-07-17 US US08/682,407 patent/US6047319A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09510562A (ja) | 1997-10-21 |
| AU1997995A (en) | 1995-10-03 |
| US6047319A (en) | 2000-04-04 |
| KR100387207B1 (ko) | 2003-10-04 |
| DE69527948D1 (de) | 2002-10-02 |
| WO1995025311A1 (en) | 1995-09-21 |
| EP0750768A1 (en) | 1997-01-02 |
| DE69527948T2 (de) | 2003-01-02 |
| AU706132B2 (en) | 1999-06-10 |
| EP0750768A4 (en) | 1998-12-23 |
| EP0750768B1 (en) | 2002-08-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3743963B2 (ja) | リモートネットワーク装置を用いる通信システム及び方法 | |
| US5446868A (en) | Network bridge method and apparatus | |
| US5012489A (en) | Method for sending a plurality of data channels over a single communications line | |
| US5265239A (en) | Method for remotely accessing service programs of a local processing system supporting multiple protocol stacks and multiple device drivers | |
| AU594596B2 (en) | Data conferencing arrangement | |
| US4996685A (en) | Technique for dynamically changing an ISDN connection during a host session | |
| US4896289A (en) | Expansion interface board system for connecting several personal computers to an electronic typesetter connected to a host personal computer | |
| RU2139636C1 (ru) | Протокол передачи пакетных данных для радиосвязи | |
| US5317692A (en) | Method and apparatus for buffer chaining in a communications controller | |
| US6496509B1 (en) | System for transmitting data packets between computers via an IEEE-1394 network medium | |
| US5197067A (en) | Packet communication system using a telephone switching network and a data flow control method | |
| US6347093B1 (en) | Application programming interface for modem and ISDN processing | |
| US6446232B1 (en) | Distribution of modem error correction and compression processing | |
| JPH0687556B2 (ja) | データ通信方法 | |
| US5721891A (en) | Detection of N length bit serial communication stream | |
| US5923443A (en) | Infrared communication port fax software legacy flow control emulation | |
| US6674742B1 (en) | Automatic SDLC role configuration on router interfaces | |
| US20020129099A1 (en) | Method and apparatus for virtualizing a serial port in a data processing system | |
| US7072351B1 (en) | Collision recovery interface support in a home phoneline networking alliance media access controller (HPNA MAC) operating in accordance with at least two different data rate standards | |
| JP3343905B2 (ja) | Ｈｄｌｃ高速通信システム | |
| US6834313B1 (en) | Performing a two-step read on a MAC register in a home network as an atomic read | |
| Davidson | Interconnection services of Net/One | |
| KR200177449Y1 (ko) | 시리얼 라인을 이용한 다중 랜 인터페이스 장치 | |
| US7106754B1 (en) | Application programming interface for modem and ISDN processing | |
| Barrett | Using a terminal switching exchange for computer peripheral sharing and other purposes. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040824 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20041122 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050117 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050223 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051018 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051111 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091202 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101202 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111202 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111202 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121202 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131202 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |