自作MQTTライブラリを�Boostに提案してみた
近藤 貴俊 redboltz
発表者について
2/36
発表の目的
3/36
免責事項
4/36
主要登場人物
5/36
joaquintides MultiIndex作者
Klemens Morgenstern Process作者の一人
Ivica Siladić async-mqtt5作者
redboltz async_mqtt作者(私)
Vinnie Falco Beast作者 精力的に活動
Robert Ramey Serialization作者 割とBoost初期メン
相関図
6/36
joaquintides
redboltz
Robert Ramey
Vinnie Falco
Ivica Siladić
Klemens Morgenstern
Endorse
Slack上でレビュー
Slack上およびFormal レビュー
並行レビュー提案
競合ライブラリ
redditにasync-mqtt5をBoostに
7/36
2023/09
joaquintides氏からメッセージが届く
8/36
joaquintides
数年間あなたのプロジェクトを見てきました。�良い印象を持っています。�MQTTライブラリを作っているようですが、�Boostに提案する計画はありませんか?
redboltz
そうしたいと考えています。
Boostの提案のプロセスから理解しようとしています。
2023/09
2023/09
BoostMLにasync-mqtt5正式提案
9/36
2023/11
async-mqtt5をBoostライブラリに正式に提案します。
これから、プロセスを進めていきます。
このタイミングでは準備が間に合いませんでした。
提案には時期尚早なので、開発を進めます。
2023/09
11
Ivica Siladić
redboltz
joaquintides
Boostライブラリ採用までの流れ
10/36
2023/11
2023/11当時の情報です。最新はこちら
BoostMLにasync_mqtt正式提案
11/36
2024/05
完成度が上がり、提案できるレベルになったと思います。
まだ関心があれば推薦お願いします。
async-mqtt5のレビューが、MLを見る限り全然始まらないまま、半年経過。
OK!
2023/09
11
2024/05
redboltz
joaquintides
なぜ提案をぶつけたのか?
12/36
Slack上での洗練
13/36
Vinnie Falco
Klemens Morgenstern
印象に残った指摘
14/36
そんなわけで比較を追加
15/36
これが後述すると言っていた、優れている項目の一部
見つからないReview Manager
16/36
見つからないReview Manager
17/36
I've been contacted by my friend and sometime collaborator Takatoshi Kondo regarding his submission of a boost library:
https://github.com/redboltz/async_mqtt. It has received two endorsements. He has asked me to be review manager and I'm inclined to accept
this request as he was very helpful to me during the refinement of the boost serialization library. There is also mqtt client library that is
proposed to the Boost. https://github.com/mireo/async-mqtt5 It also has endorsements and a review manager. A cursory examination of the git hub pages suggest considerable overlap between the two submissions. In general, boost has discouraged the acceptance of multiple libraries with this much overlap - and for good reason. An accepted library often becomes the canonical implementation in large parts of the C++ world. Having two high quality libraries that do almost the same thing is not where we would like to be. I would like to propose that we review both libraries simultaneously in order to try to reach a consensus as to which, if either we want to accept. I know this is a difficult task, but I think it is important that we do this. It's going to be tough to reject a well written library because a better one has been accepted. But it would be worse to reject a well written library merely because another one was submitted first. Normally I don’t participate as a review manager as I'm pretty bogged down in Boost stuff as it is. But I'm willing to make an exception in this case due to the importance of this case and my strong personal ties to Takatoshi. BTW - who is the review wizard these days? I presume that he will be the one making the decision about this.
友人で時折コラボレーター（共同制作）も務めている近藤貴俊さんから、彼が提出したBoostライブラリ（https://github.com/redboltz/async_mqtt）について連絡がありました。このライブラリはすでに2つの支持（endorsements）を得ています。彼は私にレビュー・マネージャーを務めてほしいと依頼しており、以前Boost Serializationライブラリのブラッシュアップの際に彼が非常に力になってくれたこともあって、私はこの依頼を引き受けたいと考えています。
一方で、別のMQTTクライアント・ライブラリ（https://github.com/mireo/async-mqtt5）もBoostに提案されています。こちらも支持を得ており、すでにレビュー・マネージャーも決まっています。
GitHubのページをざっと確認したところ、これら2つの提案にはかなりの重複があるようです。一般的にBoostでは、これほど重複する複数のライブラリを採用することは推奨していません。それには正当な理由があります。一度採用されたライブラリは、C++界の大部分において「標準的な実装」となることが多いからです。ほぼ同じ機能を持つ高品質なライブラリが2つ存在するというのは、私たちが望む状況ではありません。
そこで、どちらか一方を採用するか、あるいは両方見送るかのコンセンサスを得るために、2つのライブラリを同時にレビューすることを提案したいと思います。これは困難な作業になるとは承知していますが、実行する価値のある重要なことだと考えています。優れたライブラリを「他にもっと良いものがあるから」という理由で却下するのは心苦しいものですが、「単に他方が先に提出されたから」という理由で却下するのはそれ以上に避けるべき事態です。普段、私はBoost関連の仕事で手一杯なため、レビュー・マネージャーを引き受けることはありません。しかし、今回の件の重要性と近藤さんとの強い個人的な信頼関係から、例外的に引き受けるつもりです。
ところで、最近の「レビュー・ウィザード（Review Wizard）」はどなたが担当されているのでしょうか？ 最終的な判断はその方が下すことになるかと思います。
紛糾したが先着優先ルールに決定
18/36
2023/09
11
2024/05
2024/10
ここで私はいったん傍観者に
19/36
恐ろしく紛糾したレビュー
20/36
Sans-I/Oなプロトコルライブラリという問題提起
21/36
レビュー指摘を(勝手に)反映する
22/36
async_mqttをSans-I/O化
23/36
include/async_mqtt/protocol
asio_bind
Sans-I/Oのプロトコルマシン
Boost.Asioからプロトコルマシンを使う
Sans-I/O化
24/36
Protocol State Machine
受信バイト列通知
送信API呼び出し
設定API呼び出し
コールバック呼び出し
全て同期間数
Sans-I/O化 (プロトコルで規定されたタイムアウト)
25/36
Protocol State Machine
送信API呼び出し
設定API呼び出し
タイマ発火通知
コールバック呼び出し
受信タイムアウト10秒を設定せよ
利用者側でタイマ設定
受信バイト列通知
タイマ時間経過したら
その旨を通知するAPI呼び出し
全て同期間数
Sans-I/O化 (プロトコルで規定されたタイムアウト)
26/36
Protocol State Machine
送信API呼び出し
設定API呼び出し
タイマ発火通知
コールバック呼び出し
受信タイムアウト10秒を設定せよ
利用者側でタイマ設定
受信バイト列通知
タイマ時間経過したら
その旨を通知するAPI呼び出し
全て同期間数
例えば、Boost.Asio。あるいは、RTOS周期処理など。
コールバック引数の戻り値化
27/36
Protocol State Machine
送信API呼び出し
設定API呼び出し
タイマ発火通知
コールバック呼び出し
別の同期間数呼び出し
受信バイト列通知
全て同期間数
同期間数が戻る前に内部でコールバックは呼ばれる
コールバック連鎖でstack overflowするかも?
コールバック引数の戻り値化
28/36
Protocol State Machine RV(Return Value)
送信API呼び出し
設定API呼び出し
タイマ発火通知
受信バイト列通知
全て同期間数
Protocol State Machine
イベント variant
コールバック引数を格納
イベントvariant vectorに追加
コールバック呼び出し
コールバックは 0..N 回呼ばれる
戻り値としてvectorを返す
注意点
(戻り値化する前の)コールバック内で、ユーザに副作用のある処理の完了を期待する設計にはできない。
全てのコールバックを呼び終わって、その引数をイベント化して、順序通りvectorにして返すため。
今回そういう設計ではなかった
Sans-I/O化したメリット
29/36
その他レビュー指摘対応(余談)
30/36
その後の展開
31/36
Rust版
32/36
include/async_mqtt/protocol
asio_bind
mqtt-protocol-core
mqtt-endpoint-tokio
mqtt-client-wasm
mqtt-broker-tokio
C++
Rust
Cargoとcrates.ioという環境があり、ライブラリ(crate)配布や分割が容易
mqtt-protocol-core
mqtt-endpoint-tokio
mqtt-client-wasm
mqtt-broker-tokio
依存関係
mqtt-protocol-core
33/36
mqtt-endpoint-tokio
34/36
mqtt-client-wasm
35/36
まとめ
36/36