I have a situation where I need to get some information from an application written in JavaScript, to another computer over the network, but neither system knows the ip address of the other. Multicast really seems like the right answer to me. This communication would require small and frequent update messages, perfect for a light multicast stream.
The problem is that I don't think JavaScript can send UDP messages and I don't think JavaScript can trigger external applications to send the messages on its behalf.
How can I solve this problem?
Related
I know there are already similar questions in forum, but I didn't really find a direct answer for my question there.
What I'm trying to do:
I have a pub/sub middleware that uses UDP multicast to send data to other hosts and I want to be able to visualise that data with JavaScript im Browser. Best case scenario for me would be to receive the UDP packets directly in JavaScript (like just "rewriting my subscriber code in JS"), but I understand this is not possible for security reasons. So what other way is there to somehow get to these UDP packets from the browser?
I read that, under specific conditions, it's possible to communicate with the browser over UDP using WebRTC, but I don't understand what these conditions are. If this would be your suggestion, it would be very nice if you could explain that. I'm kinda new to the whole real-time-data-transfer-to-browser topic.
Thank you in advance! :)
WebRTC provides Datachannels, this allows a browser to send/receieve datagrams. These datagrams will be carried over UDP, but also use SCTP and DTLS.
To get your packets into the browser you will need to write a UDP -> WebRTC bridge. This will not run in the browser, but the browser will connect to it. You have lots of choices when writing this bridge Python, C/C++, Go, node.js, Rust and more.
Since you are writing a bridge you could also use Websockets or even HTTP poll. But today there is no way to directly get UDP into the browser. A Raw Sockets API was proposed, but AFAIK is not going to happen.
Not for raw-UDP, but for coap(s), there are http-coap-cross-proxies, which may help.
Request out:
Browser -- HTTP -> http2coap-cross-proxy -- coap -> coap-server
Response back:
Browser <- HTTP -- http2coap-cross-proxy <- coap -- coap-server
Anyway, that keeps the request/response scheme, so I'm not sure, if that matches your requirements/expectations.
I am trying to implement video calls into an existing ionic 3 project for one of our clients, I have used the google code lab as a boiler plate code for sending the offer and answer via Firebase real time data base.
This you probably heard(read) before: "my webRTC doesn't work in external network" and the answer would be that:
Use your own STUN server and don't rely on free stun servers like google.
Use TURN server for backup on failed stun attempts.
Understand webRTC before you implement it.
What I want to ask is the following:
In my current setup (using a free google stun server) testing with two different networks , I am seeing remote candidates with typ srflx, I am also seeing typ host but since it is different networks so it holds no interest for me, and obviously no relay as there is no TURN server. I also see that I am providing local candidates with srflx, does this means that my setup should have been enough to establish a connection? I have spent some time trying to figure this one out and I have found a lot of info in this blogpost, but I wasn't able to fully debug the situation.
Suppose we would like to implement our own TURN/STUN setup, our calls are going to be almost entirely in the same country so we won't need multiple servers. Would anyone have an estimation for the following:
1.How much data per minute would entail one video call (ballpark)?
2.Our client likes google cloud services for his project, How much would it cost to spin a TURN server for this project on google cloud platform (again just a ballpark)? is there any idea on the best setup (I was thinking coturn and was looking on this google coturn implementation)?
Thank you all.
Edit:
After some more digging, I realized that one of the different networks I was testing was sitting behind a symmetric nat, a nice jsfiddle for testing what kind of nat you have I found in this blog post.
In the case of a symmetric nat the iceCandidate received is not suitable for connection and you have to have a TURN server.
So I guess that takes care of the 1st part. Any additional data on the 2nd part would be appreciated.
OK so after all this digging I guess I can agree with the 3rd notation (and no I still don't fully get it not even close), if this might help anyone I will share my experience.
I was brought into a project (ionic 3) and was told to find and implement a video chat. We chose webRTC. webRTC as far as I know is the only widespread opensource option. In our country a huge number of cellular users are behind symmetric nat so p2p with them won't work. I tested a twilio TURN service and immediately everything started to work. The rough numbers for a basic call would be around 1.5Mb per minute. Thank you for anyone who stumbled upon this and tried to figure out if he can help.
I have built a websocket in C++ (using boost::beast).
It is going to serve a website (client) with a JSON string if requested.
When designing my setup I made a disastrous mistake: I forgot that the client web browser (that is running on a separate device from the server) will not know the IP address of the server. It will know the port that the server is listening on.
I should specify: Both (server and client) are running in a local network.
So I have two clumsy ideas to resolve this. I would be very happy to hear your input – I am sure there will be a more elegant way to fix my problem.
Send some kind of broadcast message “Very specific string” into the network. My server will know that it is been looked for and will respond with its IP, so that the connection can be established.
This post seems to indicate that this approach will not be possible.
Have the user input the (known) IP address of the device that is running the server. I would really like to avoid this last resort solution.
Unfortunately, I cannot run node.js on the device that is hosting the websocket server.
I might not be understanding the problem. Why aren't you capable of knowing the IP of the server? Is it due because it changes? Is it because it's a server you don't know?
Maybe the solution is not about finding the IP rather than knowing beforehand the server IP address.
I could recommend checking out this post to find out the IP address in your local network. If you at least know the servername of the server that could be helpful.
#E.Soria
Thank you for your answer! I was not precise enough.
The problem was, that the server is running on a device that is going to be part of our customer’s network. The customer will define the IP address for the device, which means that I need some way of getting the address of the server.
But I might have found another solution (as you might already be able to tell I am very new to networking, so this just may be wrong): I will host the website on the same device that is hosting the server and supplying the data. Then I can just establish a websocket connection through javascript like this: let socket = new WebSocket(ws://127.0.0.1:8080); and have the website read data from the server. This seems to be very straightforward and I am a little embarrassed that I did not think of this before.
I just had not really understood how the internet works :) As long as the user who wants to see the website knows where it is hosted, he/she can just connect to the website and will see anything that I put on there.
I am posting this question because I currently have some issues with WEBRTC in Javascript.
First of all, my implementation works pretty well and I can communicate with one or more people at the same time.
However, the context, where i use webrtc, can sometimes lead to a client creating multiple offers in a few ms (using STUN server) and sending those offers to multiple other client.
The issue is: sometimes the client connects really well to one or more other clients but the connection fails with the rest of clients he sent the offers. (and it is not an issue with particular client because all clients can connect each other if they send offers in a longer timing)
I suppose it is a conflict between sdp offers (maybe port conflict ?) that are generated by a same client in a too short time before the end of connection's establishments.
My question is how can i deal with it ? Is it possible to detect when connection fails and then create a new offer ? Should I check the sdp messages in my signal server to ask a client to create a new offer when he sends 2 offers that are conflicting ?
Thanks for your answers.
P.S:
Sorry for my bad language, I am not native english speaker. :/
I know there is lot's of documentation about WebRTC out there so I am sorry if I missed it:
My question is the following:
Is it possible to connect from client to client without using an intermediate server. ( Including an intermediate server to set up the connection )
Take as example two clients that know each other IP addresses and the ports they are using for RTC. Both did they already downloaded the webpage. Is it possible for them to connect without an intermediate signal server?
I hope you would point me to a good source of how this is possible! Or why not!
Thanks
It is not as easy as that to set up the connection. There is more information that needs to be provided than ip and port. There are 'offer', 'answer' and 'candidates' that are sent between the peers.
These are readable text and the could very well be typed in by the user but since they are quite large, it is more easy to provide them via the server in the middle.
You could mail them and type them in at the remote peer...