3.1 アーキテクチャ

普通のサーバ・クライアント、(リバース)プロキシが入った形態に加え、IoTの"Thing"(例えばセンサ)が、別のThingに対してはサーバとして振る舞いながら、同時にCoAPのResource Directoryサーバにクライアントとしてアクセスするような例が紹介されている。以下の図は元文書からの抜粋である。

    ________                                         _________
   |        |                                       |         |
   | Thing (C)-------------------------------------(S) Origin |
   |       (S)                                      |  Server |
   |________| \                                     |_________|
    (Sensor)   \   ________                     (Resource Directory)
                \ |        |
                 (C) Thing |
                  |________|
                 (Controller)

これはThingがどれくらいのリソースを持ってるか次第なんだろうけど、自分が知ってる限りでもCortex-M3くらいのプロセッサでWebサーバになってたりするし、いまどきかなり小さいモジュールでもこのようなことは可能なんだろう。

3.2 システム設計

システムの状態というのを大別して二つあると述べている。

一つはSession Stateで、これはコンポーネント間で行われる制御フローややりとりの状態である。この状態はクライアント側のみが保持すべきと書かれている。一般のWebの場合もこれは同じだと思うが、サーバ側のリソースが限られる場合が多いということが強調されている。

もう一つはResource Stateで、これは各コンポーネントが単独で管理する状態である。センサの説明のような静的な状態とセンサ値のような動的な状態の両方が含まれる。

まあ、普通かな…。

3.3 リソースのモデリング

MIMEのメディアタイプを用いてリソースを表すにあたり、あまり聞きなれなかったのは以下の三つ。

application/senml+json
- SenMLというものらしい。後で見てみる予定。
application/cbor
- RFC7049らしい。こちらも見てみたい。JSONを参考にしているらしい。
application/exi
- Wikipediaを見つけた。

個人的には、どんどんモジュール自体のスペックも向上するだろうし、デバッグのことを考えずに既存のものを単にダウンサイジングしたデータ形式はあまり普及しない気がしてるんだけどどうだろう。

3.6 ステータスコード

HTTPのステータスコード相当のものをCoAPだとレスポンスコードという。

記法は若干違う(CoAPは4.04のような書き方)ものの、概ねセマンティクスは同じらしい(例えば2xxは成功、など)。

ただ、両者のコードがキャッシュ可能であるかどうかの基準は異なり、ステータスコードはリクエストのメソッドにより決定されるが、レスポンスコードはコードそのもので決定されるらしい。そうすると、操作の結果としては一緒だがキャッシュ可能/不可能が異なるような場合にコードを新設する必要がありそうだが、実際のところどうなんだろう。

気が向いたらCoAPのレスポンスコード体系を確認してみることにする。

Appendix A

本文書に関する将来の取り組みとして、下記が挙げられている。

アプリケーションの状態に関する詳細
デザインパターンの議論
- 状態の監視
- 機能の実行
- 状態としてのイベント
- 変換
- コレクションについて
- 劣悪なネットワーク環境下のロバストな通信
- ベストエフォートな通信
- 3wayコミット
ディレクトリに関する議論
リソースのより具体的なモデリング方法