MosquittoのWebソケットを使用するか、クライアントを直接接続する必要がありますか?


11

このブログによると、Mosquitto(MQTTブローカー)はWebソケットを介したクライアントへの接続をサポートしています。ブログ記事は、Webソケットプロトコル現在のブラウザーの大部分でサポートされているにもかかわらず、Webブラウザーが適切なTCPソケットを(まだ)サポートしていないため、Webソケットがブラウザーアプリケーションにとってより有用であることを示唆しているようです。

ネットワークにさまざまなクライアント(例:Raspberry Pisなどのマイクロコントローラーに基づくセンサーやアクチュエーター)しかない場合、直接TCP接続でWebソケットを使用する利点はありますか?ブラウザと通信しているときだけ、Webソケットプロトコルのオーバーヘッドはそれだけの価値がありますか?


1
すべてのネットワークをコーディングしているかどうか教えてください。つまり、すべてのノード、またはクライアントとサーバーの両方ですか?または、他の人のソフトウェアとやり取りする必要がある場合はどうなりますか?あなたはクライアントのみを符号化するかもしれないように聞こえるが、私は確認することはできません
MawgはREINSTATEモニカ言う

1
@MawgサーバーはMosquitto MQTTブローカーになりますが、すべてのクライアントに使用するプロトコルを選択できます(そして、MosquittoはWebソケットと直接TCP接続の両方を提供するので、私は尋ねました)。
Aurora0001

1
ここには混乱があると思います。@ Auroa0001が「直接TCP」とは、MQTT over Websockets(... over TCP)ではなくMQTT over TCPを使用していると私は推測しています。どちらの場合も使用可能なライブラリがあるため、ソケットのコードを記述する必要はありません。
ralight 2017年

@ralightはい、それは質問をするときの私の意図でした。答えは少し迷ったようです。
Aurora0001

回答:


7

ここでの質問は、「TCP経由のMQTTを使用するか、WebSocket経由のMQTT(これもTCP経由)を使用する必要があるか」のようです。言い換えれば、「MQTTをWebSocketプロトコルにカプセル化することは良い考えですか?」

これは(ほぼ)アプリケーションに完全にかかっており、Webソケットのサポートが必要かどうか-おそらくブラウザでメッセージを消費するためか、ファイアウォールの理由のためか。純粋なMQTTの場合、サーバーにポート1883またはそれ以上の8883でアクセスできない場合は、Webソケットが最適なオプションである可能性があります。

WebSocketsは追加の帯域幅を必要としますが、それがあなたにとって重要であるかどうかは、あなたしか答えられないものです。

Mosquittoの現在のバージョンでは、websocketがうまく機能しないため、websocketメッセージの送受信時に余分な遅延が発生する可能性があることにも注意してください。これは将来のバージョンでは問題にならないものです。


7

あなただけの内部で通信している場合は、あなたのネットワーク(イントラネット)、純粋なTCPを使用すると、罰金になります。ただし、別のサーバーに接続する必要がある場合は、問題が発生します。

最新のサーバーのほとんどは、クライアントがランダムなポートを介して接続することを許可していないためです。接続できるのは一部の専用ポートのみです。それで全部です。したがって、別のサーバーに接続する必要がある場合は、純粋なTCP接続ではなく、websocketを使用することをお勧めします。

オーバーヘッドを考慮している場合は、それほど大きくありません。WebSocketのオーバーヘッドについて詳しく知りたい場合は、この記事を参照してください。

私の個人的な意見では、深刻な懸念がある場合を除いて、常にwebsocketを使用することをお勧めします。


2
エラー、TCPとwebsocketsはプロトコルです:tools.ietf.org/html/rfc6455、さらにTCPは低レベルのソケットです。
Goufalite 2016

@ThisaruGuruge回答に感謝します-質問の私のシナリオでは、あなたの回答から判断して、Webソケット経由のTCPを選択すると思いますか?特にWebソケットは主にブラウザーでサポートされているように見えるため、TCPソケットではなくWebソケットを使用する必要があるというコードオーバーヘッドがあります。
Aurora0001

1
「最新のサーバーのほとんどは、クライアントがランダムなポートを介して接続することを許可していません」-サーバーは、バインドするポート(man7.org/linux/man-pages/man2/bind.2.html)を選択でき、さらにファイアウォールはさらに制限します。ただし、「別のサーバーに接続しなければならない場合は問題発生する」おっしゃる場合同意しません。「発生する可能性がある」と言い換えます。それでも、それは設定の問題であり、どのWebソケットがrawソケットよりもおそらく簡単になるでしょう。
Mawgはモニカを2016

6

tl; dr- 自分自身をコーディングするよりも常に無料のライブラリを好む(極端な要件がない限り)


MosquittoのWebソケットを使用するか、クライアントを直接接続する必要がありますか?

文字列の長さはどれくらいですか?(YMMV)

私は一般的に話すことしかできませんが、私は常に生のソケットよりもラッパーライブラリを好みます(実際、ライブラリから無料で入手できるものをコーディングするよりも)。

これにより、コーディングが簡単になり、エラーが発生しにくくなります。彼らは多くのハウスキーピングとエラー処理を担当します。これは、自分で記述してデバッグする必要があるコードです。ライブラリは一般によくレビューされテストされており、他の何千人ものユーザーによって使用されています。バグを報告/修正します。

さらに、維持する(そして場合によっては移植する)コードも少なくて済みます。つまり、アプリの開発、テスト、および磨き、または次のアプリへの移行により多くの時間がかかります。

唯一のオーバーヘッドは間違いなく関数呼び出しです。ライブラリアンのすべての優れた点(エラー処理、ホース管理など)が、安定した優れたソフトウェアを入手するために自分でコーディングする必要があることを受け入れる場合。

パフォーマンスが気になる場合は、プロファイルを作成してください。しかし、あなたのソケットが毎秒何百回もアクティブでなければ、私は気にさえしません。


まあ、TCP接続と(ウェブ)ソケット接続用の無料のライブラリがあり、どちらも「受信メッセージ」イベントを必要とします。
Goufalite 2016

2
OPは、効率のためにTCPまたはWebソケットを使用する方が良いかどうかを知りたがっており、「抽象ライブラリを使用して、煩わしくない」と言います。わかりましたが、どれですか。C#では、System.Net.SocketsにTcpClientライブラリ(まあ、まあ...)と、nugetパッケージ(WebSocketSharp)にwebsocketライブラリがあります。すべての言語用の汎用MQTTライブラリがあることに同意しますが、OPはそれを制御して、使用する必要のあるプロトコルを選択したいと考えています。
Goufalite 2016
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.