I'm researching about servers and P2P and I remember that while playing CS on a local network, without an internet connection the client was able to fetch the servers on the local network. How is that possible? I really would like to implement something similar to that in WebRTC, although I believe it's not possible with WebRTC.
Peer discovery on a LAN is commonly done via UDP multicast which indeed is not available via browser APIs.
Related
For a mostly offline browser game I'm researching the possibility to run a WebRTC signalling server from a browser.
I can imagine that security-wise it's a big no-no to open a port and serve connections from a browser (or service worker), but I cannot* find any information on this.
Q. Can Chrome, Firefox (or perhaps any other major browser) open a network port and serve connections using javascript? Or is this fundamentally disallowed by browser design?
*) For sake of completeness, I did find one option (maybe), but it's overly complex, and therefore isn't very appealing. There is a javascript package called filerjs, which allows for a posix-like filesytem in the browser, I think using indexedb, that would allow for a nodejs installation in the browser. I did not further investigate it, so no idea if it actually works, and if a connection could be served this way.
I don't think that you can run a signaling server in the browser. But you say "mostly offline", does that mean that the peers are connected to the internet, but playing from the same LAN? Or are they completely offline? Here are a few ideas:
Signaling server on the web
Even if the signaling server is running on the web, chances are that WebRTC will connect directly through the LAN (to be tested, and it may depend on how the browser selects the ICE candidates).
Manual signaling
Now, the signaling server is only there to exchange SDP messages. So you could theoretically copy-paste the offer and answer (or copy it manually, or scan it with a QR code). It may not be practical, but for instance you could try hardcoding the SDP offer/answer. The two players would need to exchange information somehow, though:
The ICE candidates (those are IPs) that you would need to create the SDP message
The SDP type (one has to be the offer, the other has to be the answer)
I never tried it, but maybe your UI could tell the player "Please share the following IPs to the other player, and enter their IPs below. Also select if you are the offerer or the answerer". But you see that it seems a bit convoluted...
Signaling server in the LAN
If the peers are completely offline and the manual signaling is too convoluted, my next idea would be to run the signaling server in the LAN, and have the peers connect to it. You could even make it such that your game first tries to contact your signaling server on the Internet, and if it fails (because it is offline), it could fallback and try to contact the one in the LAN (maybe it would need to ask the user for the IP of the signaling server, then).
I'm trying to build a website that allows you to transfer files to devices connected on your local network. This website is static, and will be hosted on GitHub pages.
Is it possible to use Javascript to communicate with (i.e. transfer files/text) other devices on the local network? The IP addresses of the devices are already known and I'm looking for a peer-to-peer connection here.
Note: As this website is static, there is no server side code that can be controlled.
Thanks
Yes, it's possible with caveats, depending on the specifics of your situation.
WebRTC
With WebRTC, you can establish a real peer-to-peer connection between two clients on a network. They can send data (binary or strings), and media streams (like webcams and microphones). This can even work from a static page.
The catch is that you need some sort of server to help coordinate the connection. Because of the way the WebRTC standard was originally set up, there is some back-and-forth that must occur to set up that peer-to-peer connection. Some method of communicating the signalling between the clients must exist, and this is usually done via web sockets and an intermediary server.
There are some novel alternatives.
In the future, ORTC may solve this issue, allowing a one-shot method for setting up the call, making the server-side requirements easier.
Embedded HTTP Server
You didn't elaborate on the specifics of what device you want to communicate with on your network, so maybe this is a possibility as well. There's nothing stopping your browser from communicating with devices on your LAN. Your static web page can use the Fetch API or AJAX to retrieve data from devices.
Is there a way to use webrtc without any server or cost and without downloading anything? I'm trying to make a peer to peer network without a server of any kind (I can't set up my own). Every tutorial that I've found needs some kind of server, or downloading node.js, or using some service that you pay for with a subscription. Is there a way to do this?
WebRTC is actually a Peer to Peer RTC Protocol which happens between browser.
But you got it in wrong way. For establishing the direct link between two systems WebRTC requires,
The topology between itself, and the peer it wants to communicate with
Establish connectivity on the best path through a given topology
Have a fallback mechanism if all else fails.
WebRTC standards require the use of three IEFT NAT traversal standards to address these issues:
Interactive Connectivity Establishment (ICE) – RFC 5245
Session Traversal Utilities for NAT (STUN) – RFC 5389
Traversal Using Relay NAT (TURN) – RFC 5766
So, the final answer is it's not possible with WebRTC.
I want to have two different computers open a static html page, and be able to communicate to each other via WebRTC over a local area network. There is no internet connection to the outside world in this scenario. One of the pcs would be able to enter the ip address of the other pc manually and connect to it using that hardcoded IP. Is an ICE server necessary? If so, does the server itself need internet access to the outside world?
You do not need ICE servers in this case. In general, you have the following ICE candidates normally:
host (are generated by the client by binding to its locally assigned IP addresses and port)
srflx (server reflex candidates are generated by using STUN)
relay (relay candidates are generated by using TURN)
So without ICE servers you will have only host candidates generated which is enough in your case because both users are in the same local network.
Although WebRTC enables peer-to-peer communication, it still needs a server for signaling: to enable the exchange of media and network metadata to bootstrap a peer connection.
So the main problem here is that you need to exchange the “offer” and “answer” between endpoints somehow, so each party will have enough information about each other. Normally, some signaling protocol + public server is used for this purpose.
In your case, you have 3 choices:
to setup a direct p2p WebSocket connection between 2 browsers. Not sure if it's possible. Looks like a browser can only connect to other endpoint, not to listen.
manually copy\past the 'offer' and 'answer' SDP, which is not good as well I think
have some 3rd computer with some signaling server installed, so others peers will use it to exchange the 'offer' and 'answer' between each other
I'm trying to setup an a cordova plugin for iOS which implements the webrtc functions without using any server and it will only be used on a local network. I know there is this plugin, which looks promising but i have some problems with it.
My plan is not to use a TRUN, STUN or any kind of signaling server.
Maybe you think right now: "Ok this is not possible. No signaling equals no connection." But let me explain first. As pointed out here and
here it's possible to avoid using a TRUN, STUN or ICE server. I think this is a good way to start my project but there is still an open question. How shall the devices find each other if there isn't any kind signaling (in the example they use a Node.js server)? Right now i'm playing with the idea of an QR-Code which contains all the necessary information.
At the end it should look like this (black arrwos are more important):
The idea is that everyone who comes into a room has to scan a QR-Code on the RP and then the device knows the IP, port, etc. of the RP and a WebRTC connection with a DataChannel will be established.
I've been looking for an answer for days now, but due to the fact (or at least one of the reasons) that WebRTC is not even supported on iOS nativly there aren't many WebRTC examples out there which work on iOS and no one for a local network.
So my question is: Am I on the right way or is this not even possible? (I found no example for this anywhere, but if I put all the posts I read together, I think it should be possible.)
First of all, TURN and STUN are not signaling server. Signaling server is the term normally associated with the backend server that let's you relay the messages between two peers before the connection is established. The signaling server is thus used to establish the connection. Once the connection is established, there is no role of the signaling server in the communication, unless you intend to make any changes to the connection parameters.
TURN and STUN servers, on the other hand, are used during the connection establishment process. It helps the two peers find a direct path to each other. So when the connection is established, the peers can talk directly with each other and they don't require the signaling server to relay the messages anymore.
Now coming to your question, short answer is, no, your plan is incomplete.
Here are some changes that you'd need in order to make it work:
QR Code is not adequate to convey all required information. According to this answer, they can store roughly 4kb of maximum data. Thus it is not sufficient to pass all candidates.
Not to mention that WebRTC requires both devices to share the candidates. So, you'd need a display and QR code scanner on the Raspberry PI.
You might want to explore alternatives such as Wifi to allow for two-way data sharing between the device and Raspberry Pi. Once setup, the Wifi connection will act as the Signaling server.
Though I am not well versed in iOS or Raspberry Pi. So I would recommend that you ask a separate question about the choice of communication channel if you are unsure about what to choose. Keep in mind that you need Raspberry Pi to be able to communicate with the device for a short period of time in order to allow WebRTC connection to be established.
Coming to STUN and TURN servers, you may be able to get away without using them. I have seen a few cases when my app is able to establish connection to peers within the local network without STUN and TURN servers.
However, I would strongly recommend that you use at least a STUN server. They are often available for free of charge. Google and Firefox also provide their own STUN servers that you can use in any of your WebRTC apps. You can search on internet to get their details.
TURN servers are required only when the two peers are behind NAT's. In such cases STUN servers are sometimes incapable of finding a direct route between them, and you need the TURN server to relay the audio/video/message stream.
Your plan to establish the WebRTC channel between Raspberry Pi and the phones (the black arrows) seem fine to me. It would help you establish further connections between two phones whenever required.
However, if you eventually decide to implement something like Wifi on your Raspberry Pi, the WebRTC connection may be redundant. After all, you could use Wifi to pass the data back and forth, and don't really need an additional layer of WebRTC channel to do that.
Since you run your app on a local network you don't need STUN and TURN servers. But still you need a signaling server. Signaling can't be done with QR-codes, read more about WebRTC and you will understand why.
But a signaling server can be very simple. Since you have that raspberry pi in your local network, you can use this as your signaling server. Just install node, express and socket.io on it. You need only one simple javascript file, mine is only 23 lines of code. Stop wasting your time with QR-codes and you will have your signaling server up and running in no time. You can look at Google Codelab for an example. Hopes this helps you !!