Develop Reference

How is it possible to send UDP packets to browser?

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.

Socket connection from chrome extension being blocked by proxy/firewall

I have a web app in javascript that connects to a socket using socket.io and a Chrome Extension which connects in the same way and to the same server.
Everything works fine in most computers and internet connections, but one of my customer's computer is failing to have the Chrome Extension connected (the web app connects successfully).
By inspecting the extension's console for background.js (the script within the extension creating the socket connection) I see that it is not trying to connect to the right URL (my socket server) but to an unknown URL which seems to be a proxy: https://gateway.zscloud.net/auT?origurl=http%3A%2F%2Fmy_socket_server_domain...
Since this is happening only in that specific computer (from the 10 or so that I have tried with so far) using different internet connections (corporate network, guests network, mobile hotspot) and since other computers in those same networks DID succeed in connecting, I assume something installed or configured in the problematic computer is catching the connection request before it happens and tries to redirect it through a proxy.
Again, this happens only in the context of the Chrome Extension. The very same computer using the same internet connection DOES succeed in connecting from a web page in the same browser (Google Chrome).
Does anybody know what the problem could be? The client is not aware of having a security software (firewall, antivirus, etc...) that could be causing this, but it's a computer managed by his company so an admin could have done that for him. If that was the case, however, shouldn't the connection from the webpage be captured too? Is there anything specific to socket connections in Chrome Extensions that differ from regular web apps?
Thanks!

WebSocket connections differ from normal HTTP requests; they require a protocol upgrade after establishing that (some!) proxies may be unable to support.
I was at some point behind one such (transparent) proxy at work; however, it does not attempt to intercept HTTPS, which means I could use wss: WebSockets but not ws: WebSockets.
..which you should be using, anyway! With Let's Encrypt on the market, the barrier of entry for HTTPS is very low. If any sensitive data at all is sent through that connection, it's in your best interest.
For the record, that particular proxy is part of ZScaler which is a security solution. Sadly, it includes HTTPS MITM, so the above is unlikely to solve the problem (but should be implemented anyway!). It's set up as an OS-level proxy - if that setting is possible to change, or override with Chrome's proxy settings, that would fix it. However, that's going to piss off network security!
If you can't do that, then your client is a SOL and should complain up the chain about the security solution breaking legitimate applications.
Edit: I looked around and found this, which seems to claim that using SSL (that is, wss:) is enough. But that's from 2012 - perhaps before ZScaler was able to MITM all HTTPS traffic.
It should be possible to test whether wss: switch will work using https://www.websocket.org/echo.html - if it can connect then everything will work over wss:

Is there a browser-based Websocket listener implementation?

I am interested to know if anyone has built a javascript websocket listener for a browser. Basically the server side of a websocket that runs in a client. This would allow messages to be sent to the client directly. Why? Because instead of having a Node.js, python, java, etc, server process sitting on or near the client/browser, I can just use a thread in the browser as a listening server thread. I don't think that any browsers support this currently.
I've run across answers like this: https://news.ycombinator.com/item?id=2316132
Just curious if anyone has done this. I believe that the current Websockets spec does not support listeners on the browser. It would make the deployment of various peer-to-peer applications a bit easier to deploy.

WebRTC allows for peer-to-peer connections to be made between browsers.
You would still need a server in order for individual users to discover each other but then they could connect directly to each other rather than having to pass all their traffic via a central server.

The idea.
You can use a simple echo server written in any language. Your script can send the data to the server then get it back, handle it on the same page with different functions/classes emulating the real server.
An example: http://www.websocket.org/echo.html
Then, you can think about different formats of packets to/from server to diffirentiate them inside one script.

Modbus TCP communication from HTML/Javascript Webpage

I have a device that uses Modbus TCP. I want to read data from it and display it on a webpage (Without an in between server).
I have found a project that does almost this exact same thing as a Chrome extension:
https://github.com/Cloud-Automation/chrome-modbus
It uses this in the javascript code: chrome.sockets.tcp
I was hoping that I could do the same thing on my webpage using WebSockets.
It seems that websockets would work on my webpage (acting as the client), sending and receiving information from the device (acting as the server). It doesn't seem that websockets is affected by cors.
Does anybody have pointers on where I could start on this? (Or a javascript library would be great)
Is this possible?

Without an in between server will not be possible, unless your plc supports other protocol different than modbus (e.g. post/get).
If your plc is "completely closed" and you only have this port/protocol open, then you need an in between server that makes the conversion of modbus tcp to html. Using node-red as well as the dashboard and modbus flows, you can achieve it.
If you solved it other way, I would like to know how you did it.

I did get this solved without a server in between. I did it using Chrome Sockets link I also made it work using a cordova app for smart phones. Firefox has a sockets api as well, but did not attempt to figure it out for that browser.

I solve this using the PLC Connect in vb, i used vb to pass data in database and get the data through javascript.

Find a server in local network via client javascript in browser

Is it possible to find the ip of an http-server (which will respond on a specific request) in local network only via client javascript in the browser? It should work on mobile and desktop browsers.
The poor mans way trying out all ip(v4) adresses seems not possible because I cannot get reliably the local ip (http://net.ipcalf.com doesn't work on IE and all mobile browsers on iOS). UDP broadcasts don't seem possible with javascript. Is there any other possibility?
My only other alternative seems to be developing a native discovery app for all relevant platforms (win, mac, ios, android).

You just can guess the IP-Range of the local network and send multiple ajax requests to each IP in the Network. You will always get an error for each request, because if there isn't a timeout you get an No Access-Control-Allow-Origin error. However you can distinguish these errors by setting the timeout time to a certain time and track the time until the error occurs. If the tracked time is equal or bigger than your timeout you can suspect a timeout error. Otherwise you will get the error faster. So you can suspect that there is a server behind this IP.
Note: This is no secure method to search for servers and very CPU intensive.

There's no purely client-side way to get that information, no. You'd have to query a site that provides DNS lookup with a cross-domain-friendly API, but that's not purely client-side.