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).
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.
Note: I've already read this question, its main answer and all the linked questions given there (more than 8 questions, such as this one but it talks about Flash, etc.). They are all ~ 2011, and things might have changed, thanks to new tech like WebRTC, etc.
Question:
If I give my IP to a friend, and he gives me his IP, can we send bytes to each other directly in the browser, with Javascript? (both users not in the same local network but connected via internet)
If possible, without any 3rd party server. In this case we would both load a local HTML file containg the Javascript code allowing connection to each other. It seems possible to do such things with "chownat":
allows clients behind NATs to communicate with a server behind a separate NAT with no port forwarding no DMZ setup, and no 3rd party involvement.
If not possible without any server, then is it possible with a server involved just at the beginning of the process? (to make peers meet / know each other / to initiate the connection). Then once connection is established, the server would not be needed anymore: the 2 peers send bytes to each other, without server.
Is 1. or 2. possible nowadays with a standard browser (Firefox, Chrome, etc.) and without any router port configuration? With WebRTC for example?
Note: I've read about RTCDataChannel and tried this Simple_RTCDataChannel_sample but I don't see how two distant people can use this to connect to each other, this sample doesn't cover that. Here is the live demo. I don't see how it can be turned into a connection between two peers on internet.
If I give my IP to a friend, and he gives me his IP, can we send bytes to each other directly in the browser, with Javascript? [...] If possible, without any 3rd party server.
No, WebRTC uses session establishment tokens which cannot be reused, they must be generated anew for each connection. The IP address is not sufficient to establish a connection, at least such a token must also be generated and exchanged, either manually or...
If not possible without any server, then is it possible with a server involved just at the beginning of the process?
Yes, the server would act as rendezvous point to exchange tokens and optionally as STUN server.
Is 1. or 2. possible nowadays with a standard browser (Firefox, Chrome, etc.) and without any router port configuration?
That depends on your router(s), more specifically behind what types and how many layers of NAT each party is. But if they are well-behaved then the browsers will attempt NAT traversal with the help of a STUN server to establish a direct connection.
But generally browsers are less powerful when it comes to NAT traversal than native applications since native applications can talk to the firewall, UPnP/PMP/PCP routers and may also try NAT traversal techniques (e.g. TTL-based punching, linear port guessing) that are not part of the standard ICE/STUN approach.
I'm playing around trying to find a way to communicate between two browsers on the same network to establish WebRTC without a server roundtrip (no STUN/ICE/TURN). Basically an alternative to the approach found here, where the "handshake" is done via copy/mail/pasting.
After sifting through all the cross-browser-communication examples I could find (like via cookies or WebTCP) plus a bunch of questions on SO (like here), I'm back to wondering a simple thing:
Question:
If Alice and Bob visit the same page foo.html while on the same network and they know each others' internal assigned IP addresses, are there any ways they can communicate purely with what is available on the browser?
This excludes non-standard APIs like Mozilla TCP_Socket_API, but other than that all "tricks" are allowed (img tags, iframes, cookies, etc.).
I'm just curious if I can listen to someone on the same network "broadcasting" something via the browser at all.
Edit:
foo.html will be on static server, no logic, no ICE, no shortcut.
Edit:
Still not a solution but a websocket server as Chrome extension comes closer. Example here: almost pure browser serverless WebRTC
Yes, you can establish a direct connection between two browsers over the local network using WebRTC. It requires the use of ICE, but that does not mean that an outside STUN or TURN server is needed. If the browsers are on the same network, ICE will succeed with only the local candidates of each browser.
STUN/TURN is needed only in order to guarantee that two endpoints can establish a connection even when they are in different networks and behind NATs.
In fact, if you use most of the WebRTC example applications (such as apprtc) with two browsers connected in a local network, ICE is most likely to select and use the pair of local addresses. In this case a channel allocation on a TURN server will be made, but it will not get used.
In your WebRTC application, you can disable the use of STUN/TURN by passing empty iceServers when you create the PeerConnection.
While the MDN documentation lists WebSocketServer as a client API, I don't think this is accurate (maybe they wanted to document there how to write a server).
At the moment, I know no standard way to create a server socket on a web browser. I know a couple of attacks to scan the local network but most of them rely on an active server outside the network, that is you connect to a server and get JavaScript back which opens a WebSocket connection. Via that connection, I can take full control over the client and have it open more WebSockets with local IP addresses to scan the internal network.
If internal web sites don't implement CORS correctly (see here), I can access all internal web sites where the current user is currently logged in. That is a devious attack vector which allows external attackers to browser internal documents without cracking anything. This page has a demo of the attack.
Even Flash won't let you create a server socket.
If you allow a Java applet and the Java version on the client is very old or the user blindly clicked "OK", then you can create server sockets.
Related:
Socket Server in Javascript (in browsers)?
This could be explained easily. The answer is it's not possible. In order for alice and bob to communicate at all without a third-party, at least one of them needs to be listening for incoming connections. Not possible using a standard web browser alone.
You can take a look at this
https://github.com/jed/browserver-client
I think that you can easily create an http server with javascript and send messages from one browser to another
With Nodejs you can achieve the same.
I am writing a simple javascript game for a webpage. I am going to convert it to the desktop using tidesdk. I would like to allow players on different machines to play each other without the need to communicate through a server.
Is this possible in general? Is this Sockets?? Do you have any links of this being done with javascript code?
Is this possible with TideSdk? Do you know of any links to examples of this being done wiht TideSdk?
How do the players know what ip address/port their machine is on so they can give it to the other player?
I am sorry these are vague and open questions, but I don't really know where to start looking for this stuff, as I don't really know what the stuff I am looking for is called.
... Oh, and I don't want to use any third party stuff if I can help it. Maybe the jquery at a push.
This would be impossible with the APIs provided by web browsers (you would need to use something like Socket.IO and communicate through a server, as others have said). Fortunately, since you are using TideSDK, it is possible as long as you don't need a lot of network efficiency. You will need to provide a server, but it will not have to be powerful enough to host the actual games.
The General Client and Server Method
There are other ways to organize a network, but you can look those up if you think they'd be easier to implement.
Your server will host the actual game download and provide matchmaking capabilities. The clients that people download will contact this matchmaking server to find others who want to play.
The matchmaking server should select one of those clients to be a host for the others. Finally, the matchmaking server will tell the client selected as a host that it is the host and give it everyone's connection information (ports and IP addresses) while giving the other clients the connection information for the selected host. The host will connect to the other clients.
The host computer will be the only one that actually does any processing of gameplay, and the other clients just display whatever information the host sends them. The clients render the current state of the game from each player's perspective on their respective computers and capture user input, which is sent to the host for processing.
Implementation
TideSDK provides a Ti.Network.TCPSocket object which can make raw TCP client connections to TCP servers. Unfortunately, it does not also provide a way to make raw TCP servers. Instead, TideSDK provides a Ti.Network.HTTPServer object, which implements the HTTP protocol server over TCP, and a Ti.Network.HTTPClient object, which provides an HTTP client (it is actually just an abstraction over the normal AJAX request API). You can use the provided HTTP server on the host computer and directly connect to it on the clients using the provided HTTP clients. Data will be exchanged using the HTTP protocol. As far as I can tell, this is your only option here.
I did not find any example code out there (beyond what is in the TideSDK documentation) but you might find some if you are really interested.
Next Steps
If I wanted to go ahead with using TideSDK, I would do the following:
Tell the developers of TideSDK that you are interested in a TCP server socket. A raw TCP connection would be much faster than HTTP.
Test out the HTTP connection and find out if it is fast enough for my game.
Yes it's possible in general, and sockets are what you need. Although I don't think it's possible in practice, here's why.
Normally in a P2P game, there would be a server that knows who is online, and what their IP is. When new players connect to the server they will see a list of other users, they can select who they want to play.
Without having the server, there will be no way for users to see who is online, and to answer your 3rd question:
How do the players know what ip address/port their machine is on so they can give it to the other player? It doesn't matter if they can find their own IP, they have no way to find the IP of the opponent (without calling them on the phone :)).
So, if you want to build a game, then you'll need a server. I suggest Node.JS alongside Socket.IO