技術解説：XMRとは?

xiboにおけるコンテンツのディスプレイ端末への配信では、XMR(Xibo Message Relay)と言う仕組みが使われています。これは、リアルタイムにディスプレイコンテンツを配信する仕組みです。
以下、このXMRとPush Messagingに関して解説していきます。

XMRとは？

XMRはXibo 1.8で導入されました。XMRは簡単に言うとプッシュメッセージコンポーネントで、XMRがXiboに導入される前は、Playerが定期的にポーリングして、更新の有無をチェックし、その内容をを要求する、つまりプルメッセージでの実装でした。

現在でも定期的な収集間隔でプルメッセージを利用しています。

プルメッセージの問題点

プルメッセージでは、リアルタイムに情報を表示したいなどの要求には対応できません。例えば、地震速報などをディスプレイ端末に表示したい場合など、あらかじめスケジュールできないイベントに対して、即座に対応をする場合です。例えば10分間隔でポーリングしていては、ディスプレイ端末に表示データが送られるのが最大10分後になってしまいます。

また、送るべきデータがない時でも、常にある一定間隔でディスプレイ端末はサーバーにアクセスをするため、端末数が多くなるとそれがネットワークやサーバーの負荷になります。

プシュメッセージング

それでは、直接ディスプレイ端末にデータを送信すればいいと思いますが、ほとんどの場合、ディスプレイ端末はファイアオールの内側、プライベートネットワークに接続されています。そのため、直接ディスプレイ端末に接続してデータを送信することができません。なんらかの方法でディスプレイ端末に表示するデータがあることを伝え、ディスプレイ端末側から取りに来てもらう必要があります。
そこで登場するのがXMRです。

XMRはディスプレイ端末側から接続され、表示データがあるかどうかの情報だけを待ち受けます。表示データがあるとの指示をもらうと、通常のポーリング動作と同様に表示データを取得に行きます。ポーリングにより定期的に情報をチェックするより遥かに早く表示データを取得できます。

XMRとサーバーとの間の通信路は常に確保されており、瞬時に新たな表示データがあることを検知できます。

アーキテクチャ

プッシュメッセージングを実現しているアーキテクチャを以下の図で説明していきます。

この図では、ディスプレイ端末１と２がCMSに接続されている状態です。

Subscribe/Publish

それぞれのディスプレイ端末は、XMRのポート9505(デフォルト）に対してSubscribeの要求メッセージをTCPで行います(1)。この時のTCPパケットは端末側からの発信ですのでファイアウォールで遮られることなくパブリックアドレスで待ち構えているXMRに届きます。このTCPコネクションはlong-term-connectionが設定されており、NATテーブルも開いた状態がキープされ、常に接続状態となります。したがって、返信メッセージも問題なくファイアウォールを通過できます。

Xibo-CMSで何らかのデータの変更や追加などがあり、即座にディスプレイに転送する必要があると判断されると、Xibo-CMSはXMRのポート50001に、データの発生があり、それを必要とするディスプレイ端末にデータを取得するように指令するメッセージを送信します(2)。

メッセージを受け取ったXMRは、メッセージ内容に基づき、(1)でSubscribeしているディスプレイ端末に対してPublishというメッセージで、データの発生を通知します(3)。

Publishメッセージを受け取った端末は、通常の手順でCMSに対してデータをGETしに、得られたデータを処理、表示します(4)(5)。

期待される効果

このXMRの導入により、リアルタイムで情報を表示することが可能になっています。また、Xibo社のレポートによれば、XMR導入以前は1−5分のポーリング間隔を必要としていたが、XMR導入後は平均で30分間隔でポーリングすれば良いとのことです。
言うまでもなく、ネットワークの負荷を大幅に削減できることにつながります。
特に、多くの端末を接続しているシステムでは効果は大きいでしょう。

セキュリティに関して

各ディスプレイは、初回起動時にRSA公開鍵/秘密鍵を生成し、その公開鍵をCMSに送ります。この公開鍵は、ディスプレイに送られるすべてのメッセージの封印に使用され、ディスプレイはメッセージを処理する前に封印が有効であることを確認できます。

メッセージの内容を暗号化する必要はありません。なぜなら、メッセージは、命令のみを含み、いかなるデータも含んでいません。例えば、メッセージは「collectNow」などで、ディスプレイ端末がCMSからデータをGETする指示だけです。

と言うことで、このXMRからの情報漏洩等の心配は無いでしょう。

注意すること

筆者もこのXMRを理解し、実際に稼働させるのに随分と苦労しました。その経験から注意点をまとめておきます。

レンタルWebサーバーでは実装が困難

筆者は当初安価なレンタルWebサーバーにxiboをインストールしていました。しかし、レンタルWebサーバーに用意されているphpには、XMRのインストールには欠かせないzeroMQと言うライブラリが実装されていないケースが多いようです。筆者が借りたサーバーもこのzeroMQライブラリはインストールされていませんでした。

zeroMQライブラリは先に説明したsubscribe/publishと言うメッセージのハンドリングを行う必須のライブラリです。

もう一つの問題は、レンタルWebサーバーのファイアウォールです。9505ポートを解放する必要があるのですが、レンタルWebサーバーのファイアウォールはユーザーサイドでは自由に設定できないケースがほとんどです。

XMRを実装するには、VPSか独自にサーバーを立てる必要がありますね。

1台のサーバーで複数のCMSを実行する場合

Sigme Cloud Serviceでは、1台のサーバーに複数のCMSが稼働できる環境を構築しています。CMS本体は、HTTPでのアクセスですので、リバースプロキシによりサブドメイン単位で振り分け処理を行なって実現しています。

XMRはTCPの固定ポートをリッスンするので、複数のXMSで9505を使うわけには行きません。そこで、CMS毎にこのポートのアサイメントを変更しています。
CMS1には9505を、CMS2には9506をといった感じで、ダイナミックに空きポートをアサインしています。

同時にそのポートに対してファイアウォールをAllowするなどの対応が必要です。

まとめ

XMRはxiboをよりダイナミックに使っていくための重要な機能です。
近年のデジタルサイネージには、リアルタイム性など、よりダイナミックな機能が求められています。そのためにもXMRは欠かせない機能でしょう。

後はどんなインパクトのあるサイネージを実現するかはあなたのアイデア次第です！