#json-rpc

noknow renewal dev progress.

Open vSwitch のデータベースは JSON-RPC を介してデータをやり取りする。 例えば「ブリッジを追加します」とか「ポートにオプション情報が付与されました」とか。 詳しい仕様については Open vSwitch のリポジトリの ovsdb/SPEC に記述されている。 ただ、これを初めから読んで理解するのは非常にしんどいので、まずはとっかかりとして実際に流れている通信内容をモニタしたい。

Open vSwitch のデータベースとおしゃべりするための JSON-RPC は over UNIX ドメインソケットで実現されている。 つまり、UNIX ドメインソケットの通信内容を右から左へ受け流しつつ、内容をダンプするようなプロキシがいれば中身を覗き見ることが可能なはず。で、前回作った UNIX ドメインソケットのプロキシが登場する。

早速 CentOS6.3 に Open vSwitch 1.7.1 をインストールして、そこで UNIX ドメインソケットのプロキシを動かしてみる。 Open vSwitch を CentOS にインストールする方法は以前のエントリのココとかココを参照する。

プロキシの動作には Twisted が必要なのと、CentOS 6.3 の場合 Python のバージョンが 2.6 なので argparse もインストールする。

# yum -y install python-setuptools # easy_install pip # pip install Twisted argparse

プロキシの名前はなんでもいいけど、udsproxy.py って名前で保存しておく。デフォルトでは /var/run/openvswitch/db.sock がソケットのパスになってる。パーミッションの関係で root 権限で実行する。上手くいけばプロキシ用のソケット (/var/run/openvswitch/proxy.sock) ができるはず。

# python udsproxy.py \ -t /var/run/openvswitch/db.sock \ -p /var/run/openvswitch/proxy.sock

この状態でプロキシ用のソケット (/var/run/openvswitch/proxy.sock) の方で通信すれば内容がダンプされるはず！

# ovs-vsctl --db=unix:/var/run/openvswitch/proxy.sock show ec16a9cd-66c9-4a72-a8ec-33cdfdafdf7c ovs_version: "1.7.1"

プロキシの方は？

# python udproxy.py \ -p /var/run/openvswitch/proxy.sock \ -t /var/run/openvswitch/db.sock {"method":"monitor","id":0,"params":["Open_vSwitch",null,{"Port":{"columns":["interfaces","name","tag","trunks"]},"Controller":{"columns":["is_connected","target"]},"Interface":{"columns":["name","options","type"]},"Open_vSwitch":{"columns":["bridges","cur_cfg","manager_options","ovs_version"]},"Manager":{"columns":["is_connected","target"]},"Bridge":{"columns":["controller","fail_mode","name","ports"]}}]} {"id":0,"error":null,"result":{"Open_vSwitch":{"ec16a9cd-66c9-4a72-a8ec-33cdfdafdf7c":{"new":{"cur_cfg":0,"ovs_version":"1.7.1","bridges":["set",[]],"manager_options":["set",[]]}}}}}

お！なんか謎の JSON が出力されてる。

The web has come a long way since the days of intrepid coders hacking asynchronous content into pages with hidden iframes and dynamically loaded javascript files. Today we take the ease of use that standardized support for XMLHttpRequests (XHR) affords for granted. Libraries like Prototype and jQuery help to clean up code by handling generating requests and processing return values but we can do better. Here’s where RPC comes in.

Using only the components available from the browser requires a lot of code. Here we have to manually find the correct browser object, build the request, monitor the progress and interpret the response all by hand. Of course, no one would actually use this…

var xhr; // Firefox/Opera/Safari/everyone else... try {xhr = new XMLHttpRequest();} catch (e) { // New IE? try {xhr = new ActiveXObject('Msxml2.XMLHTTP');} catch (e2) { // Old IE? try {xhr = new ActiveXObject('Microsoft.XMLHTTP');} catch (e3) {xhr = false;} } } xhr.onreadystatechange = function() { // Wait for returned data if(xhr.readyState == 4) { // Check the response headers... if(xhr.status == 200) { // process results... } } } // Build the request xhr.open(GET, '/user/search?s=' + encodeURI(search_string), true); xhr.send(null);

Javascript libraries do an excellent job hiding these nuts and bolts. But as general purpose tools, they don’t do a great deal to ease communicating with server components. We’re left making server agnostic posts to URLs and processing them like traditional web forms.

new Ajax.Request('/user/search', { parameters: {s: search_string} onSuccess: function(transport) { // process result... } });

Remote procedure calls (RPC) solve this problem by allowing remote invocation of code on a server. The RPC server component handles interpreting and validating requests and forwards them to the appropriate methods. By doing this we get away from writing code that does nothing more than interpret parametrized requests and pass them to business logic.

Pos.Rpc.call('PosUser', 'search', [search_string]).and(function(rs) { // process results... });

While this works fine for calling static methods, it isn’t very well suited to interacting with persistent objects. For this we have a simple object request broker (ORB) that creates references to specific server objects in javascript. These references use a light weight interface description language (IDL) that defines the capabilities of the server object to the client. Once the reference is initialized, it transparently processes calls by passing requests to the server and returning the results through a fluid interface.

new Pos.Rpc.Reference('PosUser', user_id).ready(function(user) { user.getFullName().and(Element.update.curry('user-name')); });

For some extra spice, PHP exceptions and other errors trickle down to the Firebug console to make debugging a breeze. Also, requests are queued and bulk-processed where possible. This happens transparently and cuts back drastically on the total number of real HTTP requests that have to be made.