JP3439037B2 - 通信インターフェース - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置に係
り、特に、他の情報処理装置とパケット通信を行う際、
通信プロトコルを処理する通信制御装置の機能を拡張し
て、アプリケーションプログラムにサービスを提供する
方法に関する。

【０００２】

【従来の技術】通信回線の仕様としてイーサネットを用
い、通信プロトコルにＴＣＰ／ＩＰを使ったクライアン
ト／サーバ型ＬＡＮが普及している。ＯＳにＵＮＩＸを
使う情報機器の場合、例えばそれがサーバの機能を果た
すのであれば、クライアントからの接続要求を受け付け
る準備として通信チャネルをオープンし、あるウエルノ
ウンアドレスにおいてクライアントからの要求が来るの
を待つ。一方、クライアントは、通信チャネルをオープ
ンしてある特定のホスト即ちサーバのウエルノウンアド
レスに接続し、しかる後、サーバにサービスの要求を送
り、応答を受け取る。クライアントとサーバがお互いの
通信チャネルを認識して結んだ論理的な通信路をコネク
ションと呼び、このようにコネクションを確立してから
行う通信をコネクション型の通信と呼ぶ。ＴＣＰはコネ
クション型の通信を行うプロトコルである。また、ＴＣ
Ｐ／ＩＰを採用する情報機器では、ＯＳがＵＮＩＸでな
くともほぼ同じ様に、上述した手順で通信を行ってい
る。

【０００３】そして、クライアントにおいて通信を行お
うとするプロセスは、送るべきデータが入ったバッファ
をＴＣＰに引き渡す。ＴＣＰはそのデータにＴＣＰヘッ
ダを付加して下層のＩＰに引き渡す。ＩＰはさらにＩＰ
ヘッダを付加してＩＰパケットとし、下層のデータリン
ク層に引き渡すので、データリンク層ではイーサネット
の規約に従ってデータを送受する。

【０００４】尚、本明細書では、ＩＰが相手ホストのＩ
Ｐと送受するデータをＩＰパケット又はデータグラムと
呼び、ＴＣＰが相手ホストのＴＣＰと送受するデータを
単にパケットと呼ぶことにする。

【０００５】

【発明が解決しようとする課題】ＴＣＰは、パケットの
破壊や消失について保証している。しかし、パケットサ
イズの制約や通信速度の制約から、下層のＩＰは一つの
パケットを複数に分割して送受することもあるので、そ
れを渡されたＴＣＰは、プロセスが求めるサイズのデー
タを一度に上位プロセスに引き渡すところまでは保証し
ていない。そのため、ＴＣＰを使って通信を行おうとす
るプロセスは、所望サイズのデータを受け取るまで何度
もＴＣＰに受信要求を繰り返す必要があった。また、非
同期で送られてくるパケットを効率よく受け取るために
は、周期的に受信要求を出して常にパケットを取り込む
ようにする必要があった。この為、プログラムの構成が
複雑になるとともに、そのプロセスがＣＰＵを独占しが
ちになる弊害もあった。

【０００６】さらに、クライアントプロセスが受け取る
パケットは、必ずしもクライアントにとって既知のサイ
ズであるとは限らない。例えば、ＳＴＸ（１６進数で０
２、以下０２Ｈと表記）で始まるデータ列は、その最終
バイトがＥＴＸ（０３Ｈ）で終端する場合、データのサ
イズは送り側が決定するので受け側にとっては不定であ
る。従って、クライアントプロセスは常に最大サイズで
パケットの受信を要求するか、逆に小さなサイズで受信
要求しておいて受信したパケット毎に最終バイトを検査
する必要があった。前者の場合、サーバプロセスが最大
サイズに満たないデータしか送ってこなかったとき、ク
ライアントプロセスはいつまでも待たされる事態も生じ
かねない。また、後者の場合、頻繁に受信要求を繰り返
すことになり、前述したような問題が発生する。

【０００７】本願は、パケット通信に伴う複雑な受信処
理からプロセスを開放し、且つ、効率的な受信を可能に
してメインＣＰＵの負荷を低減することを目的とする。

【０００８】

【課題を解決するための手段】本発明は、相手装置とデ
ータの送受信を行うプロトコル処理手段と、アプリケー
ションプログラムからの要求に応じて前記プロトコル処
理手段に通信処理を要求する要求処理手段とを有する通
信インターフェースであって、相手装置とのデータの送
受信に関するユーザが変更可能な条件を記述したテーブ
ルを備え、前記要求処理手段は、前記テーブルに記述さ
れた条件に基づいて前記プロトコル処理手段に通信処理
を要求するようにし、アプリケーションプログラムから
の１回の受信要求に応じて前記テーブルに記述された条
件のデータを受信して前記アプリケーションプログラム
にその受信データを返すようにして、上記課題を解決す
るものである。

【０００９】

【実施例】図８は、本願発明の通信インターフェース87
を備えた計算機80（以下、ホストと呼ぶ）の機能ブロッ
ク図である。このホスト80は、イーサネット回線86を介
して他のホストコンピュータとＬＡＮ接続されている。
ホスト同士は相互にクライアントにもサーバにもなるこ
とが出来るが、本実施例では設定によってそのホストが
クライアントとして動作するか、サーバとして動作する
かを予めユーザが決めておく構成である。

【００１０】図に示すように、ホスト80には、通信を行
おうとするアプリケーションプログラム85からの要求を
受け付けるアプリケーションプログラム要求処理部81
と、ＴＣＰ／ＩＰプロトコルを実行して相手ホストとデ
ータを送受するプロトコル処理部82と、イーサネットの
規約に従って実際に物理的にデータをイーサネット回線
86に送信し、また受信するデータ送受信手段83と、通信
に関するパラメータを記憶するパラメータテーブル90と
がある。

【００１１】そして、アプリケーションプログラム要求
処理部81は、そのパラメータテーブル90の内容に応じて
プロトコル処理部82に対し、後述するタイムアウト値や
パケットサイズを通知するとともに、通信処理を要求す
る。また、プロトコル処理部82は通信時間を計測するた
めの計時手段84を備えていて、指定されたサイズのパケ
ット受信時だけでなく、設定された時間の経過時にも、
上位のアプリケーションプログラム要求処理部81に通知
するようにしている。ここでは、設定時間が経過するこ
とをタイムアウトと呼ぶことにする。また、アプリケー
ションプログラム85のことを、以下、プロセスと呼ぶ場
合もある。

【００１２】図９はパラメータテーブル90の内容を示
し、Ｃ／Ｓモード91はそのホストがクライアントのモー
ドで動作するか、サーバのモードで動作するかを示すフ
ラグである。ホスト名92はそのホストがクライアントモ
ードで動作する場合に接続すべきサーバの名前である。
サーバが複数存在する場合には、アプリケーションプロ
グラム85から直接指示されたサーバ名を優先させること
ができる。接続時タイムアウト値93は、クライアントの
アプリケーションプログラム要求処理部81がホストとの
通信を要求され、通信チャネルをオープンしてサーバに
コネクションを要求した後、サーバから応答が返るまで
の最大の待ち時間である。つまり、クライアント／サー
バ間のコネクションを確立する為に使える最大許容時間
である。

【００１３】受信時タイムアウト値94は、クライアント
からサーバに対してデータの送信を要求したとき、要求
を送ってから最初のデータグラムを受信するまでの待ち
時間の最大値である。また、パケットタイムアウト値95
は、最初のデータグラムを受信してからそのデータグラ
ムを含む完全なパケットを受信するまでの時間を規定す
る。完全なパケットとは、後述する条件に該当するパケ
ットであって、指定されたサイズのバイトデータを有す
るパケットである。

【００１４】本実施例ではパラメータテーブル90のこと
をプロトコルアジャストテーブルと呼び、以下ＰＡＴと
略称する。図１０は、上記パラメータを設定するための
基本仕様設定画面10の表示例である。モード11はクライ
アントなら「１」を、サーバーなら「２」を設定する。
接続ホスト名12は既知のサーバ名を設定する。この例で
は「NET-HOST」がサーバ名である。接続タイムアウト13
と受信タイムアウト14及び１パケットの受信時間15は、
何れも０．１秒から６００秒の範囲で設定が可能であ
る。そのうち１パケットの受信時間15は、受信処理の効
率を考えて数秒以下に設定するのがよい。

【００１５】図９に戻って、先頭データ96乃至最大サイ
ズ99は受信するパケットの条件を指定する。即ち、受信
したパケットの先頭のバイトデータが、先頭データ96に
示されたバイトデータに一致する場合、そのパケットの
サイズ（本実施例ではバイト数）は、最大サイズ99で示
された大きさが期待されることを示している。又は、そ
のパケットの最後尾のデータが末尾データ（１）97また
は末尾データ（２）98に一致すれば、最大サイズ99によ
らずそのパケットは完成したことを示すものである。従
って、最大サイズ99に一致しないパケットであっても、
先頭と末尾のデータが条件を満たせば、前に述べた完全
なパケットとして扱い得ることを指示するものである。

【００１６】図１１は、これら条件を設定する受信仕様
設定画面20の表示例である。先頭データ21から最大サイ
ズ24迄の４個の条件の組み合わせを１０組まで登録する
ことができる。例えば、符号２５で示す組みは、先頭デ
ータ21が０２Ｈ即ちＳＴＸ、末尾データ（１）22が０３
Ｈ即ちＥＴＸ、そして、最大サイズ24が１０２４バイト
のパケットを規定している。これは、受信したデータグ
ラムの先頭バイトがＳＴＸであるとき、最後尾のデータ
がＥＴＸであるか、又は、受信したデータが全部で１０
２４バイトになったとき、そのパケットは完成したもの
として上位のプロセス85に引き渡すことを指示するもの
である。

【００１７】また、符号２６で示す組みは、先頭データ
21がＥＮＱの場合で、これは１バイトで意味を成すデー
タなので最大サイズ24は１バイト、末尾データは設定無
しである。つまり、ＥＮＱを受信したなら直ちにその１
バイトを上位のプロセス85に引き渡すことを指示するも
のである。

【００１８】また、符号２７で示す組みは、先頭データ
21は何でもよいが末尾のデータがＣＲまたはＬＦである
とき、上位プロセス85にそのパケットを引き渡すことを
指示するものである。この場合も、ＣＲ又はＬＦが来る
前に１３０バイトのデータを受信したならば、その時点
でパケットを引き渡すことを指示している。このように
本実施例では、先頭データとして「＊＊」を総称的な指
定を表わす文字、所謂ワイルドカード文字として使用可
能である。

【００１９】尚、その他のデータとして、最大サイズ24
だけを１０２４バイトに指定したパケットを予め規定し
ている。これは、符号２７で示す様な条件をＰＡＴ90内
にユーザが設定しなかった場合に有効である。

【００２０】図１０及び図１１に示した画面は、通信条
件を設定するための図８に示すアプリケーションプログ
ラム85によって表示される。そして、ユーザが画面上で
設定した値がＰＡＴ90に反映されるようになっている。
アプリケーションプログラム要求処理部81はＰＡＴ90を
参照し、その条件に基づいてプロトコル処理部82に通信
条件を指定し、処理を依頼する。

【００２１】次に、図１乃至図７の流れ図を参照しなが
ら、実施例の動作を説明する。アプリケーションプログ
ラム要求処理部81は、アプリケーションプログラム85
（上位プロセス）からシステムコールの形で通信の開始
や、データの送信、受信の指示を受け、次のように動作
する。＜コネクションの確立＞アプリケーションプログ
ラム要求処理部81は、次のようにしてサーバとのコネク
ションを確立する。

【００２２】即ち、図１（ａ）に示すように、先ずＰＡ
Ｔ90からパラメータを読み出して自身のメモリに写し
（ステップS101）、プロトコル処理部82に対して通信ポ
ートの確保を要求して（同S102）応答を待つ。同時に、
呼び出しを行ったプロセス85をブロックしてスリープ状
態とし、他のプロセス85に制御を譲渡する。一方、プロ
トコル処理部82は、通信ポート（ソケット）を確保して
その結果を返す。

【００２３】図１（ｂ）に示すように、プロトコル処理
部82の応答から、アプリケーションプログラム要求処理
部81はソケットが確保できたか否かを判断し、確保でき
なかった場合（同S103;No）、上位プロセス85に対して
その旨エラーを返す。一方、ソケットを確保できた場合
は、ＰＡＴ90に定義された接続タイムアウト値をプロト
コル処理部82に送って設定し（同S104）、同じくＰＡＴ
90に定義されたホスト名92を持つサーバとのコネクショ
ンを要求して（同S105）応答を待つ。プロトコル処理部
82は、内部の計時手段84を用いて計時し、先に設定され
た接続タイムアウト値の範囲内でサーバとのコネクショ
ンの確立を試み、その結果を返す。

【００２４】図１（ｃ）に示すように、アプリケーショ
ンプログラム要求処理部81はプロトコル処理部82の応答
がタイムアウトか否かを判断し（同S106）、タイムアウ
トの場合、上位プロセス85に対してその旨エラーを返
す。一方、タイムアウトでない場合は、コネクションが
確立したか否かを判断し（同S107）、確立していなけれ
ば上位プロセス85に対してその旨エラーを返す。コネク
ションが確立していれば正常終了して上位プロセス85に
制御を返す。

【００２５】尚、サーバは、システム起動時に図７に示
す処理を実行して、常にクライアントからの接続要求を
受け付けられるようにしている。即ち、通信ポートを確
保し（同S701）、確保できたならば（同S702;Yes）、ク
ライアントの接続要求を受け付ける（同S703）。ＵＮＩ
Ｘマシンであれば、これは通常、accept()システムコー
ルで終了する。 ＜データの受信＞アプリケーションプログラム要求処理
部81は、次のようにしてサーバからのデータを受信す
る。

【００２６】即ち、図２に示すように、先ず、ＰＡＴ90
に記述された受信タイムアウト値をプロトコル処理部82
に送って設定する（同S201）。そして本実施例では、何
でもよいからデータを受信したならばその先頭バイトを
返すように、１バイトの受信をプロトコル処理部82に要
求する（同S203）。

【００２７】但し、上位プロセス85から受信バイト数を
明示して呼び出しを受けた場合には、ステップＳ２０２
から端子Ａに進み、図５に示すように、指定されたバイ
ト数のデータの受信を要求し（同S501）、応答を待つ。
このように、上位プロセス85が求めるバイト数の受信デ
ータを返すように、プロトコル処理部82に要求するのが
従来のやり方である。しかし、本願発明では、最初に受
信したデータグラムの先頭の１バイトが何であるかを知
るために、先ず１バイトのデータを返すようにプロトコ
ル処理部82に要求するのである。

【００２８】以下、１バイトの受信を要求した場合の動
作を説明する。プロトコル処理部82は、内部の計時手段
84を用いて計時し、先に設定された受信タイムアウト値
の範囲内でデータグラムの到着を待ち、その結果を返
す。即ち、データグラムが到着すればその先頭の１バイ
トを返し、そうでなければタイムアウトのエラーを返
す。

【００２９】図３に示すように、アプリケーションプロ
グラム要求処理部81はプロトコル処理部82の応答がタイ
ムアウトか否かを判断し（同S301）、タイムアウトの場
合、上位プロセス85に対してその旨エラーを返す。一
方、タイムアウトでない場合は、受け取った１バイトの
データによってＰＡＴ90の先頭データを検索し、対応す
る末尾データと最大サイズを取得する（同S302）。図１
１の例でいくと、プロトコル処理部82から受け取った１
バイトがＳＴＸならば、末尾データはＥＴＸ、最大サイ
ズは１０２４である。また、先頭データがＥＮＱならば
末尾データは指定無しで、最大サイズは１である。それ
以外のデータが先頭データの場合はすべて、末尾データ
はＣＲまたはＬＦで、最大サイズが１３０である。

【００３０】そこで、アプリケーションプログラム要求
処理部81は、既に取得済みの先頭１バイトを最大サイズ
から差し引いて残りのサイズを計算する（同S303）。そ
の結果、残りサイズが０ならば（同S304;Yes）、データ
の受信は終了なので受信パケットを上位プロセス85に返
して正常終了する。例えば、受信データがＥＮＱなら
ば、その１バイトを返して直ちに終了するのである。

【００３１】一方、残りサイズが０でなければ（同S30
４;No）、引き続いて送られてくるはずの残りのデータ
を受信するために、プロトコル処理部82に先ずタイムア
ウト値１００ｍｓを設定し（同S305）、ＰＡＴ90のパケ
ットタイムアウト値95からその１００ｍｓを減算してお
く（同S306）。そして、残りサイズを指定してデータの
受信をプロトコル処理部82に要求する（同S307）。この
１００ｍｓという値は、先頭の１バイトを既に受信して
いるということから、最初のデータグラムは到着済みで
あると考えられるので、２バイト目以降の残りのデータ
を早めに取り込むために、短めに設定している。

【００３２】図１１に示す例では、先頭データ21がＳＴ
Ｘの場合、パケットの最大サイズ24は１０２４バイトで
あるが、最初のデータグラムの末尾データがＥＴＸであ
れば、１０２４バイトの到着を待たずに上位プロセス85
に受信パケットを返すことができる。そこで、先頭１バ
イトを受信した直後は、短めのタイムアウト値ですぐに
結果を上位プロセス85に返せるようにしているのであ
る。

【００３３】図４は２バイト目以降の受信処理を示して
いる。上で述べたように、プロトコル処理部82は、１０
０ｍｓ経過するとその時点で受信済みのデータグラムを
返すので、アプリケーションプログラム要求処理部81
は、受信データが有れば（ステップS401;Yes）、その末
尾のバイトデータが末尾データ（１）97又は（２）98と
一致するか比較する（同S402）。一致すればそのパケッ
トは完成なのでそれを上位プロセス85に返して正常終了
する。一方、末尾データ（１）97又は（２）98のいずれ
とも一致しなかった場合（同S403;No ）、今回受け取っ
たデータグラムのバイト数を残りサイズから差し引いて
残りサイズを再計算する（同S404）。その結果、残りサ
イズが０ならば、所定サイズのデータの受信は終了なの
で、受信パケットを上位プロセス85に返して正常終了す
る。

【００３４】一方、残りサイズが０でなければ、ＰＡＴ
90のパケットタイムアウト値95の残りが０以上か否か検
査する（同S406）。もし０であれば、設定時間内に完全
なパケットが受信できなかったということなので、現在
受信済みのデータを上位プロセス85に返すとともにタイ
ムアウトエラーを通知する。ＰＡＴ90のパケットタイム
アウト値95の残りが０以上であれば（同S406;Yes）、引
き続いて送られてくるはずの残りのデータを受信するた
めに、プロトコル処理部82に今度はタイムアウト値３０
０ｍｓを設定し（同S407）、ＰＡＴ90のパケットタイム
アウト値95からその３００ｍｓを減算しておく（同S40
8）。そして、残りサイズを指定してデータの受信をプ
ロトコル処理部82に要求する（同S409）。この要求に対
するプロトコル処理部82からの応答があったときは、ア
プリケーションプログラム要求処理部81は再びステップ
Ｓ４０１から処理を再開するようになっている。

【００３５】尚、ステップＳ４０１で受信データが無し
の場合、同Ｓ４０６に跳んでパケットタイムアウトの検
査を実行する。そして、その際、プロトコル処理部82に
タイムアウト値として３００ｍｓを設定している。これ
は、最初のデータグラム受信でパケットが完成しなかっ
たことから、パケットが二つ以上に分割されていること
は明らかなので、送信側の処理時間を考えて、図３に示
した初回の設定値１００ｍｓより大きくして、当該プロ
セスがＣＰＵを独占しないように配慮している。

【００３６】以上説明したとおり、データの受信に際し
ては、アプリケーションプログラム85は受信要求を一回
発行すればよい。その一回の受信要求に応じて、アプリ
ケーションプログラム要求処理部81からは、ＰＡＴ90に
定義された条件に一致するパケットを受信したときか、
同じくＰＡＴ90に定義された時間を経過してタイムアウ
トエラーになったときにアプリケーションプログラム85
に通知される。その間、ＰＡＴ90に定義された条件やタ
イムアウトの検査は総べて、アプリケーションプログラ
ム要求処理部81とプロトコル処理部82が行うので、アプ
リケーションプログラム85は一切なにもしなくてもよ
い。

【００３７】ところで、上位プロセス85が受信バイト数
を明示して受信要求した場合には、アプリケーションプ
ログラム要求処理部81は図５の処理の後、図６の処理を
実行する。これは図４に示した処理から、末尾バイトを
比較するステップＳ４０２と同Ｓ４０３を省略したもの
であり、それ以外の処理は全く一致する。

【００３８】

【発明の効果】本発明によれば、アプリケーションプロ
グラム85は一回の受信要求だけで所望のパケットを受け
取ることができるので、処理が単純化でき、プログラム
作成が容易になる。又、所望のデータが送信されてこな
いときは、所定の時間でタイムアウトエラーとなって返
ってくるので、いつまでも待たされることがなく、それ
に応じた適切な対応をとることが可能になる。そして、
頻繁にパケットの到着を確認する必要が無いので、その
アプリケーションがＣＰＵを独占することがなくなり、
システム全体の効率が向上する。

【図面の簡単な説明】

【図１】実施例におけるクライアントの通信開始の処理
手順を示す流れ図である。

【図２】実施例における１バイト受信指示の処理手順を
示す流れ図である。

【図３】実施例における先頭１バイト受信後の処理手順
を示す流れ図である。

【図４】実施例における２バイト目以降の受信処理の処
理手順を示す流れ図である。

【図５】実施例における指定バイトの受信指示の処理手
順を示す流れ図である。

【図６】実施例における２バイト目以降の受信処理の処
理手順を示す流れ図である。

【図７】実施例におけるサーバの通信開始処理の手順を
示す流れ図である。

【図８】実施例の通信インターフェースを含む情報処理
装置の構成を示すブロック図である。

【図９】実施例におけるパラメータテーブルの構成例を
示す図である。

【図１０】実施例における基本仕様設定画面の表示例を
示す図である。

【図１１】実施例における受信仕様設定画面の表示例を
示す図である。

【符号の説明】 １０ 基本仕様設定画面 ２０ 受信仕様設定画面 ８０ 情報機器 ８１ アプリケーションプログラム要求処理部 ８２ プロトコル処理部 ８３ データ送受信手段 ８４ 計時手段 ８５ アプリケーションプログラム ８６ イーサネット回線 ８７ 通信インターフェース ９０ パラメータテーブル

Claims (4)

(57)【特許請求の範囲】
1. 【請求項１】 相手装置とデータの送受信を行うプロト
   コル処理手段と、アプリケーションプログラムからの要
   求に応じて前記プロトコル処理手段に通信処理を要求す
   る要求処理手段とを有する通信インターフェースであっ
   て、相手装置とのデータの送受信に関するユーザが変更
   可能な条件を記述したテーブルを備え、該テーブルは少
   なくとも１パケットの受信時間を記述するものであり、
   前記要求処理手段は、前記テーブルに記述された条件に
   基づいて前記プロトコル処理手段に通信処理を要求する
   ものであって、前記１パケットの受信時間より短い時間
   を指定して前記プロトコル処理手段にデータの受信を繰
   り返し要求し、前記プロトコル処理手段は計時手段を備
   え、前記要求処理手段から指定された時間が経過する
   と、その時点で受信済みのデータを返すようにし、前記
   要求処理手段は、アプリケーションプログラムからの１
   回の受信要求に応じて前記テーブルに記述された条件の
   データを受信して前記アプリケーションプログラムにそ
   の受信データを返すようにしたことを特徴とする通信イ
   ンターフェース。
2. 【請求項２】 前記テーブルにはさらに１パケットのサ
   イズを記述するようにし、前記要求処理手段は、前記１
   パケットの受信時間内に前記１パケットのサイズに等し
   いデータを受信したならば、要求元のアプリケーション
   プログラムにそのデータと共に肯定応答を返し、一方、
   前記１パケットの受信時間内に前記１パケットのサイズ
   に等しいデータを受信しなかったならば、要求元のアプ
   リケーションプログラムにエラーを返すことを特徴とす
   る請求項１記載の通信インターフェース。
3. 【請求項３】 前記テーブルにはさらに、パケットの先
   頭データと末尾データとを記述可能にし、前記要求処理
   手段は、前記１パケットの受信時間内に受信したデータ
   の先頭と末尾のデータが共に前記テーブルに記述された
   先頭データと末尾データにそれぞれ一致したとき、要求
   元のアプリケーションプログラムにそのデータと共に肯
   定応答を返し、一方、前記１パケットの受信時間内に一
   致しなかったならば、要求元のアプリケーションプログ
   ラムにエラーを返すようにしたことを特徴とする請求項
   １記載の通信インターフェース。
4. 【請求項４】 前記先頭データは、ワイルドカード文字
   が使用可能であることを特徴とする請求項３記載の通信
   インターフェース。