オペレーティングシステム

RPC(Remote Procedure Call)からネットワークコンピューティングへ（その１）

「オペレーティングシステム」（第１４回目）

今井慈郎（imai@eng.kagawa-u.ac.jp）

RPC：RemoteProcedureCallからネットワークコンピューティングへ

• RPC: Remote Procedure Call とは

• RPCからサーバクライアントシステムへ

• サーバ・クライアント(S/C or C/S)とは

RPCとは（・・の背景）

• そもそも「手続き（Procedure）」とは、何か？

• あるまとまった処理を呼び出して使う。プログラム作成が容易に。

• 「サブルーチン」呼出し、「関数」呼出しは既にお馴染み。

• 類似の言葉：ライブラリ呼出し（library call）

• printf, scanf, ….sprinf/fprintfなど

RPCとは（・・の背景２）

• 「手続き（Procedure）」を呼び出すので、「手続き呼出し（Procedure Call）」と言う。

• 利用側：あるまとまった処理を呼び出して使う。では、提供する側は？

• ライブラリは「まさに、提供する側」

• 同じように「呼び出す」ものに「System Call」がある。少し違うのはリンクする必要なし。

• 「動的リンキング」を思い出して。

RPCとは（・・の背景３）

• 静的リンクなら「手続き（Procedure）」を提

供するライブラリも自身のプログラム内に所有。しかし、動的リンクなら「どこかにあれば良い」（適当に実行時にリンクして使用できるので）。

• この発想の延長に「どこかにある手続きを呼び出して利用する」という発想が・・・「遠隔手続き呼出し（Remote Procedure Call）」となる。要するに他力本願。

RPCとは（その１）

RPCの解説

• A communication mechanism that allows

computers to communicate with one another over

a network.

• An RPC consists of a procedure identifier,

parameters passed to the procedure, and a value

returned to the caller (client computer) after the

procedure has executed on the remote system

(server computer).

出典 http://ejje.weblio.jp/content/RPC

RPCとは（その２）

• ネットワークによって接続された他のコンピュータ上でプログラムを呼び出し、実行させるための手法。あるいは、そのためのプロトコル。

• RPCでは、プログラムの実行に用いられる

サブルーチンの呼び出し（プロシージャコール）を、ネットワークを通じたマシンに対し実行し、遠隔地にあるマシン上で処理を実現。

出典 http://www.weblio.jp/content/RPC

RPCとは（その３）

• RPCを用いることで、ネットワークを通じて

他のマシンに処理を行わせ、その処理結果だけを（ネットワークなどを介して）受け取ることが可能。

• 【比較】ローカルマシンにおいて行われる通常の呼出し：プロシージャコールを区別する意味で、特にローカルプロシージャコール（LPC）と呼称。

出典 http://www.weblio.jp/content/RPC

後付け？

RPCとは（その４）

• プログラムを実行するアプリケーションソフトの側では、RPCかLPCか、などの違いを意識することなく、呼び出す（Call 依頼する）ことができる仕組みが実現。

• RPCは、クライアント・サーバーシステムや

分散処理（分散コンピューティング）技術を実現する仕組みとして「RPC」を利用。

ネットワークの隆盛期とマッチ

RPCとは（その５）

• 故Sun Microsystems(1982 - 2010)が開発した①NFS（Network File System）や②DCE（Distributed

Computing Environment）あるいはMicrosoftの分散オブジェクト技術③DCOM（Distributed

Component Object Model）などでは基幹技術のひとつとして採用。

• RPCを実行するためのプロトコル：HTTPを通じてXML形式のデータをやり取りするXML-RPCやJavaを使用するJAX-RPCなどが提案され実装された（利便性の向上）。

RPCとは（その６）

• UNIXの初期における実装方式はApollo

Computer (1980 - 1989)の“Network

Computing System(NCS)” であり、NCSは後にOSFのDistributed Computing Environment

(DCE) においてDCE/RPCの基盤として使用。その約10年後、MicrosoftがDCE/RPCを同社のRPC (MSRPC) の基盤として採用（DCOMの実装に使用）。

出典 https://ja.wikipedia.org/wiki/RPC

RPCとは（その７）

• UNIXで最初に広く使われるようになったRPC

実装モデルはSun Microsystemsの“ONC RPC”

であり、NFSの基盤として使用（ONC RPCは現

在でも、いくつか改良が施され、静かに、しかし幅広く使用される）。

出典 https://ja.wikipedia.org/wiki/RPC

RPCとは（その８）

• 利点として、遠隔相互作用の詳細を明示的にコーディングする必要がなく、プログラマはローカルなサブルーチン呼出しと基本的に同じコードをリモート呼び出しについても利用可能。

RPCとは（その９）

• RPCを行うソフトウェアがオブジェクト指向プログラミングに基づく場合、RPC のことをリモート呼出し（remote invocation）あるいはリモートメソッド呼出し （remote method

invocation，RMI）と呼ぶことも（Java RMIなど）。

• 実は、Javaを開発した企業がSUNでネットワークの守護神のような存在。

➡ Invocation （起動）

RPCとは（その１０）

• RPCクライアント側：実行する手続きと引数と

を要求メッセージとして、既知のリモートサーバに送信（メッセージパッシング）⇒ RPCを開始。

• サーバ側がRPCを処理している間，クライア

ント側は実行がブロック（イベント待ちのためWait状態へ）。・・Blocking通信と同じ

RPCとは（その１１）

• サーバ上でメッセージが処理され、応答がクライアントに戻ってくると、クライアント上のプロセスは処理を続行する。

• すなわち、Wait状態からReady状態へ、そして実行状態に移行。

同期型RPCの流れはBlocking型のため処理効率は良くない（ご存じの通り！）

RPCとは（その１２）

• RPCが通常のローカル呼出しと比べて違う重

要な点：予測できないネットワーク上のトラブルでRPC自体が失敗する可能性がある点。

またそのような場合でも，手続きが実際に実行されたかどうかをクライアントが知ることができないことも問題。 （対策は個別になされる）

参考文献 http://www.ncad.co.jp/~komata/c-kouza15.htm

RPCとは（その１３）

• RPCプロトコルの実装によって微妙な違いを

もった多くのバリエーションが存在し、残念ながら相互に互換性なし。

• 同期する利点より欠点の方が・・・

参考文献 http://www.ncad.co.jp/~komata/c-kouza15.htm

RPC：RemoteProcedureCallからネットワークコンピューティングへ

• RPC: Remote Procedure Call とは

• RPCからサーバクライアントシステムへ

• サーバ・クライアント(S/C or C/S)とは

RPCからサーバ・クライアントへ

• RPCはクライアント側でもサーバ側でも利用可能。

• もちろん、クライアント側は処理を依頼する側であり、サーバ側は依頼された処理を実際に実行する側。

Client Server

Client App

Client RPC

Server APP

Server RPC

処理を依頼 処理を実行

RPCによるClient・Server間の通信

ネットワーク（Online）

Runtime Routine

出典 https://i-msdn.sec.s-msft.com/dynimg/IC234867.gif

同期型RPCの動作手順（１）

1. アプリケーションによって呼出しが発行。

2. RPC ランタイムがクライアント側で呼出し（メッセージ）をサーバへ送信。

その間，RPC 呼出しを発行したクライアント

側のスレッドは，呼出し（要求）が完了する（結果が戻ってくる）まで RPC ランタイムで待機。 Wait状態

出典 https://i-msdn.sec.s-msft.com/dynimg/IC234867.gif

出典 https://i-msdn.sec.s-msft.com/dynimg/IC234867.gif

出典 https://i-msdn.sec.s-msft.com/dynimg/IC234867.gif

同期型RPCの動作手順（２）

3. 呼出しは，サーバ側の RPC ランタイムによってディスパッチ。

4. サーバアプリはリモート呼出しを実行。コントロールは，サーバ RPC ランタイムへ戻る。

5. サーバ RPC ランタイムはクライアントに応答を返信。

6. クライアントスレッドのブロックは解除。RPC

呼出しが完了（クライアントアプリケーションは処理を続行）。

出典 https://i-msdn.sec.s-msft.com/dynimg/IC234867.gif

出典 https://i-msdn.sec.s-msft.com/dynimg/IC234867.gif

RPCとは（同期型）

同期型RPCの流れはBlocking型のため処理効率は良くない（ご存じの通り！）

そこで「非同期型」を・・・（しかし、あくまで紹介程度）

非同期 RPC とは？（その１）

• 非同期 RPC とは・・同期 RPC メカニズムの拡張機能のひとつ。

• 同期 RPC では、RPC を発行したスレッドは RPC 呼出しが完了するまでクライアントをブロック。一方、非同期 RPC では、呼出

しを発行したスレッドは実行を継続し、後で結果を収集することが可能。

ちょっと複雑だが、処理効率は良くなる

出典 https://msdn.microsoft.com/ja-jp/library/ms811209.aspx

非同期 RPC とは？（その２）

（ちょっと日本語が変ですが）

• クライアントは、非同期 RPC 呼出しを渡します。コントロールはクライアントスレッド

に戻ります。スレッドはほかの作業を継続することができます。

• RPC ランタイムは、クライアント用に要求をサーバーに送信します。

出典 https://msdn.microsoft.com/ja-jp/library/ms811209.aspx

非同期 RPC とは？（その３）

（ちょっと日本語が変ですが）

• 要求はサーバーにディスパッチされます。サーバーアプリケーションは、リモート呼

び出しの実行を開始します。コントロールはサーバー RPC ランタイムに戻りますが、サーバー側の呼び出しは完了しません。

• サーバーは呼び出しを完了します。

• 応答がクライアントに返信されます。

出典 https://msdn.microsoft.com/ja-jp/library/ms811209.aspx

非同期 RPC とは？（その４）

（ちょっと日本語が変ですが）

• クライアントは、応答が受信されたことを通知されます。

• クライアントは RPC ランタイムに対して呼

び出しを戻して、応答を収集します。この時点で、非同期 RPC は完了します。

出典 https://msdn.microsoft.com/ja-jp/library/ms811209.aspx

出典 https://social.msdn.microsoft.com/Forums/ja-JP/9affb83c-7761-47db-b58b-c6176f23d0b9/c?forum=csharpgeneralja

出典 http://tsubalog.hatenablog.com/entry/about_ref_and_out_in_cshap

出典 http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_022/csharp_abc01.html

クライアント上における同期 RPC と非同期 RPC の比較 雰囲気だけ

同期 RPC

Function CallFoo () {

..

// 同期 RPC を呼び出します。

x = Foo(a, b, c);

// この時点で、同期 RPC は完了します。

// 戻り値と out パラメータは有効です。

}

非同期 RPC

Function SubmitFoo () {

..

// 非同期 RPC 呼び出しを渡します。

// 非同期ハンドルを初期化します。

RpcAsyncInitializeHandle(pAsync);

Foo (pAsync, a, b, c);

..

// ほかの作業を実行します。

}

Function FooComplete () {

// アプリケーションに通知されたとき、上記の RPC

呼び出しは完了します。

Status = RpcAsyncCompleteCall (pAsync, &x);

// 戻り値と out パラメータはここで有効です。

}

サーバ上における同期 RPC と非同期 RPC の比較 雰囲気だけ

同期 RPC

FooManagerRoutine ()

{

// これはリモートアプリケーションコードです。

// 作業を実行し、RPC ランタイムに戻ります。

}

非同期 RPC

FooAsyncManagerRoutine (pAsync) {

// ここから、論理呼び出しが開始します。

// 作業を実行します。

// RPC ランタイムに戻ります。論理 RPC 呼び出しはまだ完了していません。

//

}

CompleteFooAsyncCall () {

// 論理呼び出しはもうすぐ完了します。

Status = RpcAsyncCompleteCall (pAsync, &retval);

// 論理呼び出しは完了しました。非同期ハンドルは無効になりました。

}

RPCのメリットと問題（その１）Web サービスのマイグレーション・シナリオ:

• JAX-RPC から JAX-WS および JAXB へ

• このトピックでは、Java API for XML-based

RPC (JAX-RPC) Web サービスを Java API

for XML-Based Web Services (JAX-WS) および Java Architecture for XML Binding

(JAXB) Web サービスにマイグレーション。

出典（IBM) http://www-

01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/rwbs

_migjaxrpc2jaxws.html?lang=ja

RPCのメリットと問題（その２）• WebSphere® Application Server で使用可能

なツール変更について、開発環境によって、ユーザがほとんど意識しないで済む。

• 例）XML で指定されるデータによって、JAX-RPC サービスで使用されたメソッドを、ほとんど、あるいは全く変更せずに JAX-

WS サービスでも使用可能。

• 場合によって、JAX-WS サービスで変更が必要になるかも。

RPCのメリットと問題（その３）

• Java EE 環境では互換性が強調されているので、より新しい JAX-WS および JAXB

仕様をサポートするほとんどのアプリケーション・サーバでは、引き続き従来の JAX-

RPC 仕様をサポート。

RPCのメリットと問題（その４）

• 従って、既存のWeb サービスを JAX-RPC

ベースのままにしておいて、JAX-WS および JAXB プログラミング・モデルを使用して新規のWeb サービスを開発することが可能。

➡ RPCのクライアントはそのまま。RPCのサーバ側のみを修正or新規での開発が可能となる！

RPCのメリットと問題（その５）

• しかし、時間経過により、アプリケーションの改訂と再作成が行われ、やがては JAX-

RPC ベースのWeb サービスを JAX-WS

および JAXB プログラミング・モデルに基づくWeb サービスにマイグレーションする

のが最善方針となる時期が到来する可能性あり。 ➡クライアント側も変更

RPCのメリットと問題（その６）

• ソフトウェアベンダが、新規プログラミング・モデルでのみ使用可能なサービスの品質が得られるように機能強化することを選択することが原因

• Windowsユーザならご存じの通り

RPCとは（Googleの事例紹介）

• Googleが発表したgRPC ・・・2015年5月にRFCとして公開されたばかりのHTTP/2を標準でサポートした新しいRPCフレームワーク。効率的で拡張性の高いAPIや当時流行のマイクロサービスの作成をサポート。

• Goでのサンプルアプリケーションの作成を通してこのgRPCの通信を試行（という記事が以下のURL）。

http://www.apps-gcp.com/grpc-go/

出典 http://www.apps-gcp.com/wordpress/wp-

content/uploads/2015/09/grpc_concept_diagram_00.png

gRPCのサーバ・クライアントは相互に多様な環境（Google内部サーバからユーザのデスクトップ環境まで）で通信でき，gRPCがサポートしている言語（C++, Java, Go, Python, Ruby, Node.js,

Android Java, C#, Objective-C, PHP）で記述可能

並行プロセス（Concurrent Process）

• 並行プロセスとは

• 競合と協調

• プロセス間の同期

• プロセス間通信

• プロセス間通信の拡張

プロセス間通信の拡張（その１）

プロセスAとプロセスBが機能を分散し，一方がサービスを提供する「サーバ(server)」として，他方がサービスを依頼する「クライアント(client)」として，

通信しつつ処理を進める「サーバクライアント方式(server-client computing)」．

１対１のみならず，基本的に，多（クライアント）対１（サーバ）の通信を前提（容易に多対多に拡張可能）に拡張可能．

ネットワーク・コンピューティングへ

サーバクライアント方式は現在，もっとも利用頻度の高いプロセス間通信の形態 ・・次回すこし詳しく説明

プロセス間通信の拡張（その２）

機能分散の結果，プロセスAでは処理は担当せず，要求を発するのみ．それをプロセスBで処理することになる．

ちょうど，前者をメインルーチンに，後者をサブルーチンに見立てることが可能．あたかも，遠隔で（プロセス間で）サブルーチン呼出しを行っていると見なせる．

この操作を「遠隔手続き呼出し(remote procedure

call，RPCと略記)」と呼称．

ネットワーク・コンピューティングへ