rpcgen - コマンド (プログラム) の説明 - Linux コマンド集 一覧表

4rpcgen1 - RPC プロトコルコンパイラ

rpcgen 2infile4

rpcgen [-D2name4[=2value4]] [-T] [-K 2secs] 2infile4

rpcgen -c|-h|-l|-m|-t [-o 2outfile4 ] 2infile4

rpcgen [-I] -s 2nettype4 [-o 2outfile4] 2infile4

rpcgen -n 2netid4 [-o 2outfile4] 2infile4

4rpcgen1 は RPC プロトコルを実装する C 言語のコードを生成するツールである。 4rpcgen1 への入力は RPC 言語 (遠隔手続き呼び出し言語 Remote Procedure Call Language) として知られる C 言語に似た言語である。

4rpcgen1 は通常、1 つの入力ファイルを受け取って 4 つの出力ファイルを生成する、 第 1 の書式で使われる。 入力ファイル 2infile1 が 4proto.x1 という名前である場合、 4rpcgen1 はヘッダファイル 4proto.h1、 XDR ルーチン 4proto_xdr.c1、 サーバ側スタブ 4proto_svc.c1、 クライアント側スタブ 4proto_clnt.c1 を生成する。 4-T1 オプションを指定すると、さらに RPC ディスパッチテーブル n4proto_tbl.i1 も生成する。 4-Sc1 オプションを指定すると、クライアント側での遠隔手続きの使用法を説明する サンプルコードも生成する。 このコードは 4proto_client.c1 に書き出される。 4-Ss1 オプションを指定すると、 遠隔手続きの書き方を説明するサンプルのサーバ用コードを生成する。 このコードは 4proto_server.c1 に書き出される。

生成されたサーバは、 ポートモニタ (例えば 4inetd1 や 4listen1) で起動することも、 それ自身で起動することもできる。 ポートモニタで起動される場合、 ファイルディスクリプタ 40 を引き渡すトランスポートのためだけの サーバを生成する。 トランスポートの名前は環境変数 4PM_TRANSPORT1 を設定することで指定しなければならない。 4rpcgen1 で作成されたサーバが実行されると、 サーバは環境変数 4NETPATH1 で指定された全てのトランスポート用にサーバハンドルを生成する。 環境変数 4NETPATH1 が設定されていない場合、 4/etc/netconfig1 ファイルに記述された全ての可視トランスポート用にサーバハンドルを生成する。 注意: トランスポートはコンパイル時ではなく実行時に選択される。 サーバが自分自身で開始する場合、 デフォルトではバックグラウンド実行に移る。 サーバプロセスをフォアグラウンドで実行するには、 特殊定義シンボル 4RPC_SVC_FG1 が使われる。

第 2 の書式は、より洗練された RPC サーバを生成する特別な機能を提供する。 これらの機能には、ユーザー定義の 4#define1 と RPC ディスパッチテーブルのサポートが含まれる。 RPC ディスパッチテーブルのエントリには以下のものがある。

»

その手続きに対応するサービスルーチンへのポインタ

»

入出力引き数へのポインタ

»

これらのルーチンのサイズ
サーバは、認証をチェックした後にサービスルーチンを実行するために、 ディスパッチテーブルを使うことができる。 クライアントライブラリは、記憶領域管理と XDR データ変換を詳細に扱うために、 ディスパッチテーブルを使うことができる。

上で示した他の 3 つの書式は、 全ての出力ファイルではなく、特定の 1 つのファイルが必要な場合に使われる。 いくつかの使用例が以下の「例」のセクションで説明されている。 4rpcgen1 が 4-s1 オプション付きで実行された場合、 特定クラスのトランスポート用のサーバを生成する。 4-n1 オプション付きで実行された場合、 2netid1 で指定したトランスポート用のサーバを生成する。 2infile1 が指定されていない場合、 4rpcgen1 は標準入力から入力を受け付ける。

入力ファイルが 4rpcgen1 によって実際に処理される前に、C プリプロセッサ 4cc -E1 [4cc(1) を参照] が実行される。 4rpcgen1 は各タイプの出力ファイルに対して、 4rpcgen1 プログラマが使う特別なプリプロセッサシンボルを定義する。

4RPC_HDR1

ヘッダファイルにコンパイルする際に定義される。

4RPC_XDR1

XDR ルーチンにコンパイルする際に定義される。

4RPC_SVC1

サーバ側スタブにコンパイルする際に定義される。

4RPC_CLNT1

クライアント側スタブにコンパイルする際に定義される。

4RPC_TBL1

RPC ディスパッチテーブルにコンパイルする際に定義される。

`4%1' で始まる全ての行は、 4rpcgen1 に解釈されることなく、出力ファイルに直接そのまま渡される。

2infile1 で参照される全てのデータタイプに対して、 4rpcgen1 はデータタイプ名の前に 4xdr_1 を付けた名前のルーチンが存在することを仮定する。 このルーチンが RPC/XDR ライブラリにない場合、 そのルーチンを提供しなければならない。 未定義のデータタイプを提供することで XDR ルーチンをカスタマイズすることができる。

以下のオプションが使用可能である。

4-a1

クライアント側とサーバ側のサンプルコードを含む全てのファイルを生成する。

4-b1

SunOS4.1 スタイルの RPC コードを生成する。 昔のコードとの互換性のためにある。これがデフォルトである。

4-51

SysVr4 スタイルの RPC コードを生成する。 これは Svr4 システムのトランスポート独立 RPC (Transport Independent RPC) で使われる。 デフォルトでは rpcgen は、SunOS4.1 スタイルの RPC コードを生成する。

4-c1

コンパイルして XDR ルーチンを生成する。

4-C1

ANSI C のコードを生成する。 このオプションは C++ コンパイラでもコンパイルできるコードを生成する。 これがデフォルトである。

4-k1

K&R C のコードを生成する。デフォルトは ANSI C である。

4-D2name4[=2value4]1

シンボル 2name1 を定義する。 ソース中の 4#define1 ディレクティブと同じ。 2value1 が与えられていない場合、 2value1 は 411 と定義される。 このオプションは複数回指定してもよい。

4-h1

コンパイルして 4C1 言語のデータ定義 (ヘッダファイル) を生成する。 RPC ディスパッチテーブルをサポートするヘッダファイルを生成したい場合は、 4-T1 オプションを同時に指定すること。

4-I1

inetd から起動できるサービスを生成する。 デフォルトでは、4-s1 オプションで選択されるトランスポートを処理する、 静的サービスを生成する。 4-I1 を使うことで、サービスをどちらの方法でも起動できるようになる。

4-K2 secs1

デフォルトでは、4rpcgen で生成されたサービスは、 リクエストを処理した後 4120 秒待って終了する。 この待機時間は 4-K フラグを使って変更できる。 リクエストを処理した後すぐに終了するサーバを生成するには、 4-K0 を指定すること。 決して終了しないサーバを生成するには、 適切な引き数である 4-K-1 を指定すること。
サーバをモニタリングしている場合、ある種のポートモニタ、例えば 4listen(1M) のようなものは、サービスリクエストに応答して 常に新しいプロセスを生成する。 サーバがそのようなモニタとともに使われることが分かっている場合、 サーバは処理の完了後すぐに終了すべきである。 そのようなサーバを生成するためには、 4rpcgen を 4-K-1 オプション付きで使うべきである。

4-l1

コンパイルしてクライアント側スタブを生成する。

4-m1

コンパイルしてサーバ側スタブファイルを生成するが、 \(lqmain\(rq ルーチンは作成しない。 このオプションは、コールバックルーチンを作成する場合や、 初期化を行うために独自の \(lqmain\(rq ルーチンを記述する必要がある ユーザーにとって役に立つ。

4-n 2netid1

コンパイルして 2netid1 で指定したトランスポート用のサーバ側スタブを生成する。 netconfig データベースに 2netid1 用のエントリが存在する必要がある。 複数のトランスポートに対してサービスを行うサーバを作成するために、 このオプションを複数回指定することができる。

4-N1

新しいスタイルの rpcgen を使う。手続きが複数の引き数を持てるようにする。 これはまた、C 言語にとてもよく似たパラメータ渡しの方法を用いる。 これにより、遠隔手続きに引き数を渡す場合に、引き数へのポインタではなく 引き数そのものを渡すことができる。 この動作は、以前のスタイルの rpcgen が生成したコードによるものとは異なる。 以前のものとの互換性のため、新しいスタイルはデフォルトになっていない。

4-o 2outfile1

出力ファイル名を指定する。 何も指定されない場合、標準出力に書き出す (4-c1, 4-h1, 4-l1, 4-m1, 4-n1, 4-s1, 4-Sc1, 4-Ss1, 4-t1 モード時のみ)。

4-s 2nettype1

コンパイルして 2nettype1 クラスに属する全てのトランスポート用のサーバ側スタブを生成する。 サポートされているクラスは以下の通りである。 4netpath1, 4visible1, 4circuit_n1, 4circuit_v1, 4datagram_n1, 4datagram_v1, 4tcp1, 4udp1 [これらのクラスに関連づけられた意味については、 4rpc(3N) を参照すること]。 このオプションは複数回指定することができる。 注意: トランスポートはコンパイル時ではなく実行時に選択される。

4-Sc1

遠隔手続きの使用法と、rpcgen で生成されたクライアント側スタブを 呼び出す前にサーバをバインドする方法を説明するサンプルコードを生成する。

4-Ss1

サーバ側遠隔手続きの骨組みとなるコードを生成する。 遠隔手続きの実際のコードを記述する必要がある。

4-t1

コンパイルして RPC ディスパッチテーブルを生成する。

4-T1

RPC ディスパッチテーブルをサポートするコードを生成する。

オプション 4-c1, 4-h1, 4-l1, 4-m1, 4-s1, 4-t1 は、特定のタイプのファイルを生成するために、どれか 1 つを単独で使う。 一方、オプション 4-D1 と 4-T1 は、グローバルオプションで、他のオプションとともに使うことができる。

RPC 言語は構造体の入れ子構造をサポートしない。 対処法として 同様の効果を得るために、構造体をトップレベルで宣言し、 その構造体名を他の構造体の中で使うことができる。

明確な名前スコープが実際に適応されていないため、 プログラム定義の使用中に名前の衝突が起きる場合がある。 この問題の大部分は、プログラム・バージョン・手続き・タイプに対して 固有の名前を付けることで回避できる。

4-n1 オプションで生成されたサーバ用コードは、 2netid1 で指定されたトランスポートを参照するので、 非常にサイト依存したものになる。

以下の例:
$ rpcgen -T prot.x

は 5 つのファイル: 4prot.h1, 4prot_clnt.c1, 4prot_svc.c1, 4prot_xdr.c1, 4prot_tbl.i1 を生成する。

以下の例では、C 言語のデータ定義 (ヘッダファイル) が標準出力に送られる。
$ rpcgen -h prot.x

4datagram_n1 クラスに属する全トランスポート用のサーバ側スタブのテストバージョン 4-DTEST1 を標準出力に書き出すためには、以下のようにすること:
$ rpcgen -s datagram_n -DTEST prot.x

2netid1 4tcp1 で指定されたトランスポート用のサーバ側スタブを生成するためには、 以下のようにすること:
$ rpcgen -n tcp -o prot_svc.c prot.x

4cc(1)

この man ページの翻訳にあたり、 FreeBSD jpman project <http://www.jp.freebsd.org/man-jp/> による翻訳を参考にさせていただいた。