8

私はこのテクノロジーに慣れていないのですが、疑問点について誰か教えてもらえますか?

Q-1. CoAP パケットのサイズは?
(4 バイトの固定ヘッダーがあることは知っていますが、ヘッダー、オプション、ペイロードを含めた最大サイズ制限は?)

Q-2. MQTT のような Keep Alive の概念はありますか?
(接続を開いたままにする時間は UDP で動作します。デフォルトの時間はありますか、またはパケットを送信するたびに開いたままになりますか?)

Q-3. TCP で CoAP を使用できますか?
(CoAP の主な問題は、UDP で動作することです。MQTT QoS のような概念はありますか? センサーが 1 秒ごとにデータを発行するとします。サブスクライバーがオフラインになった場合、CoAP にはサブスクライバーがすべてのデータを取得するという保証があります。それはオンラインになりますか？）

Q-4. 接続時間は？
(CoAP はパブリッシュ/サブスクライブ アーキテクチャをサポートしています。接続を常に開いておく必要があるかもしれません。UDP に基づいているかどうかにかかわらず、CoAP で可能ですか。)

Q-5. リソースはどのように検出されますか?
(私は 1 つのゲートウェイと 5 つのセンサーを持っています。これらのセンサーはどのようにゲートウェイに接続しますか?ゲートウェイはこれらのセンサーを見つけますか?またはセンサーはゲートウェイを見つけますか?)

Q-5. センサーはどのようにゲートウェイに登録しますか?

私を助けてください、私は本当に答えが必要です。私はこの種のことはまったく初めてで、実装の観点から何かを提案します。

ありがとう。

4

1 に答える 1

7
  1. 場合によります：
  • コア CoAP メッセージは、リンク層パケット (UDP の場合は ~ 64 KiB) に収まるほど小さくする必要がありますが、いずれにしても、RFC では次のように述べられています。
    • IP フラグメンテーション (IPv6 の MTU は 1280) を避けるために、単一の IP パケット内に収まるべきである (SHOULD)。ヘッダーのサイズが不明な場合、適切な上限はメッセージ サイズが 1152 バイト、ペイロード サイズが 1024 バイトです。
    • アダプテーション レイヤーのフラグメンテーションを回避する場合はそれ以下 (6LoWPAN ネットワークの場合は 60 ～ 80 バイト)。
  • より大きなペイロードを転送する必要がある場合、このIETF ドラフトはコア CoAP を拡張し、複数の要求と応答のペアでリソース表現から複数の情報ブロックを転送するための新しいオプションを追加します (メッセージごとに 64KiB 以上を転送できます)。

  1. 私は MQTT を使用したことがありません。いずれにせよ CoAP はコネクションレスであり、要求と応答は UDP または DTLS を介して非同期的に交換されます。監視機能を探していると思います.CoAPクライアントがリソースに「サブスクライブ」し、サーバーがサブスクライブしたクライアントに一定期間更新を送信できるようにします。

  2. CoAP over TCP を説明するIETF ドラフトがありますが、それが監視機能とどのように相互作用するかはわかりません。通常はベスト エフォート アプローチに従います。たまたま、クライアントがリソースに関心がなくなったと見なされ、削除されるだけです。オブザーバーのリストからサーバーによって。

  3. クライアントがリソースに関心がなくなったとサーバーが判断した場合、またはクライアントがリソースからの購読解除を要求した場合、監視は停止します。

  4. よく知られている相対 URI "/.well-known/core" があります。これは、サーバーがホストするリソースに関するリンクのリストを要求するためのデフォルトのエントリ ポイントとして定義されています。詳細については、こちらをご覧ください。

  5. 5を見てください。

于 2015-10-10T14:08:34.950 に答える