【レポート】IOT321 | AWS IoT CoreとMQTTによるトヨタのコネクテッドプラットフォーム変革 #AWSreInvent #IOT321 製造ビジネステクノロジー部の新澤です。 "Toyota's connected platform transformation with AWS IoT Core and MQTT"に参加してきましたので、レポートします。 本セッションについて タイトル： Toyota's connected platform transformation with AWS IoT Core and MQTT Level: 300 – Advanced Speaker: Roman Tubin (AWS), Daisuke Muramoto (Toyota), Hiroshi Kamada (Toyota) 概要 本セッションでは、トヨタのコネクテッドビ
HTTP3 でpub-subとMQTT-over-QUICの比較をIoTの観点から行った論文の備忘録です。 IoTという文脈で、ネットワークエミュレータに遅延と帯域を設定して、性能（最初のデータが到達するまでの時間、通信終了までの時間やスループット）、ネットワークへのオーバーヘッド（バイト量とパケット数）、リソースの使用状況（CPU使用率、RAM使用量）、の3つを比較しています。 性能面では、H3 pub-subのほうが優れた結果が得られていますが、ネットワークのオーバーヘッドやリソースの使用状況はHTTP3 pub-subのほうが MQTT-over-QUICよりも多くのリソースを使用する結果となったようです。 これらの結果から、IoTという文脈を考えた場合、トレードオフが存在しているということを示唆しています。 元論文は下で読めます。 arxiv.org 実装について H3 pub-s
ご無沙汰してます。中野です。 相変わらずNATSやNSQやら、AWSやAzureやらと戯れてます。 はじめに IoTの流行りとともに脚光を浴びた通信プロトコルにMQTTと呼ばれるものがあります。 MQTTがIoTのシーンにおいて、HTTPなどの他のプロトコルと比較して、 プロトコル的にどう優れているのか、どう劣っているのか、結局ユースケース次第なのでここでは割愛します。 ただ事実としてあるのは、 Amazon Web Services (AWS) Microsoft Azure Google Cloud Platform (GCP) らが、IoT向けのメッセージブローカーとしてMQTTをサポートした以上、 MQTTというプロトコルの存在を無視はできないということです。 (製品に採用するかどうかは、ユースケース次第なのでまた別の話です。) (MQTTそのものの良し悪しより、それぞれのクラウド
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く