A few things:
The mosquittto_pub and mosquitto_sub commands do not support WebSockets at all.
When you run mosquitto from the command line you have to explicitly point to the config file with the -c option
mosquitto -v -c /path/to/mosquitto.conf
The Windows builds available from the mosquitto.org download pages don't support WebSockets, so the only way ...
The question here appears to be "should I use MQTT over TCP, or use MQTT over websockets (which also goes over TCP)?" In other words, is "encapsulating MQTT in the websockets protocol a good idea?"
This is (almost) entirely down to your application and whether you need websockets support - probably for consuming messages in a browser or for firewall reasons....
When you are communicating only inside your network (intranet), using pure TCP will be fine. But if you have to connect to another server, problems will arise.
Because most of the modern servers do not allow clients to connect through random ports. They only allow some dedicated ports to connect. That's all. Hence if you have to connect to another server, ...
MQTT is probably the right answer.
Each ESP can publish to the broker with a topic structure something like:
You can then use MQTT over Websockets to subscribe to all the topics (either each topic separately or with the # wildcard).
Since each message from the sensor arrives on it's own topic you can then use the topic to ...
tl;dr - always prefer free libraries to coding it your self (unless you have extreme requirements)
Should I use Mosquitto's web sockets or connect clients directly?
How long is a piece of string? (YMMV)
I can only speak generally, but I always prefer wrapper libraries to raw sockets (or, indeed, to coding anything which I can get for free from a ...
MQTT should be more than fast enough for your architecture, given a decent WiFi network. I run about 30 sensors (ESP8266, Feather MO, Arduino Uno, etc.) all using MQTT back to a Mosquitto Broker running as a Docker Container on an 15yo laptop, which connects back out to my control software and displays, and it all works just fine. I'm pushing close to 2 ...
As @hardlib said, you have to compile mosquitto from sources. It took some trial and error for us to get it working on windows, so here some summary in case it helps somebody. Please don't hesitate to correct it:
install Visual Studio
install cmake ( latest version is fine )
install OpenSSL to C:\temp\OpenSSL
unzip pthreads to C:\pthreads
Nothing, as I stated in the answer on Stack Overflow they are byte for byte exactly the same protocol, it's just the transport layer which changes from raw TCP to Websockets.
The difference is that you CAN NOT open raw sockets from within the browser, the security sandbox will not allow you to open arbitrary TCP connections to random hosts. The sandbox will ...
Starting from 1.5.1 the windows package support websocket, see changelog https://mosquitto.org/blog/
You have just to edit mosquitto.conf file, specify to use the websocket protocol by adding "protocol websockets" (see definition around line 145) and eventually restart mosquitto if you run it as a service
I found a compiled version of Mosquitto with WebSockets built for Windows on GitHub which may be of use if you don't want to build the code yourself.
While it is documented in Korean, it also includes a PowerPoint presentation with instructions on how to build it yourself, if you do not wish to use the pre-compiled binaries.
Congratulations on writing a research paper on it.
This can be done with streaming platforms such as kafka or AWS KDA (kinesis data analytics). There are clauses in the query language in KDA (and also in KSQL, I think) which will allow you to link the events that happen very close together.
If someone needs an answer / solution for this query, I created a landing page of repositories that provides a complete End-To-End solution of a prototype of the application. Right from Arduino Sketch for the Sensors, as well as Backend API.
Landing Page: iotfablab/TrackNTrace
Also I have a written a scientific paper for it:
If you do not have ...
In this case, since its a software, why not just allow it to have a UI, where you can ask for a userID, password and make an API call where you can then provision a device and get an IoT certificate ?
If for some reason, this has to be a headless device, you have two things to do:
You need a unique ID. This can just be a guid. Or you can call an API to get ...