この章では、RPC との C インタフェースについて取り上げ、RPC を使用してネットワークアプリケーションを書く方法を説明します。RPC ライブラリにおけるルーチンの完全な仕様については、rpc(3NSL) のマニュアルページおよび関連するマニュアルページを参照してください。
この章で説明するクライアントおよびサーバーインタフェースは、特に注意書きがある場合 (raw モードなど) 以外は、マルチスレッド対応です。すなわち、RPC 関数を呼び出すアプリケーションはマルチスレッド環境で自由に実行することができます。
単純インタフェースでは、その他の RPC ルーチンは不要なため最も簡単に使用できます。しかし、利用できる通信メカニズムの制御は制限されます。このレベルでのプログラム開発は早く、rpcgen コンパイラによって直接サポートされます。大部分のアプリケーションに対しては、rpcgen が提供する機能で十分です。
RPC サービスの中には C の関数としては提供されていないものがありますが、それも RPC プログラムとして使用できます。単純インタフェースライブラリルーチンは、詳細な制御を必要としないプログラムでは RPC 機能を直接使用できます。rnusers() のようなルーチンは、RPC サービスライブラリ librpcsvc にあります。例 4-1 は、RPC ライブラリルーチン rnusers() を呼び出して、遠隔ホスト上のユーザー数を表示します。
#include <rpc/rpc.h>
#include <rpcsvc/rusers.h>
#include <stdio.h>
/*
* rnusers() サービスを
* 呼び出すプログラム
*/
main(argc, argv)
int argc;
char **argv;
{
int num;
if (argc != 2) {
fprintf(stderr, "usage: %s hostname¥n",
argv[0]);
exit(1);
}
if ((num = rnusers(argv[1])) < 0) {
fprintf(stderr, "error: rnusers¥n");
exit(1);
}
fprintf(stderr, "%d users on %s¥n", num,
argv[1] );
exit(0);
}
|
例 4-1 のプログラムを次のコマンドを使用してコンパイルします。
cc program.c -lrpcsvc -lnsl |
単純インタフェースのクライアント側には、rpc_call() という関数が 1 つだけあります。次の 9 個のパラメータがあります。
int 0 or error code
rpc_call (
char *host /* サーバーホストの名前 */
rpcprog_t prognum /* サーバープログラム番号 */
rpcvers_t versnum /* サーバーバージョン番号 */
rpcproc_t procnum /* サーバー手続き番号 */
xdrproc_t inproc /* 引数を符号化する XDR フィルタ */
char *in /* 引数へのポインタ */
xdr_proc_t outproc /* 結果を復号化するフィルタ */
char *out /* 結果を格納するアドレス */
char *nettype /* トランスポートの選択 */
);
|
この関数は、host 上で、prognum、versum、procnum によって指定する手続きを呼び出します。遠隔手続きに渡される引数は、in パラメータによって指定され、inproc はこの引数を符号化するための XDR フィルタです。out パラメータは、遠隔手続きから戻される結果が置かれるアドレスです。outproc は、結果を復号化してこのアドレスに置く XDR フィルタです。
クライアントプログラムは、サーバーから応答を得るまで rpc_call() のところで停止します。サーバーが呼び出しを受け入れると、0 の値で RPC_SUCCESS を返します。呼び出しが失敗した場合は、0 以外の値が返されます。この値は、clnt_stat で指定される型に型変換されます。これは RPC インクルードファイルの中で定義される列挙型で、clnt_sperrno() 関数により解釈されます。この関数は、このエラーコードに対応する標準 RPC エラーメッセージへのポインタを返します。
この例では、/etc/netconfig に列挙されているすべての選択可能な可視トランスポートが試されます。試行回数を指定するには、下位レベルの RPC ライブラリを使用する必要があります。
複数の引数と複数の結果は、構造体の中で処理されます。
単純インタフェースを使用するために例 4-1 を変更すると、例 4-2 のようになります。
#include <stdio.h>
#include <utmpx.h>
#include <rpc/rpc.h>
#include <rpcsvc/rusers.h>
/*
*RUSERSPROG RPC プログラムを呼び出すプログラム
*/
main(argc, argv)
int argc;
char **argv;
{
unsigned int nusers;
enum clnt_stat cs;
if (argc != 2) {
fprintf(stderr, "usage: rusers hostname¥n");
exit(1);
}
if( cs = rpc_call(argv[1], RUSERSPROG,
RUSERSVERS, RUSERSPROC_NUM, xdr_void,
(char *)0, xdr_u_int, (char *)&nusers,
"visible") != RPC_SUCCESS ) {
clnt_perrno(cs);
exit(1);
}
fprintf(stderr, "%d users on %s¥n", nusers,
argv[1] );
exit(0);
}
|
マシンが異なれば、データ型も異なる表現になるため、rpc_call() は RPC 引数の型と RPC 引数へのポインタを必要とします (サーバーから返される結果についても同様)。RUSERSPROC_NUM の場合、戻り値は unsigned int 型であるため、rpc_call() の最初の戻りパラメータは xdr_u_int (unsigned int 用) で、2 番目は &nusers (unsigned int 型の値があるメモリーへのポインタ) です。RUSERSPROC_NUM には引数がないため、rpc_call() の XDR 符号化関数は xdr_void() で、その引数は NULL です。
単純インタフェースを使用するサーバープログラムは、大変理解しやすいものです。これは単に、呼び出される手続きを登録するため rpc_reg() を呼び出し、次に、RPC ライブラリの遠隔手続きディスパッチャである svc_run() を呼び出して、入ってくる要求を待ちます。
rpc_reg() には次の引数があります。
rpc_reg (
rpcprog_t prognum /* サーバープログラム番号 */
rpcvers_t versnum /* サーバーバージョン番号 */
rpcproc_t procnum /* サーバー手続き番号 */
char *procname /* 遠隔関数の名前 */
xdrproc_t inproc /* 引数を符号化するフィルタ */
xdrproc_t outproc /* 結果を復号化するフィルタ */
char *nettype /* トランスポートの選択 */
);
|
svc_run() は RPC 呼び出しメッセージに応えてサービス手続きを起動します。rpc_reg() のディスパッチャは遠隔手続きが登録されたときに指定された XDR フィルタを使用して、遠隔手続きの引数の復号化と、結果の符号化を行います。サーバープログラムについての注意点をいくつか挙げます。
ほとんどの RPC アプリケーションが、関数名の後に _1 を付ける命名規則に従っています。手続き名に _n 番号を付けることにより、サービスのバージョン番号 n を表します。
引数と結果はアドレスで渡されます。遠隔で呼び出される関数はすべてこうなります。関数の結果として NULL を渡すと、クライアントには応答が送信されません。送信する応答がないと仮定されます。
結果は固定のデータ領域に存在します。これは、その値が実際の手続きが終了したあとにアクセスされるからです。RPC 応答メッセージを作成する RPC ライブラリ関数は結果にアクセスして、その値をクライアントに戻します。
引数は 1 つだけ使用できます。データに複数の要素がある場合、構造体の中に入れると、1 つの引数として渡すことができます。
手続きは、指定するタイプのトランスポートごとに登録されます。タイプのパラメータが (char *)NULL の場合、手続きは NETPATH により指定されるすべてのトランスポートに登録されます。
rpcgen は汎用のコードジェネレータであるため、ユーザーが自分で書いた方が、効率のよい短いコードにできる場合があります。そのような登録ルーチンの例を次に示します。次の例では、手続きを 1 つ登録してから、svc_run() に入ってサービス要求を待ちます。
#include <stdio.h>
#include <rpc/rpc.h>
#include <rpcsvc/rusers.h>
void *rusers();
main()
{
if(rpc_reg(RUSERSPROG, RUSERSVERS,
RUSERSPROC_NUM, rusers,
xdr_void, xdr_u_int,
"visible") == -1) {
fprintf(stderr, "Couldn't Register¥n");
exit(1);
}
svc_run(); /* この関数は値を戻さない */
fprintf(stderr, "Error: svc_run
returned!¥n");
exit(1);
}
|
rpc_reg() は、異なるプログラム、バージョン、手続きを登録するごとに何度でも呼び出すことができます。
遠隔手続きへ渡すデータ型と遠隔手続きから受け取るデータ型は、事前に定義した型あるいはプログラマが定義する型の任意のものが可能です。RPC では、データを XDR (external data representation: 外部データ表現) 形式という標準データ形式に変換してからトランスポートに送信するため、個々のマシンに固有のバイト順序や構造体のデータレイアウトに関係なく、任意のデータ構造を扱うことができます。マシン固有のデータ形式から XDR 形式に変換することをシリアライズといい、反対に XDR 形式からマシン固有のデータ形式に変換することをデシリアライズといいます。
rpc_call() と rpc_reg() の引数で変換ルーチンを指定するときは、 xdr_u_int() のような XDR プリミティブを指定することも、引数として渡された構造体全体を処理するようなユーザーが作成した変換ルーチンを指定することもできます。引数の変換ルーチンは 2 つの引数を取ります。1 つは変換結果へのポインタで、もう 1 つは XDR ハンドルへのポインタです。
表 4-1 XDR プリミティブタイプのルーチン|
XDR プリミティブ・ルーチン |
|||
|---|---|---|---|
|
xdr_hyper() |
xdr_u_hyper() |
|
|
int_types.h 内にある固定幅の整数タイプに慣れている ANSI C プログラマにとって都合がよいように、ルーチン xdr_char()、xdr_short()、xdr_int()、xdr_hyper() (および、それぞれの符号なしバージョン) には、表 4-2 で示すように、ANSI C を連想させる名前の付いた同等の関数があります。
表 4-2 プリミティブタイプの等価関数|
関数 |
Equivalent |
|---|---|
|
xdr_char() |
xdr_int8_t() |
|
xdr_u_char() |
xdr_u_int8_t() |
|
xdr_short() |
xdr_int16_t() |
|
xdr_u_short() |
xdr_u_int16_t() |
|
xdr_int() |
xdr_int32_t() |
|
xdr_u_int() |
xdr_u_int32_t() |
|
xdr_hyper() |
xdr_int64_t() |
|
xdr_u_hyper() |
xdr_u_int64_t() |
xdr_wrapstring() から呼び出す xdr_string() はプリミティブではなく、3 つ以上の引数を取ります。
ユーザーが作成する変換ルーチンの例を次に示します。手続きに渡す引数は次の構造体に入れます。
struct simple {
int a;
short b;
} simple;
|
この構造体で渡された引数を変換する XDR ルーチン xdr_simple() は、例 4-3 に示すようになります。
#include <rpc/rpc.h>
#include "simple.h"
bool_t
xdr_simple(xdrsp, simplep)
XDR *xdrsp;
struct simple *simplep;
{
if (!xdr_int(xdrsp, &simplep->a))
return (FALSE);
if (!xdr_short(xdrsp, &simplep->b))
return (FALSE);
return (TRUE);
}
|
rpcgen でも、同じ機能を持つ変換ルーチンを自動生成できます。
XDR ルーチンは、データ変換に成功した場合はゼロ以外の値 (C では TRUE) を返し、失敗した場合はゼロを返します。XDR についての詳細は、付録 C 「XDR プロトコル仕様」 を参照してください。
表 4-3 XDR ブロック構築ルーティン| 基本のルーチン | ||
|---|---|---|
|
xdr_array() |
xdr_bytes() |
xdr_reference() |
|
xdr_vector() |
xdr_union() |
xdr_pointer() |
|
xdr_string() |
xdr_opaque() |
|
たとえば、可変長の整数配列を送るときは、配列へのポインタと配列サイズを次のような構造体にパックします。
struct varintarr {
int *data;
int arrlnth;
} arr;
|
この配列を変換するルーチン xdr_varintarr() は 例 4-4 に示すようになります。
bool_t
xdr_varintarr(xdrsp, arrp)
XDR *xdrsp;
struct varintarr *arrp;
{
return(xdr_array(xdrsp, (caddr_t)&arrp->data,
(u_int *)&arrp->arrlnth, MAXLEN,
sizeof(int), xdr_int));
}
|
xdr_array() に渡す引数は、XDR ハンドル、配列へのポインタ、配列サイズへのポインタ、配列サイズの最大値、配列要素のサイズ、配列要素を変換する XDR ルーチンへのポインタです。配列サイズが前もってわかっている場合は、例 4-5 のように xdr_vector() を使用します。
int intarr[SIZE];
bool_t
xdr_intarr(xdrsp, intarr)
XDR *xdrsp;
int intarr[];
{
return (xdr_vector(xdrsp, intarr, SIZE,
sizeof(int),
xdr_int));
}
|
XDR ルーチンでシリアライズすると、データが 4 バイトの倍数になるように変換されます。たとえば、文字配列を変換すると、各文字が 32 ビットを占有するようになります。xdr_bytes() は、文字をパックするルーチンで、xdr_array() の最初の 4 つの引数と同様の引数を取ります。
NULL で終わる文字列は xdr_string() で変換します。このルーチンは、長さの引数がない xdr_bytes() ルーチンのようなものです。文字列をシリアライズするときは strlen() で長さを取り出し、デシリアライズするときは NULL で終わる文字列を生成します。
例 4-6 では、組み込み関数 xdr_string() と xdr_reference() を呼び出して、文字列へのポインタと、前の例で示した構造体 simple へのポインタを変換します。
struct finalexample {
char *string;
struct simple *simplep;
} finalexample;
bool_t
xdr_finalexample(xdrsp, finalp)
XDR *xdrsp;
struct finalexample *finalp;
{
if (!xdr_string(xdrsp, &finalp->string,
MAXSTRLEN))
return (FALSE);
if (!xdr_reference( xdrsp, &finalp->simplep,
sizeof(struct simple), xdr_simple))
return (FALSE);
return (TRUE);
}
|
ここで、xdr_reference() の代わりに xdr_simple() を呼び出してもよいことに注意してください。
RPC パッケージの標準レベルへのインタフェースは、RPC 通信へのさらに詳細な制御を提供します。この制御を使用するプログラムはより複雑になります。下位レベルでの効果的なプログラミングには、コンピュータネットワークの構造に対するより深い知識が必要です。トップ、中間、エキスパート、ボトムレベルは、標準インタフェースの一部です。
この節では、RPC ライブラリの下位レベルを使用して RPC プログラムを詳細に制御する方法について説明します。たとえば、単純インタフェースレベルでは NETPATH を介してしか使用できなかったトランスポートプロトコルを自由に使用できます。これらのルーチンを使用するには、TLI に対する知識が必要です。
表 4-4 に示したルーチンにはトランスポートハンドルの指定が必要なため、単純インタフェースからは使用できません。たとえば、単純レベルでは、XDR ルーチンでシリアライズとデシリアライズを行うときに、メモリーの割り当てと解放を行うことはできません。
表 4-4 トランスポートハンドルの指定が必要な XDR ルーチン|
単純インタフェースでは使用できないルーチン |
||
|---|---|---|
|
clnt_call() |
clnt_destroy() |
clnt_control() |
|
clnt_perrno() |
clnt_pcreateerror() |
clnt_perror() |
|
svc_destroy() |
|
|
トップレベルのルーチンを使用すると、アプリケーションで使用するトランスポートタイプを指定できますが、特定のトランスポートは指定できません。このレベルは、クライアントとサーバーの両方でアプリケーションが自分のトランスポートハンドルを作成する点で、単純インタフェースと異なります。
例 4-7 に示すようなヘッダーファイルがあるとします。
/* time_prot.h */
#include <rpc/rpc.h>
#include <rpc/types.h>
struct timev {
int second;
int minute;
int hour;
};
typedef struct timev timev;
bool_t xdr_timev();
#define TIME_PROG 0x40000001
#define TIME_VERS 1
#define TIME_GET 1
|
例 4-8 に、クライアント側の、トップレベルのサービスルーチンを使用する簡単な日時表示プログラムを示します。このプログラムでは、時刻を返すサービスを呼び出します。トランスポートタイプはプログラムを起動するときの引数で指定します。
#include <stdio.h>
#include "time_prot.h"
#define TOTAL (30)
/*
* 時刻を返すサービスを呼び出すプログラム
* 使用方法: calltime ホスト名
*/
main(argc, argv)
int argc;
char *argv[];
{
struct timeval time_out;
CLIENT *client;
enum clnt_stat stat;
struct timev timev;
char *nettype;
if (argc != 2 && argc != 3) {
fprintf(stderr,"usage:%s host[nettype]¥n"
,argv[0]);
exit(1);
}
if (argc == 2)
nettype = "netpath"; /* デフォルト */
else
nettype = argv[2];
client = clnt_create(argv[1], TIME_PROG,
TIME_VERS, nettype);
if (client == (CLIENT *) NULL) {
clnt_pcreateerror("Couldn't create client");
exit(1);
}
time_out.tv_sec = TOTAL;
time_out.tv_usec = 0;
stat = clnt_call( client, TIME_GET,
xdr_void, (caddr_t)NULL,
xdr_timev, (caddr_t)&timev,
time_out);
if (stat != RPC_SUCCESS) {
clnt_perror(client, "Call failed");
exit(1);
}
fprintf(stderr,"%s: %02d:%02d:%02d GMT¥n",
nettype timev.hour, timev.minute,
timev.second);
(void) clnt_destroy(client);
exit(0);
}
|
プログラムを起動するときに nettype を指定しなかった場合は、代わりに 「netpath」という文字列が使用されます。RPC ライブラリルーチンは、この文字列を見つけると、環境変数 NETPATH 値によって使用するトランスポートを決めます。
クライアントハンドルが作成できない場合は、clnt_pcreateerror() でエラー原因を表示するか、グローバル変数 rpc_createerr の値としてエラーステータスを取り出します。
クライアントハンドルが作成できたら、clnt_call() を使用して遠隔呼び出しを行います。clnt_call() の引数は、クライアントハンドル、遠隔手続き番号、入力引数に対する XDR フィルタ、引数へのポインタ、戻り値に対する XDR フィルタ、戻り値へのポインタ、呼び出しのタイムアウト値です。この例では、遠隔手続きに渡す引数はないので、XDR ルーチンとしては xdr_void() を指定しています。最後に clnt_destroy() を使用して使用済みメモリーを解放します。
上記の例でプログラマがクライアントハンドル作成に許される時間を 30 秒に設定したいとすると、次のコード例の一部のように、clnt_create() への呼び出しは clnt_create_timed() への呼び出しに替わります。
struct timeval timeout; timeout.tv_sec = 30; /* 30 秒 */ timeout.tv_usec = 0; client = clnt_create_timed(argv[1], TIME_PROG, TIME_VERS, nettype, &timeout); |
例 4-9 には、トップレベルのサービスルーチンを使用したサーバー側プログラムを示します。このプログラムでは、時刻を返すサービスを実行します。
#include <stdio.h>
#include <rpc/rpc.h>
#include "time_prot.h"
static void time_prog();
main(argc,argv)
int argc;
char *argv[];
{
int transpnum;
char *nettype;
if (argc > 2) {
fprintf(stderr, "usage: %s [nettype]¥n",
argv[0]);
exit(1);
}
if (argc == 2)
nettype = argv[1];
else
nettype = "netpath"; /* デフォルト */
transpnum =
svc_create(time_prog,TIME_PROG,TIME_VERS,nettype);
if (transpnum == 0) {
fprintf(stderr,"%s: cannot create %s service.¥n",
argv[0], nettype);
exit(1);
}
svc_run();
}
/*
* サーバーのディスパッチ関数
*/
static void
time_prog(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
struct timev rslt;
time_t thetime;
switch(rqstp->rq_proc) {
case NULLPROC:
svc_sendreply(transp, xdr_void, NULL);
return;
case TIME_GET:
break;
default:
svcerr_noproc(transp);
return;
}
thetime = time((time_t *) 0);
rslt.second = thetime % 60;
thetime /= 60;
rslt.minute = thetime % 60;
thetime /= 60;
rslt.hour = thetime % 24;
if (!svc_sendreply( transp, xdr_timev, &rslt)) {
svcerr_systemerr(transp);
}
}
|
svc_create() は、サーバーハンドルを作成したトランスポートの個数を返します。サービス関数 time_prog() は、対応するプログラム番号とバージョン番号を指定したサービス要求がきたときに svc_run() に呼び出されます。サーバーは、svc_sendreply() を使用して戻り値をクライアントに返します。
rpcgen を使用してディスパッチ関数を生成する場合は、svc_sendreply() は手続きが戻り値を返してから呼び出されるため、戻り値 (この例では rslt) は実際の手続き内で static 宣言しなければなりません。この例では、svc_sendreply() はディスパッチ関数の中で呼び出されているので、rslt は static で宣言されていません。
この例の遠隔手続きには引数がありませんが、引数を渡す必要がある場合は次の 2 つの関数を呼び出して、引数を取り出し、デシリアライズ (XDR 形式から復号化) し、解放します。
svc_getargs( SVCXPRT_handle, XDR_filter, argument_pointer); svc_freeargs( SVCXPRT_handle, XDR_filter argument_pointer ); |
中間レベルのルーチンを使用するときは、使用するトランスポート自体をアプリケーションから直接選択します。
例 4-10 は、「トップレベルのインタフェース」の時刻サービスのクライアント側プログラムを、中間レベルの RPC で書いたものです。この例のプログラムを実行するときは、どのトランスポートで呼び出しを行うか、コマンド行で指定する必要があります。
#include <stdio.h>
#include <rpc/rpc.h>
#include <netconfig.h> /* 構造体 netconfig を使用するため */
#include "time_prot.h"
#define TOTAL (30)
main(argc,argv)
int argc;
char *argv[];
{
CLIENT *client;
struct netconfig *nconf;
char *netid;
/* 以前のサンプルプログラムの宣言と同じ */
if (argc != 3) {
fprintf(stderr, "usage: %s host netid¥n",
argv[0]);
exit(1);
}
netid = argv[2];
if ((nconf = getnetconfigent( netid)) ==
(struct netconfig *) NULL) {
fprintf(stderr, "Bad netid type: %s¥n",
netid);
exit(1);
}
client = clnt_tp_create(argv[1], TIME_PROG,
TIME_VERS, nconf);
if (client == (CLIENT *) NULL) {
clnt_pcreateerror("Could not create client");
exit(1);
}
freenetconfigent(nconf);
/* これ以降は以前のサンプルプログラムと同じ */
}
|
この例では、getnetconfigent(netid) を呼び出して netconfig 構造体を取り出しています 。詳細については、getnetconfig(3NSL) のマニュアルページと『Transport Interfaces Programming Guide』を参照してください。このレベルの RPC を使用する場合は、プログラムで直接ネットワーク (トランスポート) を選択できます
上記の例でプログラマがクライアントハンドル作成に許される時間を 30 秒に設定したいとすると、次のコード例の一部のように、 clnt_tp_create() への呼び出しは clnt_tp_create_timed() への呼び出しに替わります。
struct timeval timeout; timeout.tv_sec = 30; /* 30 秒 */ timeout.tv_usec = 0; client = clnt_tp_create_timed(argv[1], TIME_PROG, TIME_VERS, nconf, &timeout); |
これに対するサーバー側プログラムを 例 4-11 に示します。サービスを起動するコマンド行では、どのトランスポート上でサービスを提供するかを指定する必要があります。
/*
* このプログラムは、サービスを呼び出したクライアントにグリニッチ標準時を
* 返します。呼び出し方法: server netid
*/
#include <stdio.h>
#include <rpc/rpc.h>
#include <netconfig.h> /* 構造体 netconfig を使用するため */
#include "time_prot.h"
static void time_prog();
main(argc, argv)
int argc;
char *argv[];
{
SVCXPRT *transp;
struct netconfig *nconf;
if (argc != 2) {
fprintf(stderr, "usage: %s netid¥n",
argv[0]);
exit(1);
}
if ((nconf = getnetconfigent( argv[1])) ==
(struct netconfig *) NULL) {
fprintf(stderr, "Could not find info on %s¥n",
argv[1]);
exit(1);
}
transp = svc_tp_create(time_prog, TIME_PROG,
TIME_VERS, nconf);
if (transp == (SVCXPRT *) NULL) {
fprintf(stderr, "%s: cannot create
%s service¥n", argv[0], argv[1]);
exit(1)
}
freenetconfigent(nconf);
svc_run();
}
static
void time_prog(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
/* トップレベルの RPC を使用したコードと同じ */
|
エキスパートレベルのネットワーク選択は、中間レベルと同じです。中間レベルとの唯一の違いは、アプリケーションから CLIENT と SVCXPRT のハンドルをより詳細に制御できる点です。次の例では、clnt_tli_create() と svc_tli_create() の 2 つのルーチンを使用した制御方法を示します。TLI についての詳細は、『Transport Interfaces Programming Guide』を参照してください。
例 4-12 には、clnt_tli_create() を使用して UDP トランスポートに対するクライアントを作成するルーチン clntudp_create() を示します。このプログラムでは、指定したトランスポートファミリに基づいたネットワークの選択方法を示します。clnt_tli_create() には、クライアントハンドルの作成のほかに次の 3 つの機能があります。
#include <stdio.h>
#include <rpc/rpc.h>
#include <netconfig.h>
#include <netinet/in.h>
/*
* 旧バージョンの RPC では、TCP/IP と UDP/IP だけがサポートされていました。
* 現バージョンの clntudp_create() は TLI/STREAMS に基づいています。
*/
CLIENT *
clntudp_create(raddr, prog, vers, wait, sockp)
struct sockaddr_in *raddr; /* 遠隔アドレス */
rpcprog_t prog; /* プログラム番号 */
prcvers_t vers; /* バージョン番号 */
struct timeval wait; /* 待ち時間 */
int *sockp; /* ファイル記述子 (fd) のポインタ */
{
CLIENT *cl; /* クライアントハンドル */
int madefd = FALSE; /* fd はオープンされているか */
int fd = *sockp; /* TLI の fd */
struct t_bind *tbind; /* 結合アドレス */
struct netconfig *nconf; /* netconfig 構造体 */
void *handlep;
if ((handlep = setnetconfig() ) == (void *) NULL) {
/* ネットワーク設定開始でのエラー */
rpc_createerr.cf_stat = RPC_UNKNOWNPROTO;
return((CLIENT *) NULL);
}
/*
* 非接続型で、プロトコルファミリが INET、名前が UDP の
* トランスポートが見つかるまで探す。
*/
while (nconf = getnetconfig( handlep)) {
if ((nconf->nc_semantics == NC_TPI_CLTS) &&
(strcmp( nconf->nc_protofmly, NC_INET ) == 0) &&
(strcmp( nconf->nc_proto, NC_UDP ) == 0))
break;
}
if (nconf == (struct netconfig *) NULL)
rpc_createerr.cf_stat = RPC_UNKNOWNPROTO;
goto err;
}
if (fd == RPC_ANYFD) {
fd = t_open(nconf->nc_device, O_RDWR, &tinfo);
if (fd == -1) {
rpc_createerr.cf_stat = RPC_SYSTEMERROR;
goto err;
}
}
if (raddr->sin_port == 0) { /* 未知の遠隔アドレス */
u_short sport;
/*
* ユーザー作成のルーチン rpcb_getport() は rpcb_getaddr を呼び出して、
* netbuf アドレスをホストのバイト順序に従ってポート番号に変換する
*/
sport = rpcb_getport(raddr, prog, vers, nconf);
if (sport == 0) {
rpc_createerr.cf_stat = RPC_PROGUNAVAIL;
goto err;
}
raddr->sin_port = htons(sport);
}
/* sockaddr_in を netbuf に変換 */
tbind = (struct t_bind *) t_alloc(fd, T_BIND, T_ADDR);
if (tbind == (struct t_bind *) NULL)
rpc_createerr.cf_stat = RPC_SYSTEMERROR;
goto err;
}
if (t_bind->addr.maxlen < sizeof( struct sockaddr_in))
goto err;
(void) memcpy( tbind->addr.buf, (char *)raddr,
sizeof(struct sockaddr_in));
tbind->addr.len = sizeof(struct sockaddr_in);
/* fd を結合 */
if (t_bind( fd, NULL, NULL) == -1) {
rpc_createerr.ct_stat = RPC_TLIERROR;
goto err;
}
cl = clnt_tli_create(fd, nconf, &(tbind->addr), prog, vers,
tinfo.tsdu, tinfo.tsdu);
/* netconfig ファイルを閉じる */
(void) endnetconfig( handlep);
(void) t_free((char *) tbind, T_BIND);
if (cl) {
*sockp = fd;
if (madefd == TRUE) {
/* fd はハンドルの破棄と同時に閉じる */
(void)clnt_control(cl,CLSET_FD_CLOSE, (char *)NULL);
}
/* リトライ時間の設定 */
(void) clnt_control( l, CLSET_RETRY_TIMEOUT,
(char *) &wait);
return(cl);
}
err:
if (madefd == TRUE)
(void) t_close(fd);
(void) endnetconfig(handlep);
return((CLIENT *) NULL);
}
|
ネットワーク (トランスポート) 選択には、setnetconfig()、getnetconfig()、endnetconfig() を使用します。
endnetconfig() の呼び出しは、プログラムの終り近くの clnt_tli_create() の呼び出しの後で行なっていることに注意してください。
clntudp_create() には、オープンしている TLI ファイル記述子を渡すことができます。ファイル記述子が渡されなかった場合 (fd == RPC_ANYFD) は、t_open() に渡すデバイス名を UDP の netconfig 構造体から取り出して自分でオープンします。
遠隔アドレスがわからない場合 (raddr->sin_port == 0) は、遠隔の rpcbind デーモンを使って取り出します。
クライアントハンドルが作成されれば、clnt_control() を使用してさまざまな変更を加えることができます。RPC ライブラリはハンドルを破棄するときにファイル記述子を閉じ (fd をライブラリ内でオープンしたときは、clnt_destroy() の呼び出しにより閉じられる)、リトライのタイムアウト値を設定します。
例 4-13 には、これに対するサーバー側プログラム svcudp_create() を示します。サーバー側では svc_tli_create() を使用します。
svc_tli_create() は、アプリケーションで次のように詳細な制御を行う必要があるときに使用します。
送信バッファと受信バッファのサイズを指定します。引数 fd は、渡された時に結合されていないことがあります。その場合、fd は指定されたアドレスに結合され、そのアドレスがハンドルに格納されます。結合されたアドレスが NULL に設定されていて、fd が最初から結合されていない場合、任意の最適なアドレスへ結合されます。
サービスを rpcbind により登録するには、rpcb_set() を使用します。
#include <stdio.h>
#include <rpc/rpc.h>
#include <netconfig.h>
#include <netinet/in.h>
SVCXPRT *
svcudp_create(fd)
register int fd;
{
struct netconfig *nconf;
SVCXPRT *svc;
int madefd = FALSE;
int port;
void *handlep;
struct t_info tinfo;
/* どのトランスポートも使用不可の場合 */
if ((handlep = setnetconfig() ) == (void *) NULL) {
nc_perror("server");
return((SVCXPRT *) NULL);
}
/*
* 非接続型で、プロトコルファミリが INET、名前が UDP の
* トランスポートが見つかるまで探す。
*/
while (nconf = getnetconfig( handlep)) {
if ((nconf->nc_semantics == NC_TPI_CLTS) &&
(strcmp( nconf->nc_protofmly, NC_INET) == 0 )&&
(strcmp( nconf->nc_proto, NC_UDP) == 0 ))
break;
}
if (nconf == (struct netconfig *) NULL) {
endnetconfig(handlep);
return((SVCXPRT *) NULL);
}
if (fd == RPC_ANYFD) {
fd = t_open(nconf->nc_device, O_RDWR, &tinfo);
if (fd == -1) {
(void) endnetconfig();
return((SVCXPRT *) NULL);
}
madefd = TRUE;
} else
t_getinfo(fd, &tinfo);
svc = svc_tli_create(fd, nconf, (struct t_bind *) NULL,
tinfo.tsdu, tinfo.tsdu);
(void) endnetconfig(handlep);
if (svc == (SVCXPRT *) NULL) {
if (madefd)
(void) t_close(fd);
return((SVCXPRT *)NULL);
}
return (svc);
}
|
この例では、clntudp_create() と同じ方法でネットワーク選択を行なっています。svc_tli_create() で結合しているため、ファイル記述子は明示的にはトランスポートアドレスと結合されません。
svcudp_create() はオープンしている fd を使用できます。有効な fd が渡されなければ、選択された netconfig 構造体を使用してこのルーチン内でオープンします。
アプリケーションで RPC のボトムレベルインタフェースを使用すると、すべてのオプションを使用して通信を制御できます。clnt_tli_create() などのエキスパートレベルの RPC インタフェースは、ボトムレベルのルーチンを使用しています。ユーザーがこのレベルのルーチンを直接使用することはほとんどありません。
ボトムレベルのルーチンは内部データ構造を作成し、バッファを管理し、RPC ヘッダーを作成します。ボトムレベルルーチンの呼び出し側 (たとえば、clnt_tli_create()) では、クライアントハンドルの cl_netid と cl_tp の両フィールドを初期化する必要があります。作成したハンドルの cl_netid にはトランスポートのネットワーク ID (たとえば udp) を設定し、cl_tp にはトランスポートのデバイス名 (たとえば /dev/udp) を設定します。clnt_dg_create() と clnt_vc_create() のルーチンは、clnt_ops と cl_private のフィールドを設定します。
例 4-14 は、clnt_vc_create() と clnt_dg_create() の呼び出し方法を示します。
/*
* 使用する変数 :
* cl: CLIENT *
* tinfo: struct t_info (t_open() または t_getinfo() からの戻り値)
* svcaddr: struct netbuf *
*/
switch(tinfo.servtype) {
case T_COTS:
case T_COTS_ORD:
cl = clnt_vc_create(fd, svcaddr,
prog, vers, sendsz, recvsz);
break;
case T_CLTS:
cl = clnt_dg_create(fd, svcaddr,
prog, vers, sendsz, recvsz);
break;
default:
goto err;
}
|
これらのルーチンを使用するときは、ファイル記述子がオープンされて結合されている必要があります。svcaddr はサーバーのアドレスです。
サーバー側は 例 4-15 のようになります。
/*
* 使用する変数
* xprt: SVCXPRT *
*/
switch(tinfo.servtype) {
case T_COTS_ORD:
case T_COTS:
xprt = svc_vc_create(fd, sendsz, recvsz);
break;
case T_CLTS:
xprt = svc_dg_create(fd, sendsz, recvsz);
break;
default:
goto err;
}
|
svc_dg_enablecache() はデータグラムトランスポートのキャッシュを開始します。キャッシュは、サーバー手続きが「一度だけ」行われるバージョンにのみ、使用されるべきです。これは、キャッシュされたサーバー手続きを何回も実行すると、異なる別の結果を生じるためです。
svc_dg_enablecache(xprt, cache_size)
SVCXPRT *xprt;
unsigned int cache_size;
|
この関数は、cache_size エントリを保持するために十分な大きさで、サービスのエンドポイント xprt に、重複要求キャッシュを割り当てます。サービスに、異なる戻り値を返す手続きが含まれる場合は、重複要求キャッシュが必要です。キャッシュをいったん有効にすると、後で無効にする方法はありません。
次のデータ構造は参考のために示しますが、変更される可能性があります。
最初に示すのは、クライアント側の RPC ハンドルで、<rpc/clnt.h> で定義されています。下位レベルの RPC を使用する場合は、例 4-16 に示したように接続ごとに 1 つのハンドルを作成して初期化する必要があります。
typedef struct {
AUTH *cl_auth; /* 認証情報 */
struct clnt_ops {
enum clnt_stat (*cl_call)(); /* 遠隔手続き呼び出し */
void (*cl_abort)(); /* 呼び出しの中止 */
void (*cl_geterr)(); /* 特定エラーコードの取得 */
bool_t (*cl_freeres)(); /* 戻り値の解放*/
void (*cl_destroy)(); /* この構造体の破棄 */
bool_t (*cl_control)(); /* RPC の ioctl() */
} *cl_ops;
caddrt_t cl_private; /* プライベートに使用 */
char *cl_netid; /* ネットワークトークン */
char *cl_tp; /* デバイス名 */
} CLIENT;
|
クライアント側ハンドルの第 1 フィールドは、 <rpc/auth.h> で定義された認証情報の構造体です。このフィールドはデフォルトで AUTH_NONE に設定されているため、例 4-17に示すように、必要に応じてクライアント側プログラムで cl_auth を初期化する必要があります。
typedef struct {
struct opaque_auth ah_cred;
struct opaque_auth ah_verf;
union des_block ah_key;
struct auth_ops {
void (*ah_nextverf)();
int (*ah_marshal)(); /* nextverf とシリアライズ */
int (*ah_validate)(); /* 妥当性検査の確認 */
int (*ah_refresh)(); /* 資格のリフレッシュ */
void (*ah_destroy)(); /* この構造体の破棄 */
} *ah_ops;
caddr_t ah_private;
} AUTH;
|
AUTH 構造体の ah_cred には呼び出し側の資格が、ah_verf には資格を確認するためのデータが入っています。詳細については、「認証」 を参照してください。
例 4-18 には、サーバー側のトランスポートハンドルを示します。
typedef struct {
int xp_fd;
#define xp_sock xp_fd
u_short xp_port; /* 結合されたポート番号、旧形式 */
struct xp_ops {
bool_t (*xp_recv)(); /* 要求の受信 */
enum xprt_stat (*xp_stat)(); /* トランスポートステータスの取得 */
bool_t (*xp_getargs)(); /* 引数の取り出し */
bool_t (*xp_reply)(); /* 応答の送信 */
bool_t (*xp_freeargs)(); /* 引数に割り当てたメモリーの解放* */
void (*xp_destroy)(); /* この構造体の破棄 */
} *xp_ops;
int xp_addrlen; /* 遠隔アドレスの長さ、旧形式 */
char *xp_tp; /* トランスポートプロバイダのデバイス名 */
char *xp_netid; /* ネットワークトークン */
struct netbuf xp_ltaddr; /* ローカルトランスポートアドレス */
struct netbuf xp_rtaddr; /* 遠隔トランスポートアドレス */
char xp_raddr[16]; /* 遠隔アドレス、旧形式 */
struct opaque_auth xp_verf; /* raw 応答の確認 */
caddr_t xp_p1; /* プライベート: svc ops で使用 */
caddr_t xp_p2; /* プライベート: svc ops で使用 */
caddr_t xp_p3; /* プライベート: svc lib で使用 */
} SVCXPRT;
|
表 4-5 は、サーバー側のトランスポートハンドルに対応するフィールドを示します。
表 4-5 RPC サーバー側のトランスポートハンドル|
ハンドルに結合したファイル記述子。複数のサーバーハンドルで 1 つのファイル記述子を共有できる |
|
|
トランスポートのネットワーク ID (たとえば、udp)。ハンドルはこのトランスポート上に作成される。xp_tp は、このトランスポートに結合したデバイス名 |
|
|
サーバー自身の結合アドレス |
|
|
RPC の呼び出し側アドレス (したがって、呼び出しのたびに変る) |
|
|
svc_tli_create() のようなエキスパートレベルのルーチンで初期化される |
その他のフィールドは、ボトムレベルのサーバールーチン svc_dg_create() と svc_vc_create() で初期化されます。
接続型端点では、表 4-6 の各フィールドには、接続要求がサーバーに受け入れられるまで正しい値が入りません。
表 4-6 RPC 接続型端点|
接続が確立するまでは無効なフィールド |
||
|---|---|---|
|
xp_fd |
xp_ops() |
xp_p1() |
|
xp_p2 |
xp_verf() |
xp_tp() |
|
xp_ltaddr |
xp_rtaddr() |
xp_netid() |
デバッグツールとして、ネットワーク機能をすべてバイパスする 2 つの擬似 RPC インタフェースがあります。ルーチン clnt_raw_create() と svc_raw_create() は、実際のトランスポートを使用しません。
製品システムで RAW モードは使用しないでください。RAW モードは、デバッグを行い易くするために使用します。RAW モードはマルチスレッド対応ではありません。
例 4-19 は、次の Makefile を使用してコンパイルとリンクを行います。
all: raw CFLAGS += -g raw: raw.o cc -g -o raw raw.o -lnsl
/*
* 数値を 1 増加させる簡単なプログラム
*/
#include <stdio.h>
#include <rpc/rpc.h>
#include <rpc/raw.h>
#define prognum 0x40000001
#define versnum 1
#define INCR 1
struct timeval TIMEOUT = {0, 0};
static void server();
main (argc, argv)
int argc;
char **argv;
{
CLIENT *cl;
SVCXPRT *svc;
int num = 0, ans;
int flag;
if (argc == 2)
num = atoi(argv[1]);
svc = svc_raw_create();
if (svc == (SVCXPRT *) NULL) {
fprintf(stderr, "Could not create server handle¥n");
exit(1);
}
flag = svc_reg( svc, prognum, versnum, server,
(struct netconfig *) NULL );
if (flag == 0) {
fprintf(stderr, "Error: svc_reg failed.¥n");
exit(1);
}
cl = clnt_raw_create( prognum, versnum );
if (cl == (CLIENT *) NULL) {
clnt_pcreateerror("Error: clnt_raw_create");
exit(1);
}
if (clnt_call(cl, INCR, xdr_int, (caddr_t) &num, xdr_int,
(caddr_t) &ans, TIMEOUT)
!= RPC_SUCCESS) {
clnt_perror(cl, "Error: client_call with raw");
exit(1);
}
printf("Client: number returned %d¥n", ans);
exit(0);
}
static void
server(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
int num;
fprintf(stderr, "Entering server procedure.¥n");
switch(rqstp->rq_proc) {
case NULLPROC:
if (svc_sendreply( transp, xdr_void,
(caddr_t) NULL) == FALSE) {
fprintf(stderr, "error in null proc¥n");
exit(1);
}
return;
case INCR:
break;
default:
svcerr_noproc(transp);
return;
}
if (!svc_getargs( transp, xdr_int, &num)) {
svcerr_decode(transp);
return;
}
fprintf(stderr, "Server procedure: about to increment.¥n");
num++;
if (svc_sendreply(transp, xdr_int, &num) == FALSE) {
fprintf(stderr, "error in sending answer¥n");
exit (1);
}
fprintf(stderr, "Leaving server procedure.¥n");
}
|
次の点に注意してください。
サーバーはクライアントより先に作成しなければなりません。
svc_raw_create() には引数がありません。
サーバーは rpcbind デーモンに登録されません。svc_reg() の最後の引数は (struct netconfig *) NULL ですので、rpcbind デーモンに登録されないことがわかります。
svc_run() が呼び出されません。
RPC 呼び出しはすべて同一の制御スレッド内で行われます。
この節では、RPC の下位レベルインタフェースを使用するさまざまな開発テクニックを説明します。この章で説明する項目を次に示します。
サーバー上の poll() - サーバー上で svc_run() が呼び出せない場合に、サーバーから直接ディスパッチャを呼び出す方法
ブロードキャスト RPC - ブロードキャストの使用方法
バッチ処理 - 一連の呼び出しをバッチ処理にして、パフォーマンスを向上させる方法
認証 - 今回のリリースで使用される認証方法
ポートモニタの使用 - ポートモニタ inetd と listener のインタフェース
複数のプログラムのバージョン - 複数のプログラムバージョンのサービス方法
この節で説明する内容は、(デフォルトの) シングルスレッドのモードで RPC を実行する場合にだけ適用されます。
RPC 要求をサービスしたり、その他のアクティビティを実行したりするプロセスでは、svc_run() を呼び出せない場合があります。他のアクティビティで定期的にデータ構造を更新する場合は、プロセスから svc_run() を呼び出す前に SIGALRM 信号をセットできます。そうすると、シグナルハンドラがデータ構造を処理してから svc_run() に制御を戻します。
プロセスから svc_run() をバイパスして直接ディスパッチャにアクセスするには、svc_getreqset() を呼び出します。待っているプログラムに結合したトランスポート端点のファイル記述子がわかれば、プロセスは自分で poll() を呼び出して、RPC ファイル記述子と自身の記述子の両方で要求を待つことができます。
例 4-20 には svc_run() を示します。svc_pollset は、_rpc_select_to_poll() の呼び出しを通して svc_fdset() から派生した pollfd 構造体の配列です。この配列は、RPC ライブラリルーチンのどれかが呼び出されるたびに変わる可能性があります。そのたびに記述子がオープンされ、クローズされるからです。poll() がいくつかの RPC ファイル記述子への RPC 要求の到着を確認すると、svc_getreq_poll() が呼び出されます。
関数 _rpc_dtbsize() と _rpc_select_to_poll() は、SVID の一部ではありませんが、libnsl ライブラリで使用できます。Solaris 以外でも実行できるように、これらの関数を作成するために、関数の仕様を説明します。
int __rpc_select_to_poll(int fdmax, fd_set *fdset, struct pollfd *pollset) |
ビットフラグとして fd_set ポインタとチェックすべきビット数が指定されます。この関数内で、指定された pollfd 配列を RPC が使用するために初期化するようにします。RPC は、入力イベントだけをポーリングします。初期化された pollfd スロット数が返されます。
int __rpc_dtbsize() |
この関数は、getrlimit() 関数を呼び出し、新しく作成された記述子にシステムが割り当てる最大値を決定します。結果は、効率化のためにキャッシュされます。
この節の SVID ルーチンについての詳細は、rpc_svc_calls(3NSL) および poll(2) のマニュアルページを参照してください。
void
svc_run()
{
int nfds;
int dtbsize = __rpc_dtbsize();
int i;
struct pollfd svc_pollset[fd_setsize];
for (;;) {
/*
* 要求待ちするサーバー fd があるかどうかをチェック
*/
nfds = __rpc_select_to_poll(dtbsize, &svc_fdset,
svc_pollset);
if (nfds == 0)
break; /* 要求待ちの fd がないので終了 */
switch (i = poll(svc_pollset, nfds, -1)) {
case -1:
/*
* エラーが起こった場合は、poll() ではなく、シグナルハンドラなど
* 外部イベントによるものと考えて、無視して継続する
*/
case 0:
continue;
default:
svc_getreq_poll(svc_pollset, i);
}
}
}
|
RPC のブロードキャストが要求されると、メッセージはネットワーク上の rpcbind デーモンに送られます。要求されたサービスが登録されている rpcbind デーモンは、その要求をサーバーに送ります。ブロードキャスト RPC と通常の RPC 呼び出しとの主な相違点を次に示します。
通常の RPC では応答は 1 つですが、ブロードキャスト RPC には複数の応答があります (メッセージに応答するすべてのマシンから応答が返されます)。
ブロードキャスト RPC は、UDP のようにブロードキャスト RPC をサポートする非接続型プロトコルでしか使用できません。
ブロードキャスト RPC では、正常終了以外の応答は返されません。したがって、ブロードキャスタと遠隔のサービスでバージョンの不一致があれば、サービスからブロードキャスタには何も返されません。
ブロードキャスト RPC では、rpcbind で登録されたデータグラムサービスだけがアクセス可能です。サービスアドレスはホストごとに異なるので、rpc_broadcast() は、rpcbind のネットワークアドレスにメッセージを送信します。
ブロードキャスト要求のサイズはローカルネットワークの最大伝送ユニット (MTU:maximum trasfer unit) により制限されます。Ethernet の MTU は 1500 バイトです。
例 4-21 では、rpc_broadcast() の使用方法を示し、引数を説明します。
/*
* bcast.c: RPC ブロードキャストの使用例
*/
#include <stdio.h>
#include <rpc/rpc.h>
main(argc, argv)
int argc;
char *argv[];
{
enum clnt_stat rpc_stat;
rpcprog_t prognum;
rpcvers_t vers;
struct rpcent *re;
if(argc != 3) {
fprintf(stderr, "usage : %s RPC_PROG VERSION¥n", argv[0]);
exit(1);
}
if (isdigit( *argv[1]))
prognum = atoi(argv[1]);
else {
re = getrpcbyname(argv[1]);
if (! re) {
fprintf(stderr, "Unknown RPC service %s¥n", argv[1]);
exit(1);
}
prognum = re->r_number;
}
vers = atoi(argv[2]);
rpc_stat = rpc_broadcast(prognum, vers, NULLPROC, xdr_void,
(char *)NULL, xdr_void, (char *)NULL, bcast_proc,
NULL);
if ((rpc_stat != RPC_SUCCESS) && (rpc_stat != RPC_TIMEDOUT)) {
fprintf(stderr, "broadcast failed: %s¥n",
clnt_sperrno(rpc_stat));
exit(1);
}
exit(0);
}
|
例 4-22 の関数 bcast_proc() では、ブロードキャストに対する応答を収集します。通常は、最初の応答だけを取り出すか、応答をすべて収集します。bcast_proc() は、応答を返したサーバーの IP アドレスを表示します。この関数は FALSE を返して応答の収集を続け、RPC クライアントコードはタイムアウトになるまでブロードキャストを再送信し続けます。
bool_t
bcast_proc(res, t_addr, nconf)
void *res; /* 応答なし */
struct t_bind *t_addr; /* 応答したアドレス */
struct netconfig *nconf;
{
register struct hostent *hp;
char *naddr;
naddr = taddr2naddr(nconf, &taddr->addr);
if (naddr == (char *) NULL) {
fprintf(stderr,"Responded: unknown¥n");
} else {
fprintf(stderr,"Responded: %s¥n", naddr);
free(naddr);
}
return(FALSE);
}
|
TRUE が返されるとブロードキャストは終了し、rpc_broadcast() は正常終了します。FALSE が返された場合は、次の応答を待ちます。数秒間待ってから、要求が再びブロードキャストされます。応答が返されない場合は、rpc_broadcast() は RPC_TIMEDOUT を返します。
RPC の設計方針では、クライアントは呼び出しメッセージを送信して、サーバーがそれに応答するのを待ちます。すなわち、サーバーが要求を処理する間、クライアントは停止していることになります。これは、クライアントが各メッセージへの応答を待つ必要がないときには非効率です。
RPC のバッチ処理を使用すると、クライアントは非同期に処理を進めることができます。RPC メッセージは呼び出しパイプラインに入れてサーバーに送られます。バッチ処理では次のことが必要になります。
サーバーはどのような中間メッセージにも応答しない
呼び出しパイプラインは、信頼性の高いトランスポート (たとえば、TCP) で伝送される
呼び出し時に指定する、戻り値に対する XDR ルーチンは NULL である
RPC 呼び出しのタイムアウト値はゼロである
サーバーはそれぞれの呼び出しに対しては応答しないので、クライアントは、サーバーが前の呼び出しを処理している間に平行して次の呼び出しを送信できます。トランスポートは複数の呼び出しメッセージをバッファリングし、システムコール write() で一度にサーバーに送信します。このため、プロセス間通信のオーバヘッドが減少し、一連の呼び出しに要する総時間が短縮されます。クライアントは終了前に、パイプラインをフラッシュする呼び出しをバッチにしないで実行します。
例 4-23 には、バッチ処理を使用しないクライアント側プログラムを示します。文字配列 buf を走査して文字列を順に取り出し、1 つずつサーバーに送信します。
#include <stdio.h>
#include <rpc/rpc.h>
#include "windows.h"
main(argc, argv)
int argc;
char **argv;
{
struct timeval total_timeout;
register CLIENT *client;
enum clnt_stat clnt_stat;
char buf[1000], *s = buf;
if ((client = clnt_create( argv[1], WINDOWPROG, WINDOWVERS,
"circuit_v")) == (CLIENT *) NULL) {
clnt_pcreateerror("clnt_create");
exit(1);
}
total_timeout.tv_sec = 20;
total_timeout.tv_usec = 0;
while (scanf( "%s", s ) != EOF) {
if (clnt_call(client, RENDERSTRING, xdr_wrapstring, &s,
xdr_void, (caddr_t) NULL, total_timeout) != RPC_SUCCESS) {
clnt_perror(client, "rpc");
exit(1);
}
}
clnt_destroy( client );
exit(0);
}
|
例 4-24 には、このクライアントプログラムでバッチ処理を使用する場合を示します。各文字列の送信には応答を待たず、サーバーからの終了応答だけを待ちます。
#include <stdio.h>
#include <rpc/rpc.h>
#include "windows.h"
main(argc, argv)
int argc;
char **argv;
{
struct timeval total_timeout;
register CLIENT *client;
enum clnt_stat clnt_stat;
char buf[1000], *s = buf;
if ((client = clnt_create( argv[1], WINDOWPROG, WINDOWVERS,
"circuit_v")) == (CLIENT *) NULL) {
clnt_pcreateerror("clnt_create");
exit(1);
}
timerclear(&total_timeout);
while (scanf("%s", s) != EOF)
clnt_call(client, RENDERSTRING_BATCHED, xdr_wrapstring,
&s, xdr_void, (caddr_t) NULL, total_timeout);
/* ここでパイプラインをフラッシュ*/
total_timeout.tv_sec = 20;
clnt_stat = clnt_call(client, NULLPROC, xdr_void,
(caddr_t) NULL, xdr_void, (caddr_t) NULL,
total_timeout);
if (clnt_stat != RPC_SUCCESS) {
clnt_perror(client, "rpc");
exit(1);
}
clnt_destroy(client);
exit(0);
}
|
例 4-25 には、バッチ処理を使用した場合のサーバーのディスパッチ部分を示します。サーバーは、メッセージを送信しないので、クライアント側は、失敗に気付きません。
#include <stdio.h>
#include <rpc/rpc.h>
#include "windows.h"
void
windowdispatch(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
char *s = NULL;
switch(rqstp->rq_proc) {
case NULLPROC:
if (!svc_sendreply( transp, xdr_void, NULL))
fprintf(stderr, "can't reply to RPC call¥n");
return;
case RENDERSTRING:
if (!svc_getargs( transp, xdr_wrapstring, &s)) {
fprintf(stderr, "can't decode arguments¥n");
/* 呼び出し側にエラーを通知 */
svcerr_decode(transp);
break;
}
/* 文字列 s を処理するコード */
if (!svc_sendreply( transp, xdr_void, (caddr_t) NULL))
fprintf( stderr, "can't reply to RPC call¥n");
break;
case RENDERSTRING_BATCHED:
if (!svc_getargs(transp, xdr_wrapstring, &s)) {
fprintf(stderr, "can't decode arguments¥n");
/* プロトコルエラーのため何も返さない */
break;
}
/* 文字列 s を処理するコード。ただし応答はしない。 */
break;
default:
svcerr_noproc(transp);
return;
}
/* 引数の復号化で割り当てた文字列を解放 */
svc_freeargs(transp, xdr_wrapstring, &s);
}
|
バッチ処理によるパフォーマンスの向上を調べるために、例 4-23、例 4-25で 25144 行のファイルを処理しました。このサービスは、ファイルの各行を引き渡すだけの簡単なサービスです。バッチ処理を使用した方が、使用しない場合の 4 倍の速さで終了しました。
この章でこれまでに示した例では、呼び出し側は自分自身の ID をサーバーに示さず、サーバーも呼び出し側の ID を要求しませんでした。ネットワークサービスによっては、ネットワークファイルシステムのように、呼び出し側の ID が要求される場合があります。『Solaris のシステム管理』を参照して、この節で説明したいずれかの認証の方法を実行してください。
RPC のクライアントとサーバーを作成するときにさまざまなトランスポートを指定できるように、RPC クライアントにもさまざまなタイプの認証メカニズムを採用できます。RPC の認証サブシステムは端点が開かれているので、認証はさまざな使用法がサポートされます。認証プロトコルは、付録 B 「RPC プロトコルおよび言語の仕様」 で詳細に定義されています。
RPC が現在サポートしている認証タイプを 表 4-7 に示します。
表 4-7 RPC が現在サポートしている認証タイプ|
デフォルト。認証は実行されない |
|
|
UNIX オペレーティングシステムのプロセスアクセス権を基にした認証タイプ |
|
|
サーバーによっては効率向上のため AUTH_SYS の代わりに AUTH_SHORT を使用できる。AUTH_SYS 認証を使用するクライアントプログラムは、サーバーからの AUTH_SHORT 応答ベリファイアを受信できる。詳細は、付録 B 「RPC プロトコルおよび言語の仕様」 を参照 |
|
|
DES 暗号化技法を基にした認証タイプ |
|
呼び出し側が次の方法で RPC クライアントハンドルを新規作成する場合を考えます。
clnt = clnt_create(host, prognum, versnum, nettype); |
この場合対応するクライアント作成ルーチンが次のように認証ハンドルを設定します。
clnt->cl_auth = authnone_create(); |
新たな認証インスタンスを作成するときは、auth_destroy(clnt->cl_auth) を使用して現在のインスタンスを破棄します。この操作はメモリーの節約のために必要です。
サーバー側では、RPC パッケージがサービスディスパッチルーチンに、任意の認証スタイルが結合されている要求を渡します。サービスディスパッチルーチンに渡された要求ハンドルには、rq_cred という構造体が入っています。その構成は、認証資格タイプを示すフィールドを除いて、ユーザーから隠されています。
/*
* 認証データ
*/
struct opaque_auth {
enum_t oa_flavor; /* 資格スタイル */
caddr_t oa_base; /* より詳細な認証データのアドレス */
u_int oa_length; /* 最大 MAX_AUTH_BYTES まで */
};
|
RPC パッケージでは、サービスディスパッチルーチンに対して次のことを保証しています。
svc_req 構造内の rq_cred フィールドは完全に設定済みです。したがって、rq_cred.oa_flavor を調べて認証タイプを得ることができます。得られた認証タイプが RPC でサポートされていない場合は、rq_cred のその他のフィールドも調べることができます。
サービス手続きに引き渡される rq_clntcred フィールドには NULL が入っているか、サポートされている認証資格タイプの設定済み構造体へのポインタが入っています。AUTH_NONE タイプには認証データはありません。rq_clntcred は、authsys_parms、short_hand_verf、 authkerb_cred、authdes_cred の各構造体へのポインタにだけキャストできます。
クライアント側で AUTH_SYS (旧バージョンでは AUTH_UNIX) タイプの認証を使用するには、RPC クライアントハンドルの作成後に clnt->cl_auth を次のように設定します。
clnt->cl_auth = authsys_create_default(); |
以降は、この clnt を使用した RPC 呼び出しでは、clnt とともに例 4-26 に示す資格 - 認証構造体が渡されます。
/*
* AUTH_SYS タイプの資格
*/
struct authsys_parms {
u_long aup_time; /* 資格作成時刻 */
char *aup_machname; /* クライアント側のホスト名 */
uid_t aup_uid; /* クライアント側の実効 uid */
gid_t aup_gid; /* クライアント側の現在のグループ ID */
u_int aup_len; /* aup_gids の配列の長さ */
gid_t *aup_gids; /* ユーザーが所属するグループの配列 */
};
|
rpc.broadcast では、デフォルトで AUTH_SYS タイプの認証になります。
例 4-27 には、手続きを使用し、ネットワーク上のユーザー数を返すサーバープログラムである RUSERPROC_1() を示します。認証の例として AUTH_SYS タイプの資格をチェックし、呼び出し側の uid が 16 の場合は要求に応じないようにしてあります。
nuser(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
struct authsys_parms *sys_cred;
uid_t uid;
unsigned int nusers;
/* NULLPROC の場合は認証データなし */
if (rqstp->rq_proc == NULLPROC) {
if (!svc_sendreply( transp, xdr_void, (caddr_t) NULL))
fprintf(stderr, "can't reply to RPC call¥n");
return;
}
/* ここで uid を取得 */
switch(rqstp->rq_cred.oa_flavor) {
case AUTH_SYS:
sys_cred = (struct authsys_parms *) rqstp->rq_clntcred;
uid = sys_cred->aup_uid;
break;
default:
svcerr_weakauth(transp);
return;
}
switch(rqstp->rq_proc) {
case RUSERSPROC_1:
/* 呼び出し側が、この手続きの呼び出し資格を持っているかどうか確認 */
if (uid == 16) {
svcerr_systemerr(transp);
return;
}
/*
* ユーザー数を求めて変数 nusers に設定するコード
*/
if (!svc_sendreply( transp, xdr_u_int, &nusers))
fprintf(stderr, "can't reply to RPC call¥n");
return;
default:
svcerr_noproc(transp);
return;
}
}
|
このプログラムでは次の点に注意してください。
NULLPROC (手続き番号はゼロ) に結合した認証パラメータは、通常はチェックされません。
サービスプロトコルでは、アクセスが拒否された場合のステータスを返さなければなりません。例 4-27のプロトコルでは、その代わりにサービスプリミティブ svcerr_systemerr() を呼び出しています。
最後の点で重要なのは、RPC の認証パッケージとサービスの関係です。RPC は認証を処理しますが、個々のサービスへのアクセス制御は行いません。サービス自体でアクセス制御の方針を決め、それがプロトコル内で戻り値として反映されるようにしなければなりません。
AUTH_SYS タイプより厳しいセキュリティレベルが要求されるプログラムでは、AUTH_DES タイプの認証を使用します。AUTH_SYS タイプは AUTH_DES タイプに簡単に変更できます。たとえば、authsys_create_default() を使用する代わりに、プログラムから authsys_create() を呼び出し、RPC 認証ハンドルを変更して目的のユーザー ID とホスト名を設定することができます。
AUTH_DES タイプの認証を使用するには、サーバー側とクライアント側の両方のホストで、keyserv() デーモンと NIS また NIS+ ネームサービスが実行されている必要があります。また、両方のホスト上のユーザーに対してネットワーク管理者が割り当てた公開鍵 / 秘密鍵ペアが、publickey() のデータベースに入っていなければなりません。ユーザーは keylogin() のコマンドを実行して自分の秘密鍵を暗号化しておく必要があります。通常は、ログインパスワードと Secure RPC パスワードが同一の場合には、これを login() で行います。
AUTH_DES タイプの認証を使用するには、クライアントが認証ハンドルを正しく設定しなければなりません。その例を次に示します。
cl->cl_auth = authdes_seccreate(servername, 60, server, (char *)NULL); |
最初の引数は、サーバープロセスのネットワーク名か、サーバープロセスの所有者のネット名です。サーバープロセスは通常 root プロセスで、次の関数呼び出しでネット名を得ることができます。
char servername[MAXNETNAMELEN]; host2netname(servername, server, (char *)NULL); |
servername は受信文字列へのポインタで、server はサーバープロセスが実行されているホスト名です。サーバープロセスがスーパーユーザー以外のユーザーから起動されている場合は、次のように user2netname() を呼び出します。
char servername[MAXNETNAMELEN]; user2netname(servername, serveruid(), (char *)NULL); |
serveruid() はサーバープロセスのユーザー id です。どちらの関数も最後の引数は、サーバーを含むドメイン名です。NULL を指定すると、ローカルドメイン名が使用されます。
authdes_seccreate() の第 2 引数では、このクライアントの資格の存在時間 (ウィンドウとも呼ばれる) を指定します。この例では 60 秒が指定されているので、この資格はクライアント側が RPC 呼び出しを行なってから、60 秒間で失われます。プログラムから再びこの資格を使用しようとしても、サーバー側の RPC サブシステムは、資格がすでに失われていることを知って、資格を失ったクライアントからの要求に答えません。また資格の存在時間中に別のプログラムがその資格を再使用しようとしても拒否されます。サーバー側の RPC サブシステムが最近作成された資格を保存していて、重複して使用できないようにするためです。
authdes_seccreate() の第 3 引数は、クロックを同期させる timehost 名です。AUTH_DES タイプの認証を使用するには、サーバーとクライアントの時間が一致していなければなりません。この例では、サーバーに同期させています。(char *)NULL と指定すると同期しません。この指定は、クライアントとサーバーがすでに同期していることが確実な場合にだけ行なってください。
authdes_seccreate() の第 4 引数は、タイムスタンプとデータとを暗号化するための DES 暗号化キーへのポインタです。この例のように (char *)NULL と指定した場合は、ランダムキーが選択されます。このキーは、認証ハンドルの ah_key フィールドに入っています。
サーバー側はクライアント側より簡単です。例 4-27 のサーバーを AUTH_DES タイプの認証を使用するように変更したものを、例 4-28 に示します。
#include <rpc/rpc.h>
...
...
nuser(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
struct authdes_cred *des_cred;
uid_t uid;
gid_t gid;
int gidlen;
gid_t gidlist[10];
/* NULLPROC の場合は認証データなし */
if (rqstp->rq_proc == NULLPROC) {
/* 元のプログラムと同じ */
}
/* ここで uid を取得 */
switch(rqstp->rq_cred.oa_flavor) {
case AUTH_DES:
des_cred = (struct authdes_cred *) rqstp->rq_clntcred;
if (! netname2user( des_cred->adc_fullname.name, &uid,
&gid, &gidlen, gidlist)) {
fprintf(stderr, "unknown user: %s¥n",
des_cred->adc_fullname.name);
svcerr_systemerr(transp);
return;
}
break;
default:
svcerr_weakauth(transp);
return;
}
/* 以降は元のプログラムと同じ */
|
netname2user() ルーチンは、ネットワーク名 (またはユーザーの netname) をローカルシステム ID に変換することに注意してください。このルーチンはグループ ID も返します (この例では使用していません)。
SunOS 5.x は、klogin 以外の Kerberos V5 の大部分のクライアント側機能をサポートします。AUTH_KERB は AUTH_DES と概念的に同じです。主要な違いは、DES がネットワーク名と暗号化された DES セッションキーを引き渡すのに対し、Kerberos は、暗号化されたサービスチケットを引き渡すことです。実装状態と相互運用性に影響を及ぼすその他の要因については、このあとで説明します。
詳細は、kerberos(3KRB) のマニュアルページと MIT Project Athena implementation of Kerberos の Steiner-Neuman-Shiller 報告書 [Steiner, Jennifer G., Neuman, Clifford, and Schiller, Jeffrey J. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, USENIX Association, カリフォルニア州, バークレー, June 1988.] を参照してください。MIT 文書には、athena-dist.mit.edu 上の FTP ディレクトリ、/pub/kerberos/doc または、ドキュメント URL、ftp://athena-dist.mit.edu/pub/kerberos/doc を使用して Mosaic でアクセスできます。
Kerberos はその資格が有効である時間ウィンドウの概念を使用します。クライアントまたはサーバーのクロックを制限しません。クライアントは、サーバーに指定されたウィンドウの時間を調整することによって、自身とサーバー間のずれを決定し、この違いを補う必要があります。具体的には、window を authkerb_seccreate() に引き数として渡します。この場合、ウィンドウは変わりません。timehost が authkerb_seccreate() の引き数として指定されると、クライアント側は timehost から時刻を取得して、時刻の差異によってタイムスタンプを変更します。時刻を同期化するには、さまざまな方法が使用できます。詳細は、kerberos_rpc(3KRB) のマニュアルページを参照してください。
Kerberos ユーザーは、一次名、インスタンス、領域によって識別されます。RPC 認証コードは、領域とインスタンスを無視しますが、Kerberos ライブラリコードは無視しません。ユーザー名は、クライアントとサーバー間で同じであると仮定します。これによって、サーバーは一次名をユーザー ID 情報に変換することができます。周知の名前として 2 つの書式が使用されます (領域は省略されます)。
root.host は、クライアント側 host の特権を与えられたユーザーを表します。
user.ignored は、ユーザー名が user であるユーザーを表します。インスタンは無視されます。
Kerberos は、完全資格名 (チケットとウィンドウを含むもの) の送信時に暗号文ブロックチェイン (CBC: Cipher Block Chaining) モード、それ以外の場合は、電子コードブック (ECB: Electronic Code Book) モードを使用します。CBC と ECB は、DES 暗号化のための 2 つの方法です。詳細は、des_crypt(3) のマニュアルページを参照してください。セッションキーは、CBC モードに対する初期入力ベクトルとして使用されます。表記は次のようになります。
xdr_type(object) |
これは、XDR が object を type とみなして使用されることを示します。次のコードセクションの長さ (資格またはベリファイアのバイト数) を、4 バイト単位に丸めたサイズで表されます。完全資格名およびベリファイアは、次のようになります。
xdr_long(timestamp.seconds) xdr_long(timestamp.useconds) xdr_long(window) xdr_long(window - 1) |
セッションキーに等しい入力ベクトルを持つ CBC で暗号化を行うと、出力結果は次のような 2 つの DES 暗号化ブロックになります。
CB0 CB1.low CB1.high |
xdr_long(AUTH_KERB) xdr_long(length) xdr_enum(AKN_FULLNAME) xdr_bytes(ticket) xdr_opaque(CB1.high) |
xdr_long(AUTH_KERB) xdr_long(length) xdr_opaque(CB0) xdr_opaque(CB1.low) |
xdr_long(timestamp.seconds) xdr_long(timestamp.useconds) |
ニックネームは、ECB によって暗号化され、ECB0 と資格を得ます。
xdr_long(AUTH_KERB) xdr_long(length) xdr_enum(AKN_NICKNAME) xdr_opaque(akc_nickname) |
xdr_long(AUTH_KERB) xdr_long(length) xdr_opaque(ECB0) xdr_opaque(0) |
上述の認証タイプ (AUTH_SYS、AUTH_DES、AUTH_KERB) は、1 つの決まった見方で同じように扱うことができます。このため、新しいネットワーキング階層、Generic Security Standard API (汎用セキュリティ規格 API)、すなわち GSS-API が追加されています。GSS-API のフレームワークでは、認証に加え次の 2 つの「サービス」が提供されています。
「完全性」
一貫性サービスでは、GSS-API は下位層のメカニズムを使用してプログラム間で交換されるメッセージを認証します。暗号化チェックサムによって、以下が確立されます。
データの発信側から受信側への識別情報 (ID)
受信側から発信側への識別情報 (ID) (相互の認証が要求された場合)
伝送されたデータそのものの認証
「プライバシ」
プライバシサービスには、完全性サービスが含まれています。これに加えて、伝送データも「暗号化」され傍受者から保護されます。
米国の輸出の規約により、プライバシサービスはすべてのユーザーが利用できるわけではありません。
現在、GSS-API はまだ発表されていません。ただし、特定の GSS-API 機能は RPCSEC_GSS の機能 (この機能は「不透明な」(opaque 型) で扱うことができる) を通じて参照できます。プログラマはこれらの値に直接かかわる必要はありません。
RPCSEC_GSS API セキュリティタイプを使用すると、ONC RPC アプリケーションは、GSS-API の機能を利用することができます。RPCSEC_GSS は、次の図のように、GSS-API 階層の「最上部」に位置しています。

RPCSEC-GSS のプログラミングインタフェースを使用する場合は、ONC RPC アプリケーションは以下の項目を指定できます。
セキュリティのパラダイム。各種セキュリティメカニズムでは、1 つまたは複数レベルのデータ保護と同時に、それぞれ異なる種類のデータ保護を提供します。この場合、GSS-API によってサポートされる任意のセキュリティメカニズムを指定します (Kerberos v5、RSA 公開鍵など)。
プライバシまたは完全性のいずれかを指定します (あるいはどちらも指定しない)。デフォルトは完全性です。この項目はメカニズムに依存しません。
保護の質。QOP により、プライバシまたは完全性サービスを実現するために使用する暗号化アルゴリズムのタイプが指定されます。各セキュリティメカニズムには、それに関連する 1 つまたは複数の QOP があります。
アプリケーションは、RPCSEC_GSS によって提供される関数により、QOP およびメカニズムのリストを入手できます (「その他の関数」を参照)。開発者は、メカニズムと QOP をハードコード化し、使用するアプリケーション内に埋め込むことは避けてください。そうすれば、新しい、または異なるメカニズムおよび QOP を使用するためにアプリケーションを修正する必要はありません。
これまでは、「セキュリティタイプ」と「認証タイプ」は同じものを表していました。RPCSEC_GSS の導入によって、「タイプ」は現在、多少異なる意味を持ちます。タイプには、認証とともにサービス (一貫性またはプライバシ) を含むことができますが、現在は RPCSEC_GSS が、これを実行できる唯一のタイプです。
RPCSEC_GSS を使用すると、ONC RPC アプリケーションは、他のタイプを使用して行う場合と同様に、ピアにセキュリティコンテキストを確立し、データを交換してこのコンテキストを破棄します。一度コンテキストが確立されると、アプリケーションは、送信したデータユニットごとに QOP およびサービスを変更できます。
RPCSEC_GSS データタイプを含む RPCSEC_GSS の詳細については、rpcsec_gss(3NSL) のマニュアルページを参照してください。
表 4-8 は、RPCSEC_GSS コマンドを要約したものです。この表では、各関数の個別の説明ではなく、RPCSEC_GSS 関数の全般的な概要を示しています。各関数の詳細については、該当するマニュアルページを参照するか、RPCSEC_GSS データ構造のリストなどの概要が記載された、rpcsec_gss(3NSL) のマニュアルページを参照してください。
表 4-8 RPCSEC_GSS Functions| 処理 | 関数 | 入力 | 出力 |
|---|---|---|---|
| セキュリティコンテキストの作成 | rpc_gss_seccreate() | クライアントのハンドル、主体名、メカニズム、QOP、サービスタイプ | AUTH ハンドル |
| コンテキストの QOP とサービスタイプの変更 | rpc_gss_set_defaults() | 古い QOP とサービス | 新しい QOP とサービス |
| セキュリティの変換前に、データの最大サイズを示す | rpc_gss_max_data_length() | 伝送できる最大データサイズ | 変換前の最大データサイズ |
| セキュリティの変換前に、データの最大サイズを示す | rpc_gss_svc_max_data_length() | 伝送できる最大データサイズ | 変換前の最大データサイズ |
| 表示するサーバーの主体名を設定する | rpc_gss_set_svc_name() | 主体名 , RPC プログラム、バージョン番号 | 正常に完了した場合は TRUE |
| 呼び出し元 (クライアント) の資格を得る | rpc_gss_getcred() | svc_req 構造へのポインタ | UNIX 資格、RPCSEC_GSS 資格、cookie |
| (ユーザーの作成した) コールバック関数を指定する | rpc_gss_set_callback() | コールバック関数へのポインタ | 正常に完了した場合は TRUE |
| 固有のパラメータから主体名の RPCSEC_GSS 構造を作成する | rpc_gss_get_principal_name() | メカニズム、ユーザー名、マシン名、ドメイン名 | RPCSEC_GSS 主体名の構造 |
| RPCSEC_GSS ルーチンが失敗した場合にエラーコードを得る | rpc_gss_get_error() |
| RPCSEC_GSS エラー番号、該当する場合には errno |
| インストールされているメカニズムの文字列を入手する | rpc_gss_get_mechanisms() |
| 有効なメカニズムのリスト |
| 有効な QOP 文字列を入手する | rpc_gss_get_mech_info() | メカニズム | そのメカニズムの有効な QOP |
| サポートされている RPCSEC_GSS の最大および最小のバージョン番号を得る | rpc_gss_get_versions() |
| 最大および最小のバージョン番号 |
| メカニズムが導入されているかどうかをチェックする | rpc_gss_is_installed() | メカニズム | インストールされている場合は TRUE |
| ASCII メカニズムを RPC オブジェクト識別子に変換する | rpc_gss_mech_to_oid() | メカニズム (文字列で) | メカニズム (OID で) |
| ASCII QOP を整数に変換する | rpc_gss_qop_to_num() | QOP (文字列で) | QOP (整数で) |
コンテキストは、rpc_gss_seccreate() 呼び出しを使用して作成します。この関数では引数として次のものをとります。
クライアントハンドル(たとえば、clnt_create()によって戻されたもの)
サーバーの主体名 ( nfs@acme.com)
セッションのメカニズム (Kerberos V5 など)
セキュリティサービスタイプ (プライバシなど)
セッションの QOP
使用される場合は、ほとんど不透明( opaque )なまま使用される (つまり、プログラマが NULL 値を入れることができる) 2 つの GSS-API パラメータ
この関数で、AUTH 認証ハンドルを返します。例 4-29 は、Kerberos v5 セキュリティメカニズムと完全性サービスを使用したコンテキストを作成する場合、rpc_gss_seccreate() がどのように使用されるかを示しています。
CLIENT *clnt; /* クライアントハンドル */ char server_host[] = "foo"; char service_name[] = "nfs@machine.eng.company.com"; char mech[] = "kerberosv5"; clnt = clnt_create(server_host, SERVER_PROG, SERV_VERS, "netpath"); clnt->clnt_auth = rpc_gss_seccreate(clnt, service_name, mech, ¥ rpc_gss_svc_integrity, NULL, NULL, NULL); . . . |
この例 4-29 では、次の点に注意してください。
メカニズムは明示的に宣言してありますが (読みやすくするために)、通常は、rpc_gss_get_mechanisms() 用いて、使用できるメカニズムの表から入手します。
QOP は、NULL として渡されます。これにより、QOP はこのメカニズムのデフォルトに設定されます。これ以外の場合は、このメカニズムを使用して、rpc_gss_get_mechanisms() を指定したプログラムで有効な値を入手できます。詳細については、マニュアルページの rpc_gss_get_mechanisms(3NSL) を参照してください。
セキュリティサービスタイプ、rpc_gss_svc_integrity は、RPCSEC_GSS タイプの enum のひとつである rpc_gss_service_t です。rpc_gss_service_t のフォーマットは、次のようになります。
typedef enum {
rpc_gss_svc_default = 0,
rpc_gss_svc_none = 1,
rpc_gss_svc_integrity = 2,
rpc_gss_svc_privacy = 3
} rpc_gss_service_t;
|
デフォルトのセキュリティサービスは、完全性をマップするため、プログラマは指定された rpc_gss_svc_default を入手し、同じ結果を獲得することができます。
詳細については、rpc_gss_seccreate(3NSL) のマニュアルページを参照してください。
コンテキストが設定されると、アプリケーションは伝送される個々のデータユニットの QOP およびサービス値を変更する必要がある場合があります。たとえば、プログラムのパスワードは暗号化したいがログイン名は暗号化したくない場合。これは、次のように rpc_gss_set_defaults() を使用すると実行できます。
rpc_gss_set_defaults(clnt->clnt_auth, rpc_gss_svc_privacy, qop); . . . |
この場合、セキュリティサービスはプライバシに設定されます (「コンテキストの作成」を参照)。
ここで、qop は新しいQOPの名前を表わす文字列へのポインタです。
コンテキストは、通常どおり、auth_destroy() を使用して破棄します。
QOP とサービスの変更に関する詳細は、rpc_gss_set_defaults(3NSL) のマニュアルページを参照してください。
セキュリティコンテキストを確立し、保持するには、次の 2 つのタイプの主体名が必要です。
サーバーの主体名は、通常、「service@host」の形式の NULL で終わる ASCII 文字列で指定します。たとえば、 nfs@eng.acme.com のように指定します。
クライアントが rpc_gss_seccreate() でセキュリティコンテキストを作成する時に、このフォーマットでサーバーの主体名を指定します (「コンテキストの作成」を参照)。同様にサーバーは、表示する主体名を設定する必要がある場合は、引数としてこのフォーマットの主体名をとる rpc_gss_set_svc_name() を使用します。
サーバーが受信するクライアントの主体名は、rpc_gss_principal_t 構造の形式 (使用するメカニズムによって決定される、不透明に長さを暗示したバイト列) をとります。この構造については、rpcsec_gss(3NSL) のマニュアルページを参照してください 。
サーバーは、起動時に、そのサーバーを表わす主体名を指定する必要があります (1 つのサーバーが複数の主体として機能する場合もあります)。サーバー主体名の設定には、rpc_gss_set_svc_name() を使用します。
char *principal, *mechanism; u_int req_time; principal = "nfs@eng.acme.com"; mechanism = "kerberos_v5"; req_time = 10000; /* 資格の有効時間 */ rpc_gss_set_svc_name(principal, mechanism, req_time, SERV_PROG, SERV_VERS);
Kerberos は、req_time パラメータを無視します。他の認証システムでは、このパラメータを使用する場合があります。
詳細については、rpc_gss_set_svc_name(3NSL) のマニュアルページを参照してください。
サーバーは、クライアントの主体名で稼動できなければなりません。たとえば、クライアントの主体名をアクセス制御リストと比較するため、またはクライアントの UNIX 資格を検出するため (このような資格が存在する場合) に必要です。このような主体名は、rpc_gss_principal_t 構造ポインタのフォームで維持されます (rpc_gss_principal_t の詳細については、rpcsec_gss(3NSL) のマニュアルページを参照してください)。サーバーが、受信した主体名を既知のエンティティの名前と比較する必要がある場合、サーバーは、この形式で rpc_gss_principal_t 主体名を生成できなければなりません。
rpc_gss_get_principal_name() 呼び出しでは、ネットワーク上で個人を識別するパラメータをいくつか入力し、rpc_gss_principal_t 構造ポインタとして主体名を生成します。
rpc_gss_principal_t *principal; rpc_gss_get_principal_name(principal, mechanism, name, node, domain); . . .
rpc_gss_get_principal_name() への引数は、次のとおりです。
「 principal 」には、設定された rpc_gss_principal_t 構造へのポインタが入ります。
「 mechanism 」には、使用されるセキュリティメカニズムです (生成される主体名は、メカニズムに依存することに注意してください)。
「 name 」には joeh または nfs などの個人名、またはサービス名が入ります。
「 node 」には、UNIX マシン名などが入ります。
「 domain 」には、たとえば、DNS、NIS、または NIS+ドメイン名、あるいは Kerberos の領域が入ります。
各セキュリティメカニズムには、別々の識別パラメータが必要です。たとえば、Kerberos V5 にはユーザー名が必ず必要です。また、オプションの場合に限り、修飾されたノード名とドメイン名が必要です (Kerberos 用語では、ホスト名と領域名)。
詳細については、rpc_gss_get_principal_name(3NSL) のマニュアルページを参照してください。
主体名は、free() ライブラリコールを使用して解放します。
サーバーは、クライアントの資格を獲得できなければなりません。 例 4-33 で示すように、rpc_gss_getcred() 関数を使用すると、サーバーは UNIX 資格または RPCSEC_GSS 資格のいずれか (またはこの両方) を検索できます。これは、この関数が正常に終了した場合に設定された 2 つの引数によって実行されます。このうち1つは、呼び出し元の UNIX 資格が組み込まれた rpc_gss_ucred_t 構造 (存在する場合) へのポインタになります。
typedef struct {
uid_t uid; /* ユーザー ID */
gid_t gid; /* グループ ID */
short gidlen;
git_t *gidlist; /* グループのリスト */
} rpc_gss_ucred_t;
|
もう 1 つの引数は、次のような、rpc_gss_raw_cred_t 構造へのポインタです。
typedef struct {
u_int version; /* RPCSEC_GSS プログラムバージョン */
char *mechanism;
char *qop;
rpc_gss_principal_t *client_principal; /* クライアント主体名 */
char *svc_principal; /* サーバー主体名 */
rpc_gss_service_t service; /* プライバシ、完全性 enum */
} rpc_gss_rawcred_t;
|
例 4-33 は 1 つのサーバー側のディスパッチ手続きの例です。これにより、サーバーは呼び出し元の資格を入手します。この手続きでは、呼び出し元の UNIX 資格を入手してから、次に rpc_gss_rcred_t 引数内で検出された、メカニズム、QOP、サービスタイプを使用してユーザーの識別情報 (ID) を確認します。
static void server_prog(struct svc_req *rqstp, SVCXPRT *xprt)
{
rpc_gss_ucred_t *ucred;
rpc_gss_rawcred_t *rcred;
if (rqst->rq_proq == NULLPROC) {
svc_sendreply(xprt, xdr_void, NULL);
return;
}
/*
* 他の全ての要求を認証する */
*/
switch (rqstp->rq_cred.oa_flavor) {
case RPCSEC_GSS:
/*
* 資格情報を取得する
*/
rpc_gss_getcred(rqstp, &rcred, &ucred, NULL);
/*
* 設定ファイルを参照してセキュリティパラメータを
* 使用することでユーザーにアクセスが許可されている
* ことを確認する
*/
if (!authenticate_user(ucred->uid, rcred->mechanism,
rcred->qop, rcred->service)) {
svcerr_weakauth(xprt);
return;
}
break; /* ユーザーに許可する */
default:
svcerr_weakauth(xprt);
return;
} /* スイッチの終り */
switch (rqstp->rq_proq) {
case SERV_PROC1:
. . .
}
/* 通常の要求処理 ; 応答を送る ... */
return;
}
|
詳細については、rpc_gss_getcred(3NSL) のマニュアルページを参照してください。
例 4-33 では、 rpc_gss_getcred()への最後の引数は、ユーザー定義の cookie です。このコンテキストの作成時にサーバーによってどのような値が指定されていても、このユーザー定義の値が戻されます。この cookie は 4 バイトの値で、そのアプリケーションに適したあらゆる方法で使用されます。RPC はこれを解釈しません。たとえば、 cookie は、コンテキストの起動元を示す構造へのポインタまたはインデックスになることができます。また、各要求ごとにこの値を計算する代わりに、サーバーがコンテキスト作成時にこの値を計算します。このため、要求の処理時間が削減されます。
これ以外に cookie が使用される場所は、コールバックです。サーバーは、rpc_gss_set_callback() 関数を使用することにより、(ユーザー定義の) コールバックを指定してコンテキストが最初に使用された時を認知できます。コールバックは、コンテキストが指定されたプログラムとバージョン用に確立されたあとに、そのコンテキストがデータ交換に最初に使用された時に呼び出されます。
ユーザー定義のコールバックルーチンは、以下のような形式になります。
2 番めと 3 番めの引数 deleg と gss_context は、GSS-API データタイプで、現在はまだ公開されていません。そのため、コールバック関数はこれらを無視します。簡単に説明すると、プログラムが GSS-API オペレーションをこのコンテキスト上で実行する必要がある場合、すなわち受信条件のテストをする場合、deleg は代表されるピアの識別情報になり、一方 gss_context は GSS-API コンテキストへのポインタになります。cookie 引数については、すでに説明しました。
lock 引数は、以下のように rpc_gss_lock_t 構造へのポインタです。
typedef struct {
bool_t locked;
rpc_gss_rawcred_t *raw_cred;
} rpc_gss_lock_t;
|
詳細は、 rpc_gss_set_callback(3NSL) のマニュアルページを参照してください。
rpc_gss_max_data_length() と rpc_gss_svc_max_data_length() の 2 つの関数は、1 つのデータが、セキュリティ測度によって変換され「ワイヤを通じて」送信される前に、そのデータの大きさを判別する場合に便利です。つまり、暗号化などのセキュリティ変換により、通常、伝送される 1 つのデータのサイズは変更されます (通常は、大きくなる)。データが使用できるサイズ以上に大きくならないように、これら 2 つの関数 (前者はクライアント側バージョンで、後者はサーバー側バージョン) により、指定されたトランスポートの変換前の最大サイズが戻されます。
詳細については、rpc_gss_max_data_length(3NSL) と rpc_gss_svc_max_data_length(3NSL) のマニュアルページを参照してください。
関数の中には、導入されたセキュリティシステムに関する情報を入手する場合に使用できるものもあります。
rpc_gss_get_mechanisms() は、導入されたセキュリティメカニズムのリストを戻します。
rpc_gss_is_installed() は、指定したメカニズムがインストールされているかどうかを検査します。
rpc_gss_get_mech_info() は、指定されたメカニズムの有効な QOP を戻します。
これらの関数を使用することによって、プログラマは、アプリケーション内のセキュリティパラメータのハードコード化を避けることができます (RPCSEC_GSS 関数については、表 4-8 と rpcsec_gss(3NSL) のマニュアルページを参照)。
RPCSEC_GSS は各種のファイルを使用して情報を保存します。
サーバーが要求に関連するクライアントの資格を検索すると、サーバーはクライアントの主体名 (rpc_gss_principal_t 構造ポインタの形式)、またはクライアントのローカル UNIX 資格 (UID) のいずれかを入手できます。NFS 要求などのサービス では、アクセス検査に必要なローカル UNIX 資格が必要ですが、他の資格は必要ありません。つまり、これらのサービスでは、たとえば主体名は、rpc_gss_principal_t 構造として直接、独自のアクセス制御リスト内に格納できるからです。
クライアントのネットワーク資格 (その主体名) とローカル UNIX 資格間の対応は自動的に行われません。これは、ローカルのセキュリティ管理者が明示的に設定する必要があります。
gsscred ファイルには、クライアントの UNIX 資格とネットワーク(たとえば、Kerberos V5) 資格の両方が入っています。後者は、rpc_gss_principal_t 構造の Hex-ASCII 表示です。これには、XFN を通じてアクセスするため、このテーブルは、ファイル、NIS、NIS+、あるいは XFN によってサポートされる将来のネームサービス上に導入できます。XFN 階層では、このテーブルは this_org_unit/service/gsscred として表示されます。 gsscred テーブルは、gsscred ユーティリティとともに保持されます。このユーティリティを使用すると、管理者はユーザーやメカニズムの追加および削除が行えます。
便宜上、RPCSEC_GSS では、メカニズムと保護の質 (QOP) パラメータを表示するためにリテラルの文字列を使用します。ただし、基本的なメカニズム自体では、メカニズムをオブジェクト識別子として、QOP は 32 ビット整数として表示する必要があります。また、各メカニズムごとに、そのメカニズムのサービスを実現する共有ライブラリを指定する必要があります。
/etc/gss/mech ファイルには、システム上に導入されたすべてのメカニズムに関する情報、メカニズム名 (ASCII 形式)、メカニズムの ODI、このメカニズムによって使用できるサービスを実現する共有ライブラリ、サービスを実現するカーネルモジュールが格納されます。次に例を示します。
kerberos_v5 1.2.840.113554.1.2.2 gl/mech_krb5.so gl_kmech_krb5 |
/etc/gss/qop ファイルには、導入されたすべてのメカニズム用に、各メカニズムがサポートするすべての QOP が、ASCII 文字列とそれに対応する 32 ビット整数の両方で格納されます。
/etc/gss/mech と /etc/gss/qop は、両方とも指定されたシステムにセキュリティメカニズムが最初に導入されたときに作成されます。
カーネル内 RPC ルーチンは、通常、文字列にない値を使用してメカニズムと QOP を表すため、アプリケーションは、これらのカーネル内ルーチンを利用したい場合には、rpc_gss_mech_to_oid() と rpc_gss_qop_to_num() 関数を使用してこれらのパラメータと同等の文字列にない値を入手します。
RPC サーバーは、inetd や listen のようなポートモニタから起動できます。ポートモニタは、要求が来ているかどうか監視し、要求が来ればそれに応じてサーバーを生成します。生成されたサーバープロセスには、要求を受信したファイル記述子 0 が渡されます。inetd の場合、サーバーは処理を終えるとすぐに終了するか、次の要求がくる場合に備えて指定された時間だけ待ってから終了します。
listen の場合は常に新たなプロセスが生成されるため、サーバーは応答を返したらすぐに終了しなければなりません。次に示す関数呼び出しでは、ポートモニタから起動されるサービスで使用する SVCXPRT ハンドルが作成されます。
transp = svc_tli_create(0, nconf, (struct t_bind *)NULL, 0, 0) |
ここで、nconf は要求を受信したトランスポートの netconfig 構造体です。
サービスはポートモニタによりすでに rpcbind で登録されているので、登録する必要はありません。ただし、サービス手続きは次のように svc_reg() を呼び出して登録しなければなりません。
svc_reg(transp, PROGNUM, VERSNUM, dispatch,(struct netconfig *)NULL) |
ここでは netconfig 構造体として NULL を渡し、svc_reg() が rpcbind を呼び出してサービスを登録しないようにしています。
rpcgen が生成したサーバー側スタブプログラムを調べて、これらのルーチンの呼び出し順序を確認してください。
接続型トランスポートの場合は、次のルーチンにより下位レベルインタフェースが提供されます。
transp = svc_fd_create(0, recvsize, sendsize); |
最初の引数ではファイル記述子 0 を指定します。recvsize と sendsize には、適当なバッファサイズを指定できます。どちらの引数も 0 とすると、システムのデフォルト値が使用されます。自分で監視を行わないアプリケーションサーバーの場合は、svc_fd_create() を使用します。
/etc/inet/inetd.conf のエントリ形式は、ソケットサービス、TLI サービス、RPC サービスによってそれぞれ異なります。RPC サービスの場合の inetd.conf のエントリ形式は次のようになります。
rpc_prog/vers endpoint_type rpc/proto flags user pathname args |
各エントリの内容を次に示します。
表 4-9 RPC inetd サービス|
rpc_prog/vers |
RPC プログラム名に / とバージョン番号 (またはバージョン番号の範囲) を付けたもの |
|
endpoint_type |
dgram (非接続型ソケット)、stream (接続型ソケット)、tli (TLI 端点) のどれか |
|
proto |
サポートされているトランスポートすべてを意味する *、nettype、netid のどれか。または、nettype と netid をコンマで区切ったリスト |
|
flags |
wait または nowait のどちらか |
|
user |
有効な passwd データベースに存在しているユーザー |
|
pathname |
サーバーデーモンへのフルパス名 |
|
args |
デーモンの呼び出し時に渡される引数 |
エントリの例を次に示します。
rquotad/1 tli rpc/udp wait root /usr/lib/nfs/rquotad rquotad |
inetd についての詳細は、inetd.conf(4) のマニュアルページを参照してください。
次に示すように pmadm を使用して RPC サービスを追加します。
pmadm -a -p pm_tag -s svctag -i id -v vers ¥ -m `nlsadmin -c command -D -R prog:vers` |
引数の -a はサービスの追加を意味します。-p pm_tag ではサービスへのアクセスを提供するポートモニタに結合したタグを指定します。-s svctag はサーバーの ID コードです。-i id はサービス svctag に割り当てられた /etc/passwd 内のユーザー名です。-v vers はポートモニタのデータベースファイルのバージョン番号です。-m ではサービスを呼び出す nlsadmin コマンドを指定します。nlsadmin コマンドには引数を渡すことができます。たとえば、rusersd という名前の遠隔プログラムサーバーのバージョン 1 を追加する場合は、pmadm コマンドは次のようになります。
# pmadm -a -p tcp -s rusers -i root -v 4 ¥ -m `nlsadmin -c /usr/sbin/rpc.ruserd -D -R 100002:1` |
このコマンドでは、root パーミッションが指定され、listener データベースファイルのバージョン 4 でインストールされ、TCP トランスポート上で使用可能になります。pmadm の引数やオプションは複雑であるため、RPC サービスはコマンドスクリプトでもメニューシステムでも追加できます。メニューシステムを使用するには、sysadm ports と入力して、port_services オプションを選択します。
サービスを追加した場合は、その後リスナを再初期化してサービスを利用可能にしなければなりません。そのためには、次のようにリスナを一度止めてから再起動します (このとき rpcbind が実行されていなければならないことに注意してください)。
# sacadm -k -p pmtag # sacadm -s -p pmtag |
リスナプロセスの設定などについての詳細は、listen(1M)、pmadm(1M)、sacadm(1M)、sysadm(1M) のマニュアルページと『Solaris のシステム管理 (第 3 巻)』を参照してください。
一般に、プログラム PROG の最初のバージョンは PROGVERS_ORIG とし、最新バージョンは PROGVERS と命名します。プログラムのバージョン番号は続き番号で割り当てなければなりません。バージョン番号に飛ばされた番号があると、検索したときに定義済みのバージョン番号を探し出せないようなことが起こります。
プログラムのバージョン番号は、プログラムの所有者以外は決して変更しないでください。自分が所有していないプログラムのバージョン番号を追加したりすると、そのプログラムの所有者がバージョン番号を追加するときに重大な問題が起こります。バージョン番号の登録やご質問はご購入先へお問い合わせ下さい。
ruser プログラムの新バージョンが、int ではなく unsigned short を返すように変更されたとします。新バージョンの名前を RUSERSVERS_SHORT とすると、新旧の 2 つのバージョンをサポートするサーバーは二重登録することになります。次のように、どちらの登録でも同じサーバーハンドルを使用します。
if (!svc_reg(transp, RUSERSPROG, RUSERSVERS_ORIG,
nuser, nconf))
{
fprintf(stderr, "can't register RUSER service¥n");
exit(1);
}
if (!svc_reg(transp, RUSERSPROG, RUSERSVERS_SHORT, nuser,
nconf)) {
fprintf(stderr, "can't register RUSER service¥n");
exit(1);
}
|
次のように、1 つの手続きで両バージョンを実行できます。
void
nuser(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
unsigned int nusers;
unsigned short nusers2;
switch(rqstp->rq_proc) {
case NULLPROC:
if (!svc_sendreply( transp, xdr_void, 0))
fprintf(stderr, "can't reply to RPC call¥n");
return;
case RUSERSPROC_NUM:
/*
* ユーザー数を求めて変数 nusers に設定するコード
*/
switch(rqstp->rq_vers) {
case RUSERSVERS_ORIG:
if (! svc_sendreply( transp, xdr_u_int, &nusers))
fprintf(stderr, "can't reply to RPC call¥n");
break;
case RUSERSVERS_SHORT:
nusers2 = nusers;
if (! svc_sendreply( transp, xdr_u_short, &nusers2))
fprintf(stderr, "can't reply to RPC call¥n");
break;
}
default:
svcerr_noproc(transp);
return;
}
return;
}
|
異なるホストでは RPC サーバーの異なるバージョンが実行されている可能性があるので、クライアントはさまざまなバージョンに対応できるようにしなければなりません。たとえば、あるサーバーでは旧バージョン RUSERSPROG(RUSERSVERS_ORIG) が実行されており、別のサーバーでは最新バージョン RUSERSPROG(RUSERSVERS_SHORT) が実行されているとします。
サーバーのバージョンがクライアント作成ルーチン clnt_call() で指定したバージョン番号と一致しない場合は、clnt_call() から RPCPROGVERSMISMATCH というエラーが返されます。サーバーがサポートしているバージョン番号を取り出して、正しいバージョン番号をもつクライアントハンドルを作成することもできます。そのためには、例 4-36 のルーチンを使用するか、clnt_create_vers() を使用します。詳細については、rpc(3NSL) のマニュアルページを参照してください。
main()
{
enum clnt_stat status;
u_short num_s;
u_int num_l;
struct rpc_err rpcerr;
int maxvers, minvers;
CLIENT *clnt;
clnt = clnt_create("remote", RUSERSPROG, RUSERSVERS_SHORT,
"datagram_v");
if (clnt == (CLIENT *) NULL) {
clnt_pcreateerror("unable to create client handle");
exit(1);
}
to.tv_sec = 10; /* タイムアウト値を設定 */
to.tv_usec = 0;
status = clnt_call(clnt, RUSERSPROC_NUM, xdr_void,
(caddr_t) NULL, xdr_u_short,
(caddr_t)&num_s, to);
if (status == RPC_SUCCESS) { /* 最新バージョン番号が見つかった場合 */
printf("num = %d¥n", num_s);
exit(0);
}
if (status != RPC_PROGVERSMISMATCH) { /* その他のエラー */
clnt_perror(clnt, "rusers");
exit(1);
}
/* 指定したバージョンがサポートされていない場合 */
clnt_geterr(clnt, &rpcerr);
maxvers = rpcerr.re_vers.high; /* サポートされている最新バージョン */
minvers = rpcerr.re_vers.low; /* サポートされている最も古いバージョン */
if (RUSERSVERS_SHORT < minvers || RUSERSVERS_SHORT > maxvers)
{
/* サポート範囲内にない場合 */
clnt_perror(clnt, "version mismatch");
exit(1);
}
(void) clnt_control(clnt, CLSET_VERSION, RUSERSVERS_ORIG);
status = clnt_call(clnt, RUSERSPROC_NUM, xdr_void,
(caddr_t) NULL, xdr_u_int, (caddr_t)&num_l, to);
if (status == RPC_SUCCESS)
/* 識別できるバージョン番号が見つかった場合 */
printf("num = %d¥n", num_l);
else {
clnt_perror(clnt, "rusers");
exit(1);
}
}
|
場合によっては、動的に生成される RPC プログラム番号をアプリケーションが使用すると便利なことがあります。たとえば、コールバック手続きを実装する場合などです。コールバックでは、クライアントプログラムは通常、動的に生成される、つまり一時的な RPC プログラム番号を使用して RPC サービスを登録し、これを要求とともにサーバーに渡します。次にサーバーは一時的な RPC プログラム番号を使用してクライアントプログラムをコールバックし、結果を返します。クライアントの要求を処理するのにかなりの時間がかかり、クライアントが停止できない (シングルスレッドであると仮定して) 場合などには、この機構が必要になります。このような場合、サーバーはクライアントの要求を認識し、あとで結果とともにコールバックを行います。コールバックを使用する別の例としては、サーバーから定期的なレポートを生成する場合があります。クライアントは RPC 呼び出しを行い、報告を開始します。そしてサーバーはクライアントプログラムが提供する一時的な RPC プログラム番号を使用して、定期的にレポートとともにクライアントをコールバックします。
動的に生成される一時的な RPC 番号は、0x40000000 から 0x5fffffff の範囲です。次に示すルーチンは指定されるトランスポートタイプ用に、一時的な RPC プログラムに基づいてサービスを作成します。サービスハンドルと一時的な rpc プログラム番号が返されます。呼び出し側はサービスディスパッチルーチン、バージョンタイプ、トランスポートタイプを提供します。
SVCXPRT *
register_transient_prog(dispatch, program, version, netid)
void (*dispatch)(); /* サービスディスパッチルーチン */
rpcproc_t *program; /* 一時的な RPC 番号が返される */
rpcvers_t version; /* プログラムバージョン */
char *netid; /* トランスポート id */
{
SVCXPRT *transp;
struct netconfig *nconf;
rpcprog_t prognum;
if ((nconf = getnetconfigent(netid)) == (struct netconfig
*)NULL)
return ((SVCXPRT *)NULL);
if ((transp = svc_tli_create(RPC_ANYFD, nconf,
(struct t_bind *)NULL, 0, 0)) == (SVCXPRT *)NULL) {
freenetconfigent(nconf);
return ((SVCXPRT *)NULL);
}
prognum = 0x40000000;
while (prognum < 0x60000000 && svc_reg(transp, prognum,
version,
dispatch, nconf) == 0) {
prognum++;
}
freenetconfigent(nconf);
if (prognum >= 0x60000000) {
svc_destroy(transp);
return ((SVCXPRT *)NULL);
}
*program = prognum;
return (transp);
}
|
このマニュアルには、Solaris でのマルチスレッドプログラミングについては説明していません。次の項目については、『マルチスレッドのプログラミング』を参照してください。
スレッドの作成
スケジューリング
同期
シグナル
プロセスリソース
軽量プロセス (lwp)
並列性
データロックの技術
TI-RPC は、Solaris 2.4 以降のマルチスレッド RPC サーバーをサポートします。マルチスレッドサーバーと シングルスレッドのサーバーの違いは、マルチスレッドサーバーがスレッドの技術を使用して複数のクライアント要求を同時に処理することです。マルチスレッドサーバーの方が、高度なパフォーマンスと可用性を備えています。
このリリースで新規に使用可能なインタフェースについては、まず、「マルチスレッドサーバーの概要」から読んでください。
マルチスレッド対応のクライアントプログラムでは、RPC 要求が出されるたびにスレッドを 1 つ作成することができます。複数スレッドが同一のクライアントハンドルを共有する場合は、RPC 要求を発行できるのは一度に 1 つのスレッドだけです。その他のすべてのスレッドは、未処理の要求が終了するまで待たなければなりません。これに対して、複数スレッドがそれぞれ固有のクライアントハンドルを使用して RPC 要求を出す場合には、複数の要求が同時に処理されます。図 4-2 は、異なるクライアントハンドルを使用するクライアント側の 2 つのスレッドから成るマルチスレッド対応クライアント環境でのタイミングの例を示したものです。
例 4-38 は、クライアント側でマルチスレッド rstat プログラムを実行する場合を示します。クライアントプログラムは各ホストに対してスレッドを作成します。スレッドはそれぞれ、固有のクライアントハンドルを作成し、指定のホストにさまざまな RPC 呼び出しを行なっています。クライアント側の各スレッドは異なるハンドルを使用して RPC 呼び出しを行うため、RPC 呼び出しは同時に実行されます。

RPC マルチスレッド対応アプリケーションを作成する場合は常に、スレッドライブラリをリンクしなければなりません。コンパイルコマンドで -lthread を指定して、スレッドライブラリを最後にリンクするようにしなければなりません。
次のように入力して 例 4-38 のプログラムを作成します。
$ cc rstat.c -lnsl -lthread |
/* @(#)rstat.c 2.3 93/11/30 4.0 RPCSRC */
/*
* w コマンドと同様の形式で、遠隔ホストのステータスを表示する簡単な
* プログラム
*/
#include <thread.h> /* スレッドインタフェースの定義 */
#include <synch.h> /* 相互排他的ロックの定義 */
#include <stdio.h>
#include <sys/param.h>
#include <rpc/rpc.h>
#include <rpcsvc/rstat.h>
#include <errno.h>
mutex_t tty; /* printf のための tty の制御 */
cond_t cv_finish;
int count = 0;
main(argc, argv)
int argc;
char **argv;
{
int i;
thread_t tid;
void *do_rstat();
if (argc < 2) {
fprintf(stderr, "usage: %s ¥"host¥" [...]¥n", argv[0]);
exit(1);
}
mutex_lock(&tty);
for (i = 1; i < argc; i++) {
if (thr_create(NULL, 0, do_rstat, argv[i], 0, &tid) < 0) {
fprintf(stderr, "thr_create failed: %d¥n", i);
exit(1);
} else
fprintf(stderr, "tid: %d¥n", tid);
}
while (count < argc-1) {
printf("argc = %d, count = %d¥n", argc-1, count);
cond_wait(&cv_finish, &tty);
}
exit(0);
}
bool_t rstatproc_stats();
void *
do_rstat(host)
char *host;
{
CLIENT *rstat_clnt;
statstime host_stat;
bool_t rval;
struct tm *tmp_time;
struct tm host_time;
struct tm host_uptime;
char days_buf[16];
char hours_buf[16];
mutex_lock(&tty);
printf("%s: starting¥n", host);
mutex_unlock(&tty);
/* rstat クライアントハンドル */
rstat_clnt = clnt_create(host, RSTATPROG, RSTATVERS_TIME,
"udp");
if (rstat_clnt == NULL) {
mutex_lock(&tty); /* ty の制御権を取得 */
clnt_pcreateerror(host);
count++;
cond_signal(&cv_finish);
mutex_unlock(&tty); /* tty の制御権を解放 */
thr_exit(0);
}
rval = rstatproc_stats(NULL, &host_stat, rstat_clnt);
if (!rval) {
mutex_lock(&tty); /* tty の制御権を取得 */
clnt_perror(rstat_clnt, host);
count++;
cond_signal(&cv_finish);
mutex_unlock(&tty); /* tty の制御権を解放 */
thr_exit(0);
}
tmp_time = localtime_r(&host_stat.curtime.tv_sec,
&host_time);
host_stat.curtime.tv_sec = host_stat.boottime.tv_sec;
tmp_time = gmtime_r(&host_stat.curtime.tv_sec,
&host_uptime);
if (host_uptime.tm_yday != 0)
sprintf(days_buf, "%d day%s, ", host_uptime.tm_yday,
(host_uptime.tm_yday > 1) ? "s" : "");
else
days_buf[0] = '¥0';
if (host_uptime.tm_hour != 0)
sprintf(hours_buf, "%2d:%02d,",
host_uptime.tm_hour, host_uptime.tm_min);
else if (host_uptime.tm_min != 0)
sprintf(hours_buf, "%2d mins,", host_uptime.tm_min);
else
hours_buf[0] = '¥0';
mutex_lock(&tty); /* tty の制御権を取得 */
printf("%s: ", host);
printf(" %2d:%02d%cm up %s%s load average: %.2f %.2f %.2f¥n",
(host_time.tm_hour > 12) ? host_time.tm_hour - 12
: host_time.tm_hour,
host_time.tm_min,
(host_time.tm_hour >= 12) ? 'p'
: 'a',
days_buf,
hours_buf,
(double)host_stat.avenrun[0]/FSCALE,
(double)host_stat.avenrun[1]/FSCALE,
(double)host_stat.avenrun[2]/FSCALE);
count++;
cond_signal(&cv_finish);
mutex_unlock(&tty); /* tty の制御権を解放 */
clnt_destroy(rstat_clnt);
sleep(10);
thr_exit(0);
}
/* クライアント側の MT rstat プログラムの実行 */
/* clnt_control() を使用してデフォルトのタイムアウトを変更可能 */
static struct timeval TIMEOUT = { 25, 0 };
bool_t
rstatproc_stats(argp, clnt_resp, clnt)
void *argp;
statstime *clnt_resp;
CLIENT *clnt;
{
memset((char *)clnt_resp, 0, sizeof (statstime));
if (clnt_call(clnt, RSTATPROC_STATS,
(xdrproc_t) xdr_void, (caddr_t) argp,
(xdrproc_t) xdr_statstime, (caddr_t) clnt_resp,
TIMEOUT) != RPC_SUCCESS) {
return (FALSE);
}
return (TRUE);
}
|
Solaris 2.4 より前のバージョンでは、RPC サーバーはシングルスレッドでした。つまり、クライアント側から要求が来るごとに処理していました。たとえば、2 つの要求を同時に受け取り、最初の処理に 30 秒、次の処理に 1 秒かかるとすると、2 つめの要求を出したクライアントは最初の処理が完了するまで待たなければなりません。これは、各 CPU が異なる要求を同時に処理するマルチプロセッササーバー環境を利用できず、他の要求がサーバーによって処理することができるのに 1 つの要求の I/O の完了を待っている状態が生じ、望ましいものではありません。
Solaris 2.4 以降 の RPC ライブラリでは、サービス開発者がエンドユーザーにより高いパフォーマンスを提供するマルチスレッドサーバーを作成できる機能を追加しました。サーバーのマルチスレッドの 2 つのモード、自動マルチスレッドモードとユーザー・マルチスレッド・モードは、TI-RPC でサポートされます。
自動モードでは、サーバーは、クライアント要求を受信するごとに新規スレッドを自動的に作成します。このスレッドは要求を処理し、応答してから終了します。ユーザーモードでは、サービス開発者が、入って来るクライアント要求を同時に処理するスレッドを作成、管理します。自動モードはユーザーモードより使用はしやすいのですが、ユーザーモードの方が特別な要件を必要とするサービス開発者に対して柔軟性があります。
RPC マルチスレッド対応アプリケーションを作成する場合は常に、スレッドライブラリをリンクしなければなりません。コンパイルコマンドで -lthread を指定して、スレッドライブラリを最後にリンクするようにしなければなりません。
サーバー側のマルチスレッドをサポートする呼び出しでは、rpc_control() と svc_done() がサポートされています。これらの呼び出しによってサーバー側でマルチスレッド処理が行えるようになりました。rpc_control() 呼び出しがマルチスレッドモードを設定するために、自動モードとユーザーモードの両方で使用されます。サーバーが自動モードを使用する場合には、svc_done() を呼び出す必要はありません。ユーザーモードの場合には、サーバーが要求処理からのリソースを再要求できるようにするため、svc_done() は各クライアント要求が処理されてから呼び出されなければなりません。さらにマルチスレッド RPC サーバーは、svc_run() をマルチスレッド対応で呼び出さなければなりません。svc_getreqpoll() と svc_getreqset() は、MT アプリケーション対応ではありません。
サーバープログラムが新規インタフェース呼び出しを行わない場合には、デフォルトのモードのシングルスレッドモードのままです。
サーバーが使用しているモードに関係なく、RPC サーバー手続きはマルチスレッド対応にしなければなりません。通常これは、すべての静的変数とグロール変数が mutex ロックで保護される必要がある、ということです。相互排他と他の同期 API は、synch.h で定義されます。さまざまな同期インタフェースのリストは、condition(3THR)、rwlock(3THR)、mutex(3THR) を参照してください。
図 4-3 は、マルチスレッドモードのどちらかで実行されるサーバーの実行タイミングを示します。

サービス・トランスポート・ハンドル、SVCXPRT には、引き数を復号化するための領域と結果をコード化するための領域である 1 つのデータ領域があります。したがって、デフォルトでは、シングルスレッドモードであり、この構造は、これらの操作を行う関数を呼び出すスレッド間では自由に共有することはできません。ただし、サーバーが、マルチスレッド自動モードまたはユーザーモードにある場合には、この構造のコピーは、同時要求処理を可能にするために、サービスディスパッチ用のプログラムに引き渡されます。これらの状況では、ルーチンのマルチスレッド対応ではない一部のルーチンがマルチスレッド対応となります。特別に注意書きがない場合には、サーバーインタフェースは通常、マルチスレッド対応です。サーバー側のインタフェースについての詳細は、rpc_svc_calls(3NSL) のマニュアルページを参照してください。
マルチスレッド自動モードでは、RPC ライブラリはスレッドを作成し、管理することができます。サービス開発者が新規インタフェース呼び出し、rpc_control() を呼び出し、svc_run() を呼び出す前にサーバーをマルチスレッド自動モードにします。このモードでは、プログラマはサービス手続きがマルチスレッド対応であることを確認するだけで十分です。
rpc_control() の使用によって、アプリケーションでグローバル RPC 属性を設定できます。現在はサービス側の操作しかサポートしていません。 表 4-10 は、自動モード用に定義された rpc_control() 操作を示します。追加の情報については、rpc_control(3NSL) のマニュアルページを参照してください。
表 4-10 rpc_control() ライブラリルーチン|
マルチスレッドモードの設定 |
|
|
マルチスレッドの取得 |
|
|
最大スレッド数の設定 |
|
|
最大スレッド数の取得 |
|
|
現在アクティブなスレッドの合計数 |
|
|
RPC ライブラリ作成のスレッドの累積数 |
|
|
RPC ライブラリ内の thr_create エラー数 |
表 4-10 の get 演算は、RPC_SVC_MTMODE_GET() 以外はすべて、自動マルチスレッドモードにだけ適用されます。マルチスレッド・ユーザー・モードまたはデフォルトのシングル・スレッド・モードで使用する場合には、演算の結果は定義されません。
デフォルトでは、RPC ライブラリが一度に作成できるスレッドの最大数は 16 です。サーバーが 16 以上のクライアント要求を同時に処理する必要がある場合には、スレッドの最大数を指定して設定する必要があります。このパラメータは、サーバーによっていつでも設定することができ、これによってサーバー開発者はサーバーによって使用されるスレッドリソースの上限を設定できます。例 4-39 は、マルチスレッド自動モードに作成された RPC プログラムの例です。この例では、スレッドの最大数は 20 に設定されています。
マルチスレッドのパフォーマンスは、関数 svc_getargs() が、NULLPROCS 以外の手続きによって呼び出されるごとに、引き数 (この場合には xdr_void())がない場合でも改善されていきます。これはマルチスレッド自動モードとマルチスレッドユーザーモード両方の場合においてです。詳細は、rpc_svc_calls(3NSL) のマニュアルページを参照してください。
例 4-39 は、マルチスレッド自動モードでのサーバーを示したものです。
RPC マルチスレッド対応アプリケーションを作成する場合は常に、スレッドライブラリ内でリンクしなければなりません。コンパイルコマンドで -lthread を指定して、スレッドライブラリを最後にリンクするようにしなければなりません。
次のように入力して例 4-39 のプログラムを作成します。
$ cc time_svc.c -lnsl -lthread |
#include <stdio.h>
#include <rpc/rpc.h>
#include <synch.h>
#include <thread.h>
#include "time_prot.h"
void time_prog();
main(argc, argv)
int argc;
char *argv[];
{
int transpnum;
char *nettype;
int mode = RPC_SVC_MT_AUTO;
int max = 20; /* スレッド最大数を 20 に設定 */
if (argc > 2) {
fprintf(stderr, "usage: %s [nettype]¥n", argv[0]);
exit(1);
}
if (argc == 2)
nettype = argv[1];
else
nettype = "netpath";
if (!rpc_control(RPC_SVC_MTMODE_SET, &mode)) {
printf("RPC_SVC_MTMODE_SET: failed¥n");
exit(1);
}
if (!rpc_control(RPC_SVC_THRMAX_SET, &max)) {
printf("RPC_SVC_THRMAX_SET: failed¥n");
exit(1);
}
transpnum = svc_create( time_prog, TIME_PROG, TIME_VERS,
nettype);
if (transpnum == 0) {
fprintf(stderr, "%s: cannot create %s service.¥n",
argv[0], nettype);
exit(1);
}
svc_run();
}
/*
* サーバーのディスパッチプログラムです。RPC サーバーライブラリは、
* サーバーのディスパッチャルーチン time_prog () を実行するスレッドを
* 作成します。RPC ライブラリがスレッドを廃棄した後に行われます。
*/
static void
time_prog(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
switch (rqstp->rq_proc) {
case NULLPROC:
svc_sendreply(transp, xdr_void, NULL);
return;
case TIME_GET:
dotime(transp);
break;
default:
svcerr_noproc(transp);
return;
}
}
dotime(transp)
SVCXPRT *transp;
{
struct timev rslt;
time_t thetime;
thetime = time((time_t *)0);
rslt.second = thetime % 60;
thetime /= 60;
rslt.minute = thetime % 60;
thetime /= 60;
rslt.hour = thetime % 24;
if (!svc_sendreply(transp, xdr_timev,(caddr_t) &rslt)) {
svcerr_systemerr(transp);
}
}
|
例 4-40 は、サーバーの time_prot.h ヘッダーファイルを示します。
include <rpc/types.h>
struct timev {
int second;
int minute;
int hour;
};
typedef struct timev timev;
bool_t xdr_timev();
#define TIME_PROG 0x40000001
#define TIME_VERS 1
#define TIME_GET 1
|
マルチスレッド・ユーザー・モードでは、RPC ライブラリはスレッドを作成しません。このモードは、基本的には、シングルスレッド、またはデフォルトのモードのように作動します。唯一の違いは、データ構造のコピー (サービス・ディスパッチ・ルーチンへのトランスポートサービスなど) をマルチスレッド対応に引き渡す点です。
RPC サーバー開発者は、スレッドライブラリ全体のスレッドの作成と管理に対する責任を持ちます。ディスパッチルーチンでは、サービス開発者は、手続きの実行を新規作成のまたは既存のスレッドに割り当てることができます。thr_create() API は、さまざまな属性を持つスレッドを作成するために使用されます。すべてのスレッドのライブラリインタフェースは、thread.h で定義されます。詳細は、pthread_create(3THR) のマニュアルページを参照してください。
このモードは、サーバー開発者に幅広い柔軟性を提供しています。スレッドは、サービス要件に応じたスタックサイズを持ちます。スレッドは限定されます。異なる手続きは、異なる特長を持つスレッドによって実行されます。サービス開発者は、サービスの一部をシングルスレッドで実行できます。また、特定のスレッドに固有のシグナル処理を行うこともできます。
自動モードの場合と同じように、rpc_control() ライブラリは、ユーザーモードに切り換える場合に使用されます。表 4-10 に示した rpc_control() 演算 (RPC_SVC_MTMODE_GET() 以外) は、マルチスレッド自動モードにだけ適用されます。マルチスレッド・ユーザー・モードまたはシングルスレッドのデフォルトモードで使用すると、演算の結果が定義できません。
マルチスレッド・ユーザー・モードでは、サービス手続きは、戻しの前に svc_done() を呼び出さなければなりません。svc_done() は、クライアント要求が指定のサービス・トランスポート・ハンドルに向けたサービスに割り当てたリソースを解放しなければなりません。この機能は、クライアント要求がサービスされた後、あるいは応答の送信を妨げたエラーまたは異常な状態の後に呼び出されます。svc_done() が呼び出された後に、サービス・トランスポート・ハンドルは、サービス手続きによって参照されるべきではありません。例 4-41 は、マルチスレッド・ユーザー・モードでのサーバーを示します。
svc_done() は、マルチスレッド・ユーザー・モード内でだけ呼び出すことができます。詳細は、rpc_svc_calls(3NSL) のマニュアルページを参照してください。
#define SVC2_PROG 0x30000002
#define SVC2_VERS 1
#define SVC2_PROC_ADD 1)
#define SVC2_PROC_MULT 2
struct intpair {
u_short a;
u_short b;
};
typedef struct intpair intpair;
struct svc2_add_args {
int argument;
SVCXPRT *transp;
};
struct svc2_mult_args {
intpair mult_argument;
SVCXPRT *transp;
};
extern bool_t xdr_intpair();
#define NTHREADS_CONST 500
|
例 4-42 は、マルチスレッド・ユーザー・モードでのクライアントです。
#define _REENTRANT
#include <stdio.h>
#include <rpc/rpc.h>
#include <sys/uio.h>
#include <netconfig.h>
#include <netdb.h>
#include <rpc/nettype.h>
#include <thread.h>
#include "rpc_test.h"
void *doclient();
int NTHREADS;
struct thread_info {
thread_t client_id;
int client_status;
};
struct thread_info save_thread[NTHREADS_CONST];
main(argc, argv)
int argc;
char *argv[];
{
int index, ret;
int thread_status;
thread_t departedid, client_id;
char *hosts;
if (argc < 3) {
printf("Usage: do_operation [n] host¥n");
printf("¥twhere n is the number of threads¥n");
exit(1);
} else
if (argc == 3) {
NTHREADS = NTHREADS_CONST;
hosts = argv[1]; /* live_host */
} else {
NTHREADS = atoi(argv[1]);
hosts = argv[2];
}
for (index = 0; index < NTHREADS; index++){
if (ret = thr_create(NULL, NULL, doclient,
(void *) hosts, THR_BOUND, &client_id)){
printf("thr_create failed: return value %d", ret);
printf(" for %dth thread¥n", index);
exit(1);
}
save_thread[index].client_id = client_id;
}
for (index = 0; index < NTHREADS; index++){
if (thr_join(save_thread[index].client_id, &departedid,
(void *)
&thread_status)){
printf("thr_join failed for thread %d¥n",
save_thread[index].client_id);
exit(1);
}
save_thread[index].client_status = thread_status;
}
}
void *doclient(host)
char *host;
{
struct timeval tout;
enum clnt_stat test;
int result = 0;
u_short mult_result = 0;
int add_arg;
int EXP_RSLT;
intpair pair;
CLIENT *clnt;
if ((clnt = clnt_create(host, SVC2_PROG, SVC2_VERS, "udp"
==NULL) {
clnt_pcreateerror("clnt_create error: ");
thr_exit((void *) -1);
}
tout.tv_sec = 25;
tout.tv_usec = 0;
memset((char *) &result, 0, sizeof (result));
memset((char *) &mult_result, 0, sizeof (mult_result));
if (thr_self() % 2){
EXP_RSLT = thr_self() + 1;
add_arg = thr_self();
test = clnt_call(clnt, SVC2_PROC_ADD, (xdrproc_t) xdr_int,
(caddr_t) &add_arg, (xdrproc_t) xdr_int, (caddr_t) &result,
tout);
} else {
pair.a = (u_short) thr_self();
pair.b = (u_short) 1;
EXP_RSLT = pair.a * pair.b;
test = clnt_call(clnt, SVC2_PROC_MULT, (xdrproc_t)
xdr_intpair,
(caddr_t) &pair, (xdrproc_t) xdr_u_short,
(caddr_t) &mult_result, tout);
result = mult_result;
}
if (test != RPC_SUCCESS) {
printf("THREAD: %d clnt_call hav
thr_exit((void *) -1);
};
thr_exit((void *) 0);
}
|
例 4-43 は、マルチスレッド・ユーザー・モードのサーバー側を示します。マルチスレッドパフォーマンスは、関数 svc_getargs() が NULLPROC 以外の各手続きに呼び出される場合は、引き数 (この場合には xdr_void) がなくても改善されます。これは、マルチスレッド自動モードモードとマルチスレッドユーザーモードにおいてです。詳細は、rpc_svc_calls(3NSL) のマニュアルページを参照してください。
RPC マルチスレッド対応アプリケーションを作成する場合は常に、スレッドライブラリ内でリンクしなければなりません。コンパイルコマンドで -lthread を指定して、スレッドライブラリを最後にリンクするようにしなければなりません。
#define _REENTRANT
#include <stdio.h>
#include <rpc/rpc.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/uio.h>
#include <signal.h>
#include <thread.h>
#include "operations.h"
SVCXPRT *xprt;
void add_mult_prog();
void *svc2_add_worker();
void *svc2_mult_worker();
main(argc, argv)
int argc;
char **argv;
{
int transpnum;
char *nettype;
int mode = RPC_SVC_MT_USER;
if(rpc_control(RPC_SVC_MTMODE_SET,&mode) == FALSE){
printf(" rpc_control is failed to set AUTO mode¥n");
exit(0);
}
if (argc > 2) {
fprintf(stderr, "usage: %s [nettype]¥n", argv[0]);
exit(1);
}
if (argc == 2)
nettype = argv[1];
else
nettype = "netpath";
transpnum = svc_create(add_mult_prog, SVC2_PROG,
SVC2_VERS, nettype);
if (transpnum == 0) {
fprintf(stderr, "%s: cannot create %s service.¥n", argv[0],
nettype);
exit(1);
}
svc_run();
}
void add_mult_prog (rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
int argument;
u_short mult_arg();
intpair mult_argument;
bool_t (*xdr_argument)();
struct svc2_mult_args *sw_mult_data;
struct svc2_add_args *sw_add_data;
int ret;
thread_t worker_id;
switch (rqstp->rq_proc){
case NULLPROC:
svc_sendreply(transp, xdr_void, (char *) 0);
svc_done(transp);
break;
case SVC2_PROC_ADD:
xdr_argument = xdr_int;
(void) memset((char *) &argument, 0, sizeof (argument));
if (!svc_getargs(transp, xdr_argument,
(char *) &argument)){
printf("problem with getargs¥n");
svcerr_decode(transp);
exit(1);
}
sw_add_data = (struct svc2_add_args *)
malloc(sizeof (struct svc2_add_args));
sw_add_data->transp = transp;
sw_add_data->argument = argument;
if (ret = thr_create(NULL, THR_MIN_STACK + 16 * 1024,
svc2_add_worker, (void *) sw_add_data, THR_DETACHED,
printf("SERVER: thr_create failed:");
printf(" return value %d", ret);
printf(" for add thread¥n");
exit(1);
}
break;
case SVC2_PROC_MULT:
xdr_argument = xdr_intpair;
(void) memset((char *) &mult_argument, 0,
sizeof (mult_argument));
if (!svc_getargs(transp, xdr_argument,
(char *) &mult_argument)){
printf("problem with getargs¥n");
svcerr_decode(transp);
exit(1);
}
sw_mult_data = (struct svc2_mult_args *)
malloc(sizeof (struct svc2_mult_args));
sw_mult_data->transp = transp;
sw_mult_data->mult_argument.a = mult_argument.a;
sw_mult_data->mult_argument.b = mult_argument.b;
if (ret = thr_create(NULL, THR_MIN_STACK + 16 * 1024,
svc2_mult_worker, (void *) sw_mult_data, THR_DETACHED,
&worker_id)){
printf("SERVER: thr_create failed:");
printf("return value %d", ret);
printf("for multiply thread¥n");
exit(1);
break;
default:
svcerr_noproc(transp);
svc_done(transp);
break;
}
}
u_short mult_arg();
int add_one();
void *svc2_add_worker(add_arg)
struct svc2_add_args *add_arg;
{ int *result;
bool_t (*xdr_result)();
xdr_result = xdr_int;
result = *malloc(sizeof (int));
*result = add_one(add_arg->argument);
if (!svc_sendreply(add_arg->transp, xdr_result,
(caddr_t) result)){
printf("sendreply failed¥n");
svcerr_systemerr(add_arg->transp);
svc_done(add_arg->transp);
thr_exit((void *) -1);
}
svc_done(add_arg->transp);
thr_exit((void *) 0);
}
void *svc2_mult_worker(m_arg)
struct svc2_mult_args *m_arg;
{
u_short *result;
bool_t (*xdr_result)();
xdr_result = xdr_u_short;
result = (u_short *) malloc(sizeof (u_short));
*result = mult_arg(&m_arg->mult_argument);
if (!svc_sendreply(m_arg->transp, xdr_result,
(caddr_t) result)){
printf("sendreply failed¥n");
svcerr_systemerr(m_arg->transp);
svc_done(m_arg->transp);
thr_exit((void *) -1);
}
svc_done(m_arg->transp);
thr_exit((void *) 0);
}
u_short mult_arg(pair)
intpair *pair;
{
u_short result;
result = pair->a * pair->b;
return (result);}
int add_one(arg)
int arg;
{
return (++arg);
}
|
例 4-44 に示すサンプルプログラムは、あるホストのファイルを別のホストにコピーするプログラムです。RPC の send() 呼び出しで標準入力から読み込まれたデータがサーバ ーreceive() に送信され、サーバーの標準出力に書き出されます。また、このプログラムでは、1 つの XDR ルーチンでシリアライズとデシリアライズの両方を実行する方法も示します。ここでは、接続型トランスポートを使用します。
/*
* XDR ルーチン:
* 復号化時にネットワークを読み取り fp に書き込む
* 符号化時に fp を読み取りネットワークに書き込む
*/
#include <stdio.h>
#include <rpc/rpc.h>
bool_t
xdr_rcp(xdrs, fp)
XDR *xdrs;
FILE *fp;
{
unsigned long size;
char buf[BUFSIZ], *p;
if (xdrs->x_op == XDR_FREE) /* 解放するものなし */
return(TRUE);
while (TRUE) {
if (xdrs->x_op == XDR_ENCODE) {
if ((size = fread( buf, sizeof( char ), BUFSIZ, fp))
== 0 && ferror(fp)) {
fprintf(stderr, "can't fread¥n");
return(FALSE);
} else
return(TRUE);
}
p = buf;
if (! xdr_bytes( xdrs, &p, &size, BUFSIZ))
return(0);
if (size == 0)
return(1);
if (xdrs->x_op == XDR_DECODE) {
if (fwrite( buf, sizeof(char), size, fp) != size) {
fprintf(stderr, "can't fwrite¥n");
return(FALSE);
} else
return(TRUE);
}
}
}
|
例 4-45 と 例 4-46 には、例 4-44 に示した xdr_rcp()ルーチンだけでシリアライズとデシリアライズを行うプログラムを示します。
/* 送信側のルーチン */
#include <stdio.h>
#include <netdb.h>
#include <rpc/rpc.h>
#include <sys/socket.h>
#include <sys/time.h>
#include "rcp.h"
main(argc, argv)
int argc;
char **argv;
{
int xdr_rcp();
if (argc != 2 7) {
fprintf(stderr, "usage: %s servername¥n", argv[0]);
exit(1);
}
if( callcots( argv[1], RCPPROG, RCPPROC, RCPVERS, xdr_rcp,
stdin,
xdr_void, 0 ) != 0 )
exit(1);
exit(0);
}
callcots(host, prognum, procnum, versnum, inproc, in, outproc,
out)
char *host, *in, *out;
xdrproc_t inproc, outproc;
{
enum clnt_stat clnt_stat;
register CLIENT *client;
struct timeval total_timeout;
if ((client = clnt_create( host, prognum, versnum,
"circuit_v")
== (CLIENT *) NULL)) {
clnt_pcreateerror("clnt_create");
return(-1);
}
total_timeout.tv_sec = 20;
total_timeout.tv_usec = 0;
clnt_stat = clnt_call(client, procnum, inproc, in, outproc,
out,
total_timeout);
clnt_destroy(client);
if (clnt_stat != RPC_SUCCESS)
clnt_perror("callcots");
return((int)clnt_stat);
}
|
例 4-46 では、受信側のルーチンを定義します。サーバー側では、xdr_rcp() がすべての処理を自動的に実行することに注意してください。
/*
* 受信側ルーチン
*/
#include <stdio.h>
#include <rpc/rpc.h
#include "rcp.h"
main()
{
void rcp_service();
if (svc_create(rpc_service,RCPPROG,RCPVERS,"circuit_v") == 0) {
fprintf(stderr, "svc_create: errpr¥n");
exit(1);
}
svc_run(); /* この関数は戻らない */
fprintf(stderr, "svc_run should never return¥n");
}
void
rcp_service(rqstp, transp)
register struct svc_req *rqstp;
register SVCXPRT *transp;
{
switch(rqstp->rq_proc) {
case NULLPROC:
if (svc_sendreply(transp, xdr_void, (caddr_t) NULL) == FALSE)
fprintf(stderr, "err: rcp_service");
return;
case RCPPROC:
if (!svc_getargs( transp, xdr_rcp, stdout)) {
svcerr_decode(transp);
return();
}
if(!svc_sendreply(transp, xdr_void, (caddr_t) NULL)) {
fprintf(stderr, "can't reply¥n");
return();
}
return();
default:
svcerr_noproc(transp);
return();
}
}
|
XDR ルーチンは通常、データのシリアライズとデシリアライズに使用します。XDR ルーチンは、多くの場合、メモリーを自動的に割り当て、そのメモリーを解放します。一般に、配列や構造体へのポインタの代わりに NULL ポインタを渡されると、XDR ルーチンはデシリアライズを行うときに自分でメモリーを割り当てるようにします。次の例の xdr_chararr1() では、長さが SIZE の固定長配列を処理するようになっており、必要に応じてメモリーを割り当てることができません。
xdr_chararr1(xdrsp, chararr)
XDR *xdrsp;
char chararr[];
{
char *p;
int len;
p = chararr;
len = SIZE;
return (xdr_bytes(xdrsp, &p, &len, SIZE));
}
|
chararr にすでに領域が確保されている場合は、サーバー側から次のように呼び出すことができます。
char chararr[SIZE]; svc_getargs(transp, xdr_chararr1, chararr); |
XDR ルーチンや RPC ルーチンにデータを引き渡すための構造体は、基底アドレスが、アーキテクチャで決められた境界になるようなメモリーの割り当てにならなければなりません。XDR ルーチンでメモリーを割り当てるときも、次の点に注意して割り当てます。
呼び出し側が要求した場合にメモリー割り当てを行う
割り当てたメモリーへのポインタを返す
次の例では、第 2 引数が NULL ポインタの場合、デシリアライズされたデータを入れるためのメモリーが割り当てられます。
xdr_chararr2(xdrsp, chararrp)
XDR *xdrsp;
char **chararrp;
{
int len;
len = SIZE;
return (xdr_bytes(xdrsp, charrarrp, &len, SIZE));
}
|
これに対する RPC 呼び出しを次に示します。
char *arrptr; arrptr = NULL; svc_getargs(transp, xdr_chararr2, &arrptr); /* * ここで戻り値を使用 */ svc_freeargs(transp, xdr_chararr2, &arrptr); |
文字配列は、使用後に svc_freeargs() を使用して解放します。svc_freeargs() は、第 2 引数に NULL ポインタを渡された場合は何もしません。
これまでに説明したことをまとめると、次のようになります。
svc_getargs() は、XDR ルーチンを呼び出してデシリアライズを行います。
トランスポート独立の RPC ルーチン (TI-RPC ルーチン) を使用すると、アプリケーション開発者はトランスポート層へのアクセスレベルを自由に選択できます。最上位レベルのルーチンは、トランスポートが完全に抽象化されて、本当の意味でトランスポート独立になっています。下位レベルのルーチンを使用すると、旧バージョンと同じように個々のトランスポートに依存したアクセスレベルになります。
この節は、トランスポート特定 RPC (TS-RPC) アプリケーションを TI-RPC へ移行するための非公式ガイドになっています。表 4-11 では、いくつかのルーチンを選んで相違点を示します。ソケットとトランスポート層インタフェース (TLI) の移行の問題点についての詳細は、『Transport Interfaces Programming Guide』を参照してください。
TCP または UDP に基づくアプリケーションはバイナリ互換モードで実行できます。すべてのソースファイルをコンパイルし直したり、リンクし直したりできるのは、一部のアプリケーションだけです。RPC 呼び出しだけを使用し、ソケット、TCP、UDP に固有の機能を使用していないアプリケーションがこれに当たります。
ソケットセマンティクスに依存していたり、TCP や UDP の固有の機能を使用しているアプリケーションでは、コードの変更や追加が必要な場合があります。ホストアドレス形式を使用したり、バークレイ UNIX の特権ポートを使用するアプリケーションがこれに当たります。
ライブラリ内部や個々のソケット仕様に依存していたり、特定のトランスポートアドレスに依存するアプリケーションは、移行の手間も大きく、本質的な変更が必要な場合もあります。
アプリケーションがトランスポート独立になるため、より多くのトランスポート上で実行できます。
アプリケーションの効率を改善する新規インタフェースが使用できます。
バイナリレベルの互換性の影響は、ネイティブモードより少なくなります。
旧インタフェースは、将来のバージョンで使用できなくなる可能性があります。
IPv6 は、IPv4 の後継バージョンで、今日のインターネットテクノロジーにおいて、最も一般的に使用される階層 2 のプロトコルです。また、IPv6 は IP の次世代 (IPng) とも呼ばれています。詳細については、『Solaris のシステム管理 (第 3 巻)』を参照してください。
ユーザーは、IPv4 と IPv6 の両方を使用できます。COTS (コネクション型のトランスポートサービス) を使用する場合、アプリケーションにより、使用する「スタック」が選択されます。この場合、TCP または CLTS (コネクションレス型のトランスポートサービス) を選択できます。
次の図では、IPv4 または IPv6 プロトコルスタックを経由して実行される、典型的な RPC アプリケーションを示しています。

IPv6 がサポートされるのは、TI-RPC アプリケーションだけです。現在、TS-RPC では、IPv6 をサポートしていません。TI-RPC におけるトランスポートの選択は、NETPATH 環境変数、または /etc/netconfig のいずれかによって制御されます。IPv4 または IPv6 の代わりに、TCP または UDP を選択するかどうかは、/etc/netconfig 内の該当エントリの順序によって決まります。/etc/netconfig には、IPv6 に関連する新しいエントリが 2 つあります。また、デフォルトでは、これらのエントリは、ファイルの最初の 2 つのエントリです。まず、TI-RPC が IPv6 を試行し、失敗すると、IPv4 を試行します。この場合、RPC アプリケーション自体に変更が無いこと (つまり、トランスポートに関する情報がまったく無く、トップレベルのインタフェースを使用して書かれたものであること) が必要条件です。
|
clnt_create() |
svc_create() |
|
clnt_call() |
clnt_create_timed() |
このインタフェースでは、/etc/netconfig 内の最初のエントリが IPv6 である場合、IPv6 が自動的に選択されます。
IPv6 を使用すると、アプリケーションは、RPCBIND プロトコルの V3 と V4 だけを使用して、サービスバーと番号を配置できます。
|
clnt_tli_create() |
svc_tli_create() |
|
clnt_dg_create() |
svc_dg_create() |
|
clnt_vc_create() |
svc_vc_create() |
上記のいずれかのインタフェースを使用する場合は、コードを移植する必要があります。
ネットワーク関数は libc から外されました。コンパイル時には libnsl を明示的に指定して、ネットワーク・サービス・ルーチンをリンクする必要があります。
旧インタフェースの多くは libnsl ライブラリでもサポートされていますが、TCP と UDP でしか使用できません。それ以外の新たなトランスポートを利用するには、新インタフェースを使用する必要があります。
トランスポート独立にするには、アドレスを直接使用できません。すなわち、アプリケーションでアドレス変換を行う必要があります。
トランスポート独立型の RPC とトランスポート特定の RPC との主な相違点を表 4-11 に示します。TI-RPC と TS-RPC の比較については、「旧バージョンとの比較」 のサンプルプログラムを参照してください。
表 4-11 TI-RPC と TS-RPC の相違点
この節では、RPC ライブラリ関数を機能別にグループ化して示します。各グループ内では、旧バージョンと同じ関数、機能が追加された関数、旧バージョンにはなかった新規関数に分けて示します。
アスタリスクの付いた関数は、新バージョンへの移行期間はサポートされていますが、Solaris の将来のバージョンではなくなる可能性があります。
次の関数は、旧バージョンと同じで、現在の SunOS で使用できます。
clnt_destroy clnt_pcreateerror *clntraw_create clnt_spcreateerror *clnttcp_create *clntudp_bufcreate *clntudp_create clnt_control clnt_create clnt_create_timed clnt_create_vers clnt_dg_create clnt_raw_create clnt_tli_create clnt_tp_create clnt_tp_create_timed clnt_vc_create
次の関数は、旧バージョンと同じで、現在の SunOS で使用できます。
svc_destroy svcfd_create *svc_raw_create *svc_tp_create *svcudp_create *svc_udp_bufcreate svc_create svc_dg_create svc_fd_create svc_raw_create svc_tli_create svc_tp_create svc_vc_create
次の関数は、旧バージョンと同じで、現在の SunOS で使用できます。
*registerrpc *svc_register *svc_unregister xprt_register xprt_unregister rpc_reg svc_reg svc_unreg
次の関数は、旧バージョンと同じで、現在の SunOS で使用できます。
*callrpc clnt_call *svc_getcaller - IP に基づくトランスポートでのみ使用可 rpc_call svc_getrpccaller
次の関数の機能は旧バージョンと同じです。旧バージョンとの互換性を保つためにだけサポートされています。
*clnt_broadcast
clnt_broadcast() は portmap サービスにだけブロードキャストできます。
portmap と rpcbind の両方にブロードキャストできる次の関数が現在の SunOS で使用できます。
rpc_broadcast
TI-RPC ライブラリ関数は、portmap と rpcbind の両方で使用できますが、それぞれサービスが異なるため、次のように 2 組の関数が提供されています。
次の関数は portmap と共に使用します。
pmap_set pmap_unset pmap_getport pmap_getmaps pmap_rmtcall
次の関数は rpcbind と共に使用します。
rpcb_set rpcb_unset rpcb_getaddr rpcb_getmaps rpcb_rmtcall
次の関数の機能は旧バージョンと同じです。旧バージョンとの互換性を保つためにだけサポートされています。
authdes_create authunix_create authunix_create_default authdes_seccreate authsys_create authsys_create_default
現バージョンの rpcbind ではタイムサービス (主として、安全な RPC のためにクライアント側とサーバー側の時間を同期させるときに使用) が提供されており、rpcb_gettime() 関数で利用できます。pmap_getport() と rpcb_getaddr() は、登録サービスのポート番号を取り出すときに使用します。サーバーでバージョンが 2、3、4 の rcpbind が実行されている場合には、rpcb_getaddr() を使用します。pmap_getport() はバージョン 2 が実行されている場合しか使用できません。
例 4-47 と 例 4-48では、クライアント作成部分が TS-RPC と TI-RPC とでどう違うかを示します。どちらのプログラムも次のことを実行します。
UDP 記述子を作成します。
遠隔ホストの RPC 結合プロセスと通信してサービスアドレスを得ます。
遠隔サービスのアドレスを記述子に結合します。
クライアントハンドルを作成してタイムアウト値を設定します。
struct hostent *h;
struct sockaddr_in sin;
int sock = RPC_ANYSOCK;
u_short port;
struct timeval wait;
if ((h = gethostbyname( "host" )) == (struct hostent *) NULL)
{
syslog(LOG_ERR, "gethostbyname failed");
exit(1);
}
sin.sin_addr.s_addr = *(u_int *) hp->h_addr;
if ((port = pmap_getport(&sin, PROGRAM, VERSION, "udp")) == 0) {
syslog (LOG_ERR, "pmap_getport failed");
exit(1);
} else
sin.sin_port = htons(port);
wait.tv_sec = 25;
wait.tv_usec = 0;
clntudp_create(&sin, PROGRAM, VERSION, wait, &sock);
|
TI-RPC では、UDP トランスポートは netid udp を持つものとみなします。netid はよく知られた名前でなくてもかまいません。
struct netconfig *nconf;
struct netconfig *getnetconfigent();
struct t_bind *tbind;
struct timeval wait;
nconf = getnetconfigent("udp");
if (nconf == (struct netconfig *) NULL) {
syslog(LOG_ERR, "getnetconfigent for udp failed");
exit(1);
}
fd = t_open(nconf->nc_device, O_RDWR, (struct t_info *)NULL);
if (fd == -1) {
syslog(LOG_ERR, "t_open failed");
exit(1);
}
tbind = (struct t_bind *) t_alloc(fd, T_BIND, T_ADDR);
if (tbind == (struct t_bind *) NULL) {
syslog(LOG_ERR, "t_bind failed");
exit(1);
}
if (rpcb_getaddr( PROGRAM, VERSION, nconf, &tbind->addr, "host")
== FALSE) {
syslog(LOG_ERR, "rpcb_getaddr failed");
exit(1);
}
cl = clnt_tli_create(fd, nconf, &tbind->addr, PROGRAM, VERSION,
0, 0);
(void) t_free((char *) tbind, T_BIND);
if (cl == (CLIENT *) NULL) {
syslog(LOG_ERR, "clnt_tli_create failed");
exit(1);
}
wait.tv_sec = 25;
wait.tv_usec = 0;
clnt_control(cl, CLSET_TIMEOUT, (char *) &wait);
|
例 4-49 と例 4-50では、ブロードキャスト部分が旧バージョンと SunOS 5.x とでどう違うかを示します。SunOS 4.x の clnt_broadcast() は SunOS 5.x の rpc_broadcast() とほぼ同じです。大きく異なるのは、collectnames() 関数で重複アドレスを削除し、ブロードキャストに応答したホスト名を表示する点です。
statstime sw;
extern int collectnames();
clnt_broadcast(RSTATPROG, RSTATVERS_TIME, RSTATPROC_STATS,
xdr_void, NULL, xdr_statstime, &sw, collectnames);
...
collectnames(resultsp, raddrp)
char *resultsp;
struct sockaddr_in *raddrp;
{
u_int addr;
struct entry *entryp, *lim;
struct hostent *hp;
extern int curentry;
/* 重複アドレスはカット */
addr = raddrp->sin_addr.s_addr;
lim = entry + curentry;
for (entryp = entry; entryp < lim; entryp++)
if (addr == entryp->addr)
return (0);
...
/* ホスト名がわかればホスト名、わからなければアドレスを表示 */
hp = gethostbyaddr(&raddrp->sin_addr.s_addr, sizeof(u_int),
AF_INET);
if( hp == (struct hostent *) NULL)
printf("0x%x", addr);
else
printf("%s", hp->h_name);
}
|
例 4-50 は、TI-RPC におけるブロードキャストを示します。
statstime sw;
extern int collectnames();
rpc_broadcast(RSTATPROG, RSTATVERS_TIME, RSTATPROC_STATS,
xdr_void, NULL, xdr_statstime, &sw, collectnames, (char *)
0);
...
collectnames(resultsp, taddr, nconf)
char *resultsp;
struct t_bind *taddr;
struct netconfig *nconf;
{
struct entry *entryp, *lim;
struct nd_hostservlist *hs;
extern int curentry;
extern int netbufeq();
/* 重複アドレスはカット */
lim = entry + curentry;
for (entryp = entry; entryp < lim; entryp++)
if (netbufeq( &taddr->addr, entryp->addr))
return (0);
...
/* ホスト名がわかればホスト名、わからなければアドレスを表示 */
if (netdir_getbyaddr( nconf, &hs, &taddr->addr ) == ND_OK)
printf("%s", hs->h_hostservs->h_host);
else {
char *uaddr = taddr2uaddr(nconf, &taddr->addr);
if (uaddr) {
printf("%s¥n", uaddr);
(void) free(uaddr);
} else
printf("unknown");
}
}
netbufeq(a, b)
struct netbuf *a, *b;
{
return(a->len == b->len && !memcmp( a->buf, b->buf, a->len));
}
|