I want to implement a service for a great number of devices. This service should be able to send/receive (small - max 1kB) messages between server and client, but also p2p between device and device.
For now I am thinking about achieving this with MQTT, as it seems to be a lightweight low traffic generating protocol. As stated in this question XMPP might also be an alternative, but I'm not sure if this is giving me the performance I need.
Summarized I have the following expectations for the protocol:
Small Overhead
Small Payload
High number of clients (starting with 100.000)
Handles unstable network connection
Scalability for example by using multiple broker instances
P2P Connections between clients (could be solved with an involved server)
If possible open source implementations in Java, JavaScript and C++
Is MQTT the right approach for me or should I better look at some alternatives? Please keep also in mind that I would need to create a highly scalable service.
I think all your expectations except for 6. can be fulfilled with MQTT if you use it the right way. You should have a look at http://www.eclipse.org/paho/ and http://mosquitto.org/ for OpenSource implementations.
As MQTT has a publish-subscribe architecture where every message is send to and distributed by the message broker (server), P2P might be a problem. You could use a dedicated topic for every connection between two clients, but the messages would still have to pass through a message broker.
As a workaround, you could negotiate a P2P connection between clients over MQTT and then use the negotiated channel with another protocol.
As leikes said, with MQTT you have all the features you need and the point 6 is achieved using a broker.
The big lack for MQTT is that it doesn't support request/reply pattern natively (like HTTP or AMQP) but a full support for publish/subscribe pattern.
Of course, if you need request/reply you need to do it into a layer above the protocol itself defining right topics and payload to create a matching/correlation logic between request and response.
Paolo.
Related
Is it possible to implement a WebService over a WebRTC Data Channel ?
The idea is:
The client makes one https request to the server for signaling and session establishment
The client and the server start to communicate via a WebRTC DataChannel bidirectionally
Benefits?:
Performance ?
Requests goes over one connection and the standard allows for multiple datachannels over the same connection ( ports )
Flexible networking topologies
UDP
End to end encryption
The server can send events over the same connection
Load balancing could be implemented from a pool of servers client side without a load balancer , or all kinds of different solutions
Currently being debated the addition of DataChannels to Workers/Service Workers/ etc https://github.com/w3c/webrtc-extensions/issues/64
Drawbacks:
Application specific code for implementing request fragmentation and control over buffer limits
[EDIT 3] I don't know how much of a difference in terms of performance and cpu/memory usage will it be against HTTP/2 Stream
Ideas:
Clients could be read replicas of the data for sync, or any other applications that are suitable for orbit-db https://github.com/orbitdb/orbit-db in the public IPFS network, the benefit of using orbit-db is that only allows to the owner to make writes, then the server could additionally sign with his key all the data so that the clients could verify and trust it's from the server, that could offload the main server for reads, just an idea.
[EDIT]
I've found this repo: https://github.com/jsmouret/grpc-over-webrtc
amazing!
[EDIT2]
Changed Orbit-db idea and removed cluster IPFS after investigating a bit
[EDIT3]
After searching Fetch PROS for HTTP/2 i've found Fetch upload streaming with ReadableStreams, i don't know how much of a difference will it be to run GRPC (bidi) over a WebRTC DataChannel or a HTTP/2 Stream
https://www.chromestatus.com/feature/5274139738767360#:~:text=Fetch%20upload%20streaming%20lets%20web,things%20involved%20with%20network%20requests).
Very cool video explaining the feature: https://www.youtube.com/watch?v=G9PpImUEeUA
Lots of different points here, will try to address them all.
The idea is 100% feasible. Check out Pion WebRTC's data-channels example. All it takes a single request/response to establish a connection.
Performance
Data channels are a much better fit if you are doing latency sensitive work.
With data channels you can measure backpressure. You can tell how much data has been delivered, and how much has has been queued. If the queue is getting full you know you are sending too much data. Other APIs in the browser don't give you this. There are some future APIs (WebTransport) but they aren't available yet.
Data channels allow unordered/unreliable delivery. With TCP everything you send will be delivered and in order, this issue is known as head-of-line blocking. That means if you lose a packet all subsequent packets must be delayed. An example would be if you sent 0 1 2 3, if packet 1 hasn't arrived yet 2 and 3 can't be processed yet. Data channels can be configured to give you packets as soon as they arrive.
I can't give you specific numbers on the CPU/Memory costs of running DTLS+SCTP vs TLS+WebSocket server. It depends on hardware/network you have, what the workload is etc...
Multiplexing
You can serve multiple DataChannel streams over a single WebRTC Connection (PeerConnection). You can also serve multiple PeerConnections over a single port.
Network Transport
WebRTC can be run over UDP or TCP
Load Balancing
This is harder (but not intractable) moving DTLS and SCTP sessions between servers isn't easy with existing libraries. With pion/dtls it has the support to export/resume a session. I don't know support in other libraries however.
TLS/Websocket is much easier to load balance.
End to end encryption
WebRTC has mandatory encryption. This is nice over HTTP 1.1 which might accidentally fall back to non-TLS if configured incorrectly.
If you want to route a message through the server (and not have the server see it) I don't think what protocol you use matters.
Topologies
WebRTC can be run in many different topologies. You can do P2P or Client/Server, and lots of things in between. Depending on what you are building you could build a hybrid mesh. You could create a graph of connections, and deploy servers as needed. This flexibility lets you do some interesting things.
Hopefully addressed all your points! Happy to discuss further in the comments/will keep editing the question.
I was also wondering about this HTTP-over-WebRTC DataChannel idea a couple of years ago. The problem at hand was how to securely connect from a web app to an IoT device (raspberry pi) that sits behind a firewall.
Since there was no readily available solution, I ended up building a prototype. It did the job and has been in live deployment since 2019.
See this technical blog post that covers the design and implementation in more detail:
https://webrtchacks.com/private-home-surveillance-with-the-webrtc-datachannel/
High level architecture:
Simplified sequence diagram:
Recently began the process of extracting the code into a standalone repo.
https://github.com/ambianic/peerfetch
If your main use-case exchanges small content, you may have a look at CoAP RFC 7252. A peer may easily implement both roles, client and server, though the exchanged messages for request and response share the same fomat.
For some advanced usage of DTLS 1.2, DTLS Connection ID can do some magic for you.
If you don't stick to javascript and java is an option, you may check the open source project Eclipse/Californium. That's a CoAP/DTLS implementation, which comes with DTLS Connection ID and some prepared advanced examples as built-in-cid-load-balancer-support or DTLS-graceful-restart.
I am trying to make simple game of Tic-Tac-Toe in JS.
I made almost everything. Now there is just one thing to do.
I would like to make it available to play online with someone.
I want to send data between two games via Internet.
Unfortunately my server does not support Node.JS.
Is there a way to make it happen without any server-side "socket".
I thought I could make it with XMLHttpRequest() for saving/loading data into/from server files and play like that, but I think it would require a lot of code and maybe for ttt it would be fast enough, but for more complicated games it would not be sufficient.
I know this is tough, but how did they do that before node.js?
For a game like Tic-Tac-Toe where players take turns, latency definitely takes second seat to every other factor in communications. For this reason alone, communicating with just the HTTP protocol, typically by utilizing the XMLHttpRequest class or the Fetch API, is a very reasonable approach which will save you a lot of programming effort.
Otherwise, when wanting one or several low-latency and/or RTC channels (for hopefully a good reason), both WebRTC and WebSocket are viable candidates.
WebRTC, for one, can absolutely do peer-to-peer, while WebSocket uses the client-server model. But even WebRTC requires a "signalling" service to exchange peer identifiers initially, before eventually switching to communicating between the peers directly. While peer identifiers are required to set up WebRTC communication, the API deliberately does not cover how peer identifiers are exchanged -- however you want to design your signalling service, is up to you. For all WebRTC cares, you can "POST" a peer ID to a HTTP server and retrieve it with the other peer's Web browser and vice-versa. WebRTC starts with already known peer IDs.
Otherwise, if configured to do so, WebRTC is able to utilize STUN and/or TURN services to maintain peer-to-peer connection, on networks that otherwise prohibit straightforward IP routing between any two clients -- a necessary prerequisite of true peer-to-peer communication.
STUN/TURN services aren't required in all cases, but knowing average network conditions, without using either STUN or TURN or both, your application wouldn't be very reliable for any two clients separated by multiple arbitrary networks. Like in scenarios where both parties are separated by at least one firewall or a stubborn router that functions as one.
A TURN service would then transparently route WebRTC communication, working as a relay.
A STUN service punches holes in the firewalls between clients in such a way that peer-to-peer communication is possible afterwards. Meaning that in contrast with a TURN service, it does not play any active part in communication after latter is established.
WebRTC is a bit complex, especially if you are expecting an API along the lines of send and receive, but a simplified connection example should be understandable to a developer.
You may also not need to use WebRTC API directly, there are libraries that encapsulate WebRTC into a simpler API of one flavour or another, API that simultaneously hides the more fringe or "boilerplate" aspects of WebRTC and which also helps minimize the risk of getting into trouble as different user agents are notorious for implementing different parts of WebRTC a bit differently.
One of these libraries is PeerJS but there are others, without a doubt.
The WebSocket API, unlike WebRTC, requires a WebSocket compliant server, and WebSocket API does not do peer-to-peer. The good news is that 1) a WebSocket compliant service is typically just an advanced relay (often fused with an application back-end logic), albeit working on the application level instead of the session level for TURN and 2) there are plenty of "turn-key" WebSocket server implementations out there.
WebRTC signalling is driving me crazy. My use-case is quite simple: a bidirectional audio intercom between a kiosk and to a control room webapp. Both computers are on the same network. Neither has internet access, all machines have known static IPs.
Everything I read wants me to use STUN/TURN/ICE servers. The acronyms for this is endless, contributing to my migraine but if this were a standard application, I'd just open a port, tell the other client about it (I can do this via the webapp if I need to) and have the other connect.
Can I do this with WebRTC? Without running a dozen signalling servers?
For the sake of examples, how would you connect a browser running on 192.168.0.101 to one running on 192.168.0.102?
STUN/TURN is different from signaling.
STUN/TURN in WebRTC are used to gather ICE candidates. Signaling is used to transmit between these two PCs the session description (offer and answer).
You can use free STUN server (like stun.l.google.com or stun.services.mozilla.org). There are also free TURN servers, but not too many (these are resource expensive). One is numb.vigenie.ca.
Now there's no signaling server, because these are custom and can be done in many ways. Here's an article that I wrote. I ended up using Stomp now on client side and Spring on server side.
I guess you can tamper with SDP and inject the ICE candidates statically, but you'll still need to exchange SDP (and that's dinamycally generated each session) between these two PCs somehow. Even though, taking into account that the configuration will not change, I guess you can exchange it once (through the means of copy-paste :) ), stored it somewhere and use it every time.
If your end-points have static IPs then you can ignore STUN, TURN and ICE, which are just power-tools to drill holes in firewalls. Most people aren't that lucky.
Due to how WebRTC is structured, end-points do need a way to exchange call setup information (SDP) like media ports and key information ahead of time. How you get that information from A to B and back to A, is entirely up to you ("signaling server" is just a fancy word for this), but most people use something like a web socket server, the tic-tac-toe of client-initiated communication.
I think the simplest way to make this work on a private network without an internet connection is to install a basic web socket server on one of the machines.
As an example I recommend the very simple https://github.com/emannion/webrtc-web-socket which worked on my private network without an internet connection.
Follow the instructions to install the web socket server on e.g. 192.168.1.101, then have both end-points connect to 192.168.0.101:1337 with Chrome or Firefox. Share camera on both ends in the basic demo web UI, and hit Connect and you should be good to go.
If you need to do this entirely without any server, then this answer to a related question at least highlights the information you'd need to send across (in a cut'n'paste demo).
I'm new to WebRTC, actually just heard about it a few days ago and I've read a lot about it. However, I still have a few questions.
What do I need to explore the usage of WebRTC? E.g.: do I need a server, any libraries etc.? I'm aware that new version of Chrome and Firefox support WebRTC, but besides these two browsers, is there anything else that is necessary?
What is the main purpose of WebRTC when addressing practical usage? To video chat? Audio chat? What about text-chatting?
Does WebRTC need a server for any kind of browser-to-browser interaction? I've seen some libraries, such as PeerJS that don't explicitly mention any kind of server... so is it possible to connect two clients directly? There's also a PeerServer, which supposedly helps broker connections between PeerJS clients. Can I use WebRTC without such a server?
What are the most commonly used libraries for WebRTC?
What's a good starting point for someone who's totally new in WebRTC? I'd like to setup a basic google-talk kind of service, to chat with one person.
Thank you so much guys.
You can find many docs here E.g. this one, this one and this one!
You can find a few libraries here.
A simple multi-user WebRTC app needs following things:
Signalling server to exchange sdp/ice/etc. ---- e.g. socket.io/websockets/xmpp/sip/XHR/etc.
ICE server i.e. STUN and/or TURN; to make sure Firewalls doesn't block UDP/TCP ports
JavaScript app to access/invoke RTCWeb JavaScript API i.e. RTCPeerConnection.
It just takes a few minutes to setup WebRTC peer-to-peer connection. You can setup peer-to-server connections as well where media-servers can be used to transcode/record/merge streams; or to relay to PSTN networks.
WebRTC DataChannels can be used for gaming, webpage synchronizing; fetching static contents, peer-to-peer or peer-to-server data transmission, etc.
What do I need to explore the usage of WebRTC? E.g.: do I need a
server, any libraries etc.? I'm aware that new version of Chrome and
Firefox support WebRTC, but besides these two browsers, is there
anything else that is necessary?
WebRTC it is JavaScript API for web developers which can be used for audio and video streaming.
But there are 2 notices:
You need a signaling path.
For example, if your first user is Alice using Firefox and second user is Bob using Chrome,
they should negotiate used codecs and streams.
WebRTC does not offer the signalling implementation. So you need to implement the signaling yourself. It is quite simple. You need to send SDP(stream config) to participant and receive an SDP answer. You can use plain HTTP via apahe server or use Websockets or any other transport to negotiate SDP.
So, it seems you need an intermediary signaling server workning with websockets or HTTP/HTTPS.
Once you negotiated the streams you are sending your audio or video stream, but the distanation user might have a simmetric NAT. It means that you stream will not be delivered to the target user. In such situation you need a TURN server to traverse the NAT.
Finally you will need 2 server-side logic items:
1) Signaling server
2) TURN or proxy server
To start, take a look Web Call Server.
The server implements HTML5 Websocket signaling and SRTP proxying as a TURN server.
You can also learn the webrtc application open source code.
First steps:
1. Download the signaling and streaming server.
2. Download and unzip web client.
3. Start the web client and debug javascript code to learn more how webrtc works.
I have been thinking about building a client to client program. But the way I want is to use the broswer to do it, helped by a server that can make that connection.
The troubles comes when I need to have an unnconected socket (or pasive) in a client, waiting for a connection.
I have been thinking about Html5 WebSockets, but it doesn't give to the client the posibility of having a pasive socket without connecting it with a TCP protocol.
I'm learning this and trying to find the way to do this. All ideas are wellcome :D.
You can have a passive socket in Java applets, Flash and other browser plugins, but in general that can be problematic for public web applications.
First of all it will be difficult to get through firewalls, etc, and you'll need to depend and write code for a browser plugin that implements a socket API, and bridge it to JavaScript. If you are interested in some solutions, you may want to check out the following Stack Overflow post:
How can I communicate over TCP sockets from JavaScript?
The traditional approach for peer-to-peer communications between browsers is to have your server acting as a gateway for all the connections. Browsers initiate the connection (either with WebSockets or with XMLHttpRequest) and keep an active connection to the server at all times, re-establishing it if it drops. Since the server application will always find an open TCP connection to all the connected browsers, it can easily route messages to/from all clients.
As Daniel says, you are going to have a very hard time trying to do true peer-to-peer (a la Skype etc) in the browser, and it is certainly not possible without the use of plugins. And even Skype etc rely on falling back to a server acting as a gateway when a direct connection cannot be established (due to firewalls etc).
So you really need to have a gateway server regardless, and that there are a number of options. Try searching here for 'comet'. Some options that I have played with include Orbited (http://orbited.org/) and Hookbox (http://hookbox.org/) but there are many others.