Linear RPCをOSSとして公開させて頂きました [通信]
2015/09/02にLinear RPCをOSS (Open Source Software)として公開させて頂きました。
Linear RPCはデータフォーマットにMessagePackを使用したRPC (Remote Procedure Call)であるMessagePack RPCの一実装です。今回はC++によるクライアント/サーバーとJavaScriptによるクライアント実装などを公開させて頂きました。Linear RPCは、元々IPネットワーク経由で業務用機器を遠隔制御するためのプロトコルとして実装しましたが、RPCを利用したいすべてのアプリケーションやサービスで利用することが可能になっています。なお、公開させて頂いた実装についてですが、C++11仕様ではありません。これは、Linux用のC++のコンパイラでC++11はオプション扱いになっていたり、組込み機器向けのコンパイラがC++11にまだ未対応であったりするケースを想定して、今のところC++11では実装しないことにしました。C++11ならばより洗練された形で実装可能なのでIT系の方などは不満かもしれませんが、最新の環境が整っていないところでも利用できるようにしたかったというのが理由です。将来的に組込み系の開発環境が整えばC++11に移行する余地はあるかと思います。
Linear RPCはすべてではありませんがこちらの分野の機器に採用させて頂いております。まだまだ、いろいろと不足や不満な部分もあると思いますが、多くの方にご利用して頂ければ幸いです。
背景
放送用カメラ、デッキ、セキュリティカメラなどの業務用機器の世界では、以前より機器をコントロールするコントローラーと本体をRS232やRS422などのシリアルケーブルや独自ケーブルで接続し、機器をバイナリコマンドで遠隔制御することが一般的に行われていました。近年は、この接続がIPネットワークになり、Windows PC上のアプリケーションや、iOSやAndroidを搭載したスマートフォンやタブレットのアプリケーションをコントローラーとして利用するケースも増えてきています。IPネットワーク経由で業務用機器を制御するプロトコルと言えば、SOAPが一般的で、現在でもSOAPを利用した制御はまだ残っています。また、近年では、制御にRESTやデータ形式としてJSONといったWeb系の技術も導入されています。特に、RESTやJSONなどのWeb系の技術は、SOAPと比較してスマートフォン等との相性が良く、また、たくさんの開発ツールがそろっているため、多くの機器の機器制御プロトコルとして採用されています。小規模なシステムやリアルタイム性があまり高くないシステムでは、RESTやJSONは、良い選択のひとつです。
ところが、比較的規模の大きなシステムやリアルタイム性の高いシステムでは、RESTやJSONは処理速度やデータサイズなどの面で厳しいケースがあります。例えば、リアルタイム性の高いシステムでは、機器の内部のステータスに変更があったことを、コントローラーに直ちに知らせたいケースがあります。これをRESTなどで実現すると、Long Pollingなどの技法を用いて見かけ上、機器側から知らされたように見せることになります。ただ、ステータスの変更が多く発生する場合、Long Pollingでは、ポーリングに起因した遅延が発生したり、処理負荷が高くなってしまったりすることがあります。
また、RESTなどで使用されるJSONはシンプルで解りやすいデータフォーマットです。しかしながら、業務用機器で良く使用するバイナリデータを扱う場合にはbase64エンコーディングを行うなど、大量のバイナリデータを扱うケースでは効率が落ちてしまうケースがあります。 例えば、デッキ等では、保存された映像データのサムネイル画像を数十～数百個を同時に取得することがあります。このとき、サムネイル画像データはJPEGなどのバイナリデータになりますが、JSON形式で送受信すると、base64エンコーディングが必要となり33～37%くらいデータサイズが大きくなります。コントローラーと本体の間で送受信する画像数や画像サイズが小さいうちにはあまり問題になりませんが、大量の画像データの送受信が発生すると無視できないサイズとなり、処理の待ち時間が大きくなってしまいます。
最近の機器制御プロトコルに要求されること
IPネットワーク経由で機器を制御するにあたり、SOAPやREST/JSONなどのWeb系の技術が今まで導入されてきましたが、遠隔制御に対しての要求のレベルが上がるにしたがって、SOAPやREST/JSONでは厳しい状況が増えてきました。以前からあったものも含めて要求のいくつかを挙げてみると以下のようになります。- ♪コントローラーをWebアプリケーションで実装したい
- ♪コントローラーをWindows PCネイティブアプリケーションで実装したい
- ♪コントローラーをiOSやAndroidのスマートフォンやタブレット上のアプリケーションで実装したい
- ♪機器の内部ステータスの変化をリアルタイムで知りたい
- ♪1つの処理を数ms以内に終わりたい
- ♪遅延を最小限に抑えたい
- ♪。。。
数ms以内に処理を終了させたいという話はIT系の方には意外とピンとこないらしいですが、例えば、60p (1秒間に60フレーム)で撮影しているカメラを制御する際、約16ms間隔で映像フレームが送出される訳ですが、処理時間が延びるにしたがって、フォーカスなどの制御が遅れて画像に反映したり、カメラのパン・チルト・ズームなどが遅れるために、動いているものを上手く撮影できないなどの状況が起こってしまいます。
なぜMessagePack RPCなのか
機器制御のプロトコルとして最小限欲しいメッセージは、制御のために使用するRPCとステータスの変更等を知らせるNotificationの2つになります。従来は、コントローラーとして専用のアプリケーションや機器を作ることが多かったために、制御プロトコルとしてリアルタイムの部分にのみ着目した独自のプロトコルを実装すれば良かったのですが、最近は、Webアプリから制御したいなどの要求も増えてきており、独自プロトコルの採用は難しくなってきています。それでも、当初は、TLV (Type-Length-Value)ベースの独自のプロトコルを実装することも検討していました。そんな中、たまたまMessagePackがやりたいことに近かったので、データフォーマットとしてMessagePackを採用させて頂きました。データフォーマットとしてMessagePackを採用したので、そのままMessagePack RPCを採用したというのが正直なところです。ただ、MessagePack RPCの実装は、クライアント側(コントローラー)からRPCとNotifyメッセージを送信する実装が多かったのですが、機器制御のプロトコルとして考えると、Notifyメッセージはサーバー側(機器)からステータスの変更を通知できる必要があります。このため、Linear RPCでは、サーバー側からNotifyメッセージを送信できるように実装させて頂きました。RPCとNotificationが利用可能になると、様々な処理パターンのプロトコルを定義することが可能となります。サーバー側の視点で一例を挙げると以下のようになります。
- ♪Requestを受信後、処理が終了してからResponseを返信する。
- ♪Requestを受信後、処理が正しく開始されたらResponseを返信し、処理が終了したらNotifyを送信する。
- ♪内部のステータスが変更されたら、Notifyを送信する。
複数のトランスポートプロトコル対応
MessagePack RPCの実装の多くはトランスポートプロトコルとしてTCPを利用しているようです。しかしながら、Webアプリケーションやネイティブアプリケーションからの機器制御プロトコルとして考えると、TCPの実装だけでは厳しいということがあり、Linear RPCは、複数のトランスポートプロトコルを採用できるアーキテクチャにさせて頂きました。現在、以下のプロトコルに対応しています。- ♪WebSocket/WebSocket Security
- ♪TLS
- ♪TCP
今回は入っていませんが、実はトランスポートプロトコルとしてUDPも想定しています。UDPは主にIPマルチキャストを利用して複数の機器を同期的に制御する際に利用可能と考えています。
おわりに
現在、機器制御のプロトコルと言えば、SOAPやREST/JSONが全盛期ですが、リアルタイム性の高い機器制御をやろうと考えている人たちにとっては、SOAPやREST/JSONでは厳しい状況になってきています。IoTの世界ではMQTTが流行っており、これを機器制御プロトコルとして応用しようという動きもあるようですが、MQTTブローカーが必須となってしまうと、用途が限られてしまいこれだけでは厳しいような気もしています。Linear RPCはまだ完成形ではないと考えていますが、改良をしていきながら広く利用されるプロトコルに育って頂ければ幸いです。
コメント 0