開発者が語る、無線技術についてや製品開発の秘話、技術者向け情報、新しく興味深い話題、サイレックスが提供するサービスや現状などの話題などを配信していきます。流行語になってからもう数年経ちました。対して距離を取ってきたのですが、そうも言っていられなくなってきたようです。社で開発されたものと言われます。いう名前自体には大した意味はありません。いう名前は「名が体を現わさない」妙なことになっています。古典的なクライアント・サーバ型システムの場合、データの発信者と受信者は直接接続していました。接続する場合には問題になりませんが、センサネットワークのように数百数千ものデータソースが存在する場合は問題です。アドレスを検出管理しなければなりません。サーバ側では接続数が多くなると処理や消費メモリの負荷が上がり、「何が起きたとき誰に伝えれば良いか?」というデータ配布条件の設定も複雑になる傾向がありました。ブローカー)にデータを送り付けるだけでよく、そのデータをどんな条件で誰に再配布するのかはブローカーが処理する形態のシステムです。データの受け取り手はサブスクライバー(Subscriber)と呼ばれます。厄介事をブローカーがまとめて引き受ける中央集権型のシステムですが、ブローカーをクラウドサーバとして解釈するとわかりやすいかと思います。8883)を使って動作します。異なるバイト単位のバイナリフォーマットで、十数バイト程度の短いメッセージを交換する場合にデータ効率が優れることも特長です。トピックとメッセージさて、データ伝達の基本は「誰」に「何」を伝えるかです。「何」は更に「それを識別する名前」と「その中身」から構成されます。おいて「何」は「トピック(Topic)」という文字列で識別されます。始まる任意の階層の名前を付けることができます。予約語として特別な機能が与えられる」という程度しか既定がなく、非常に自由度が高い特徴があります(※註)。※註:もっとも原仕様で既定していないというだけの話で、実装系によって異なる既定や上限がある可能性はあります。おいて、トピックとパブリッシャーの間に直接の関係はありません。複数のパブリッシャーが1つのトピックにメッセージを送ることも可能です(※註)。一切関知しませんし、複数パブリッシャーから「ほぼ同時」にメッセージが送られてきた場合の優先度や到着順序は管理も保証もしません。※註:誰彼構わずメッセージを送られると困るような場合、ユーザ名とパスワードを使ってトピックへのアクセス条件を制限するようにブローカーを実装することは可能です。仕様は「ユーザ名とパスワードが指定可能である」という枠組みを設けているだけで、それをどのように利用してパーミッションを実現するかは実装に任されています。「既定しないこと」を既定しています(※註)。アプリケーションが解釈できればそれで良いというのです。従来のメッセージ型プロトコルが何らかのデータ型(整数や文字列)を持っていたのに対し、この自由度の高さは異様にすら思えます。世界で用いられているフォーマットが使用されるでしょう。セッションをもって「誰」を識別します。ように切断状態にあった「誰か」がログインして溜まっていたメッセージをまとめて受信するような運用は想定されていません(※註)。機能はない」と冒頭に書いた通りです。※註:ただし、トピックに送られた最後のメッセージを1つだけ溜める「リテイン(Retain)」という機能はオプション仕様として既定されています。サブスクライバーはブローカーに対し、自分が受信したいトピックを指定します。そのトピックに対して(パブリッシャーから)メッセージが送られると、メッセージは全てのサブスクライバーに再配布されます。条件を組み合わせた配布条件フィルタのような難しい機能はありません(※註)。※註:これも、ユーザ名に紐づけてメッセージの再配布条件を設定する実装は可能です。それを実装するかどうか、どれだけ複雑な条件設定を可能にするかは実装と運用に任されます。サブスクライバー側には、複数のトピックをまとめて受信する「ワイルドカード」という仕組みがあります。組み合わせで指定されます。「それ以降の全ての一致」を示します。ワイルドカードは階層単位で用いられ、文字列の部分一致には用いられません。全てのトピック」を対象とします。「/+room」だとか「/bed#」のように文字列と組み合わせて使うことはできません。ワイルドカードを使った場合、サブスクライバーは(当然ながら)複数の異なるトピックからのメッセージを受信することになります。メッセージの優先度や到着順序は管理も保証もしませんし、それどころかメッセージがどのトピックから送られたかも示してくれません。この辺も「アプリケーション依存」なので、「メッセージにトピック情報を添付することにする」とか「そもそもワイルドカードには頼らない」とか、システムとして何らかの解決法を定める必要があります。いうパッケージを使ってました。バージョンが問題になるほど難しいことはやりません。最初にブローカーを起動します。オプションを付けて接続や送受信の情報を逐一表示させるようにすると、何がどう動いているのかわかりやすいでしょう。1883.次に別ウィンドウを開けてサブスクライバーを起動します。トピックを指定します。/bedroom/light次にもう一つ別ウィンドウを開けてパブリッシャーを起動します。メッセージを示します。ONするとサブスクライバーのウィンドウに再配布されたメッセージ「ON」が表示されるはずです。簡単な動作例は以上です...これだけ?!そう、これだけ。単純なプロトコルです。大幅な改訂が行われ直接互換性の無い部分すらあり少々の混乱を招いたようです。動かすことはまず無いでしょう。セキュリティ層を挟んで少なくとも片方向(ブローカー/サーバ側)の認証と暗号化を行う運用がほぼ必須になると思います。双方向認証を必須とすることも可能で、このへんは使用する実装系と運用上の要件に応じたインテグレーションが必要になります。用いると接続・切断のたびに証明書の交換と検証が発生し、これは通信時間と消費電力の増大を招きます。バッテリ駆動で間欠的なデータ発行を行うセンサノードでは大問題で、ここをどう工夫するかがインテグレーターに問われることになります。回線を接続しっ放しで省電力モードに入れたほうが効率的かも知れません。したほうが効率的かも知れません。性能や証明書の鍵長にも左右されるので一概には言えません。)に頼ることが正解になるかも知れません。特徴ではないかと思います。ついて簡単にまとめてみました。日本でも盛んに実装が行われていて、開発者による充実した日本語の(ホンネの)情報もネットで読むことができます。「アホみたいに単純」なプロトコルで、メッセージフォーマットすら既定せず、運用で直面するであろう多くの課題を「アプリケーション依存」として実装/運用者に丸投げしている印象を受けます。見ているような気になります。枠外から出てきて市場に受け入れつつあるというのは象徴的ですね。いった低速ネットワークに向くかも知れません。ヘッダ長差なんて大した違いではなくなります。特長を活かしたシステムとして稼動させるには要求条件と使用するコンポーネントの特性を把握し、利害得失を判断して適切なセッティングを選ぶインテグレーターの手腕が問われることに変わりはないでしょう。個人情報の取り扱いについて。