クライアントから送信されたメッセージをローカルDBに永続化するMQTTサーバーをセットアップしようとしています。各メッセージには「正常に受信されました」フラグがあり、受信クライアントが受信したメッセージ（QOS = 1）ごとにpubackを返すときに反転します。
質問は：
メッセージを公開すると、サーバーは受信側クライアントからpubackを正しく受信します。ただし、messageIdは、公開クライアントのパケットからのものと同じではありません。私はこれが意図されていることを知っています。しかし、そうすると、フラグを反転するための適切なメッセージをDBで見つけることができなくなります。クライアントAがQOS=1の2つのメッセージをクライアントBに連続して送信した場合はどうなりますか？サーバーは、戻ってくる2つのpubackをどのように区別しますか？
たぶん、MQTTクライアントは私が見逃しているmessageIdsをマッピングするために何か魔法のようなことをしていますか？
私はmqttjsとpahomqttv3btwを使用しています。
QoS 1 または 2 の MQTT PUBLISH メッセージには、パケットの一部としてメッセージ ID が必要です。メッセージ ID は、PUBACK (または QoS 2 の PUBREC/PUBREL/PUBCOMP) が参照しているメッセージを識別するために使用されます。一度に複数のメッセージが「処理中」になる可能性があるため、これは重要な機能です。
見逃しているかもしれない重要な点は、クライアントが互いに完全に分離されているということです。これは、メッセージ ID がクライアント (およびメッセージ フローの方向、ブローカーからクライアント、またはクライアントからブローカー) に固有であることを意味します。ブローカはブローカから発信されたメッセージのメッセージ ID を生成し、クライアントはクライアントから発信されたメッセージのメッセージ ID を生成します。メッセージ ID は方向ごとに独立しているため、ブローカーとクライアントが相手の動作を追跡する必要はありません。
サブスクライブしているすべてのクライアントに送信された受信メッセージを追跡したい場合は、受信メッセージに関連する送信メッセージを追跡し、それらの送信メッセージのすべての PUBACK が受信された後にのみ DB をトリガーする必要があります。 . これにより、メッセージの受信時にサブスクライブしていたすべてのクライアントにどのメッセージが正常に送信されたかがわかります。
ブローカーに送信されたすべてのメッセージのログが必要であり、送信が正常に機能していると想定できる場合は、作業がはるかに簡単になります。「#」トピックまたは興味のあるものをリッスンするクライアントをブローカホスト上に作成し、クライアントの on_message() コールバックを使用して (またはライブラリが管理する方法で) メッセージを処理し、DB に保存します。 .