I am a little bit confused about what extra functionality MQTT over WebSocket provides vs traditional MQTT over TCP in react native. Is MQTT over WebSocket a solution for browsers in order to receive an event in real-time or it adds something more that I can't catch?
MQTT over Websockets provides 2 main capabilities over native MQTT.
Allows browser based systems to connect to brokers and publish/subscribe to messages. This is because the browser's sandbox doesn't allow native socket operations.
Allows MQTT applications to make use of existing proxy set ups. MQTT over Websocket connections can be made through HTTP proxies in situations where other traffic is blocked by a local firewal.
Related
I need help on following:
I want to use RabbitMQ message broker for internal communication among microservices. For example shopping cart, order, product, payment etc.
Can I use AMQP for internal communication among microservices &
MQTT for push notification to mobile & web browser?
Can I use both AMQP & MQTT with RabbitMQ at the same time or only one can be used not both?
I have just began using socket.io and I have some experience with express. I know socket.io has bidirectional communication while express is only client to server.
This made me think, why don't we just use socket.io with different namespaces and not use express at all?
In which cases should I use socket vs express?
In the case I need bidirectional communication, is it advisable to make the client -> server with express and then use socket for server -> client?
First off express and socket.io are pretty different things. Express is a full-blown web server framework. You use it for setting up a web-site, fielding http requests from a browser, fielding http requests for an API, etc...
socket.io is a communication layer that sits on top of the webSocket protocol and the webSocket protocol uses an http server to establish its initial connection. While there is a little bit of overlap between what you can do with socket.io and Express, they are more different than they overlap.
For example, if you're setting up a web-site, you couldn't do that with socket.io, one would use something like Express.
Now, if you have a specific programmatic need to communicate between an arbitrary client and a server, you have a zillion choices. If the client is in a browser and the programmatic interface is from Javascript in the browser, then you have fewer choices.
From the browser, using http ajax requests via Express is one choice. Setting up a socket.io connection and defining you own messages is another choice.
Reasons to pick socket.io over Ajax calls to Express from browser Javascript:
You need/want two-way communication over the same channel.
The client is sending a lot of requests to the server (the overhead for sending a socket.io message is lower than an ajax call, once the socket is already set up, so if you're sending a lot of messages, then socket.io messages are more efficient than http requests)
Reasons to pick Ajax calls to Express:
HTTP connections are stateless and short-lived which can make implementing high scale, multi-server implementations with failover and redundancy easier.
There are a wealth of tools to use for http connections from authentication libraries to data formats (MIME) to audio to video, etc...
You want your client to run in places where a long-connected socket.io during inactive periods of time may not be practical (perhaps mobile or battery operated devices).
You want to run in situations where there are proxies, firewalls or other network infrastructure that may not support long running webSocket connections or specifically disallow them.
You want a request/response model. HTTP is request/response where you get a specific response for each request and you know exactly which response goes with which request.
So, as you can see, there is no generic answer to this question. It really depends upon the specific of your communication, the interoperability you desire and the exact needs of your code.
Here are some other references on this topic:
Ajax vs Socket.io
Websocket vs REST when sending data to server
Using AJAX vs. socket.io socket messages
websocket vs rest API for real time data?
Is there any way to use TCP instead of websocket in react native paho mqtt?
As #hardillb says, react-native-paho-mqtt only supports WebSocket because React Native itself doesn't support raw TCP out of the box. That said if you could write a wrapper to wrap https://github.com/PeelTechnologies/react-native-tcp in an API that looks like a WebSocket, you could pass your wrapper to react-native-paho-mqtt like this - theoretically that'd work, albeit a bit messily.
The Paho JavaScript client only supports MQTT over WebSockets because it is intended to be used in the browser.
You could look at the mqtt package (https://www.npmjs.com/package/mqtt) on npm which can be used natively or in the browser and is capable of both MQTT over Websockets and native MQTT, assuming the underlying JavaScript sandbox will allow full TCP sockets.
I want to create my own video chat application. I use the WebRTC framework. I read a few tutorials and each of theme assumes that signalling channel exists. How to implement my own signalling channel?
Since signalling is not defined for the WebRTC standard at the moment, it leaves you a few options. Check out this article for more info the following articles:
Signalling Options for WebRTC Applications
Choosing your signalling protocol
1.SIP over WebSockets
Companies like JSSIP offer a SIP signalling framework over Javascript. The advantage here is that it's interoperable with the usual VoIP structures.
JSSIP
SIPJS
SIPML5
2.The WebRTC Data Channel
Uncharted territory but viable!
Tutorial by Pusher
3.XMPP
If you take this route, it is probably either because you have an existing XMPP installation
Jingle
4.JSON over COMET or WebSockets
My favourite! WebRTC signalling shouldn't be done any other way than the Web way.
Matrix
Firebase
I hope this helps!
You can make a Node.js WebSocket server or other WebSocket server to broker the connection. Here is a simple guide that gets the first client talking to the server. An alternative is PeerJS, which can handle the signaling and alleviate most of the complexity of setting up the WebRTC call.
With serverless options available, vanilla HTTP AJAX options may not be bad for scalability and costs.
Create a plain HTTP(s) API exchanging information using JSON.
I need to build a server and a client that can exchange data in real time with a company's proxy between them. No one has the authorisation to amend the proxy's configuration (in order to allow the WebSocket protocol).
I would need a fallback technology such as long-polling.
Example: client is a user's PC employee. He needs to exchange data with the server, located in the cloud and separated by company's proxy.
Ideally, I would use WebSocket with SSL, but I know some proxies are not configured for WebSocket messages and thus could reject the connection.
The app would therefore switch to another push technology such as long-polling, increasing the chances of getting a successful connection (is 100% guaranteed with proxies? Giving that there are several types of proxies...)
Are there any libraries/frameworks proposing such features?
Usually, secure WebSocket connections do fine through proxies.
In .NET you have SignalR
In node.js you have socket.io