I'm using gRPC to implement RPCs between local Python processes. I'd like to make sure that the server only responds to local requests, i.e., from the same machine. However, I don't see a way to do it in the gRPC API. Am I missing something?
Related
I'm trying to develop a web application in nodejs. I'm using an npm package called "simple-peer" but i don't think this issue is related to that. I was able to use this package and get it working when integrating it with a laravel application using an apache server as the back end. I could access the host machine through it's IP:PORT on the network and connect a separate client to the host successfully with a peer-to-peer connection. However, I'm now trying to develop this specifically in node without an apache back end. I have my express server up and running on port 3000, I can access the index page from a remote client on the same network through IP:3000. But when I try to connect through webrtc, I get a "Connection failed" error. If I connect two different browser instances on the same localhost device, the connection succeeds.
For reference: i'm just using the copy/pasted code from this usage demo. I have the "simplepeer.min.js" included and referenced in the correct directory.
So my main questions are: is there a setting or some webRTC protocol that could be blocking the remote clients from connecting? What would I need to change to meet this requirement? Why would it work in a laravel/webpack app with apache and not with express?
If your remote clients can not get icecandidates, you need TURN server.
When WebRTC Peer behind NAT, firewall or using Cellular Network(like smartphone), P2P Connection will fail.
At that time, for fallback, TURN server will work as a relay server.
I recommend coTURN.
Here is an simple implementation of simple-peer with nodejs backend for multi-user video/audio chat. You can find the client code in /public/js/main.js. Github Project and the Demo.
And just like #JinhoJang said. You do need a turn server to pass the information. Here is a list of public stun/turn servers.
I'm working on a data sharing app using node js, the idea is to create an application that can connect peers using node-js without using any kind of central dependency i.e a signalling server or something of its kind. After a lot of research I'm always back to this diagram but it only makes sense if there is no signalling server I'm targeting LAN networks so that I don't have to deal with NAT.
To be specific, I would like some to answer these specific question
Is it possible to connect to webrtc on LAN, i.e the webrtc connection will connect using my client's ip
Is it possible to use websockets without a central server, or something like websockets
Is it possible to connect two clients on LAN using node js without using any hardcoded Ips or asking users to enter ip.
Since you are using node.js, you can very well use raw UDP (dgram) and use UDP broadcasting for device discovery - then you do not need any form of centralization required by websockets/webRTC.
The answer to all your questions is Yes!
Also, there is a lof WebRTC server that you can use them on a simple Linux box, like Janus, Kurento, etc. I've tested them and they have worked with some mischief, lol. So, run it and next read their API to exchange anything you want on their medium.
I'm not sure about Janus but the Kurento has a nodeJS client itself. Read the Local Installation and JavaScript Kurento Client.
Additionally, if you want to make a WebSocket connection, it has enabled by default configuration.
To change the port, enter this command at the final step:
npm start -- --ws_uri=ws://https://185.164.72.144/:8888/kurento --as_uri=https://185.164.72.144:6008/
My team and I are working on a digital signage platform.
We have ~ 2000 Raspberry Pi around the world connected to a Nodejs server using Socket IO. The Raspberries are initiating the connection.
We would like to be able to scale horizontally our application on multiple servers but we have a problem that we can’t figure out.
Basically, the application stores the sockets of the connected Raspberry in an array.
We have an external program that calls the API within the server, this results by the server searching which sockets will be "impacted" by the API call and send them the informations.
After lots of search, we assume that we have to stores the sockets (or their ID) elsewhere (Redis ?), to make the application stateless. Then, any server can respond to a API call and look the sockets in a central place.
Unfortunately, we can’t find any detailed example on how to do that.
Can you please help us ?
Thanks
(You can't store sockets from multiple server instances in a shared datastore like redis: they only make sense in the context of the server where they were initiated).
You will need a cluster of node.js servers to handle this. There are various ways to make a cluster. They all involve directing incoming connections from your RPis to a "generic" hostname, for example server.example.com. Behind that server.example.com hostname will be multiple node.js servers.
Each incoming connection from each RPi connects to just one of those multiple servers. (You know this, I believe.) This means one node.js server in your cluster "owns" each individual RPi.
(Telling you how to rig up a cluster of node.js servers is beyond the scope of this answer. Hints: round-robin DNS or a reverse-proxy nginx front end.)
Then, you want to route -- to fan out -- the incoming data from each API call to each server in the cluster, so the server can route it to the RPis it owns.
Here's a good way to handle that:
Set up a redis cache or other shared data store. It can be very small.
When each node.js server starts, have it register itself as active. That is, have it place its own specific address for handling API calls into the shared server. The specific address is probably of the form 12.34.56.78:3000: that is, an IP address and port.
Have each server update that address every so often, once a minute or so, to show it is still alive.
When an API call arrives at server.example.com, it will come to a more-or-less randomly chosen node.js server instance.
Get that server to read the list of server addresses from the redis cache
Get that server to repeat the API call to all servers except itself. Add a parameter like repeated=yes to the repeated API calls.
Then, each server looks at its list of connected sockets and does what your application requires.
On server shutdown, have the server unregister itself -- remove its address from redis -- if possible.
In other words, build a way of fanning out the API calls to all active node.js servers in your cluster.
If this must scale up to a very large number (more than a hundred or so) node.js servers, or to many hundreds of API calls a minute, you probably should investigate using message queuing software.
SECURE YOUR REDIS server from random cybercreeps on the internet.
I came across this awesome library xterm.js which is also the base for Visual Studio Code's terminal. I have a very general question.
I want to access a machine(ssh into a machine ) on a local network through a web based terminal(which is out of network, may be on a aws server). I was able to do this in a local network successfully but I could not reach to a conclusion to do it from Internet-->local network .
As an example - An aws server running the application on ip 54.123.11.98 which has a GUI with a button to open terminal. I want to open terminal of a local machine which is in a local network somewhere behind some public ip on local ip 192.168.1.7.
Can the above example be achieved using some sort of solutions where i can use xterm.js so that I don't have to go for building a web based terminal? What are the major security concerns I should keep in mind while exposing the terminals this way ?
I was thinking in line with using a fixed intermediate server between AWS and local network ip and use some sort of reverse ssh tunnel process to do this but I am not sure if this is the right way or could there be a more simple/better way to achieve this.
I know digital ocean, google cloud , they all do this but they have to connect to a computer which has public ip while I have a machine in a local network. I don't really want to configure router to do any kind of setup .
After a bit of research here is working code.
Libraries:
1) https://socket.io/
This library is used for transmit package from client to server.
2) https://github.com/staltz/xstream
This library is used for terminal view.
3) https://github.com/mscdex/ssh2
This is the main library which is used for establishing a connection with your remote server.
Step 1: Install Library 3 into your project folder
Step 2: Start from node side create a server.js file for open socket
Step 3:
Connection client socket to node server (both are in local machine)
The tricky logic is how to use socket and ssh2.
On emission of socket you need to trigger an SSH command using the ssh2 library. On response of the ssh2 library (from server) you need to transmit the socket package to the client. That's it.
Click here to find an example.
That example will have these files & folders:
Type Name
------------
FILE server.js
FILE package.json
FOLDER src
FOLDER xtream
First you need to configure your server IP, user and password or cert file on server.js and just run node server.js.
P.S.: Don't forget to run npm install
Let me know if you have any questions!
After some research later I came across this service : https://tmate.io/ which does the job perfectly. Though if you need a web-based terminal of tmate you have to use their ssh servers as a reverse proxy which ideally I was not comfortable with. However, they provide tmate-server which can be used to host your own reverse proxy server but lacks web UI. But to build a system where you have to access a client behind NAT over ssh on web, below are the steps.
Install and configure tmate-server on some cloud machine.
Install tmate on the client side and configure to connect to a cloud machine.
Create a nodejs application using xterm.js(easy because of WebSocket based communication) which connects to your tmate-server and pass commands to the respective client. (Beware of security issues of exposing this application, since you will be passing Linux commands ).
Depending on your use case you might need a small wrapper around tmate client on client-side to start/stop it automatically or via some UI/manual action.
Note: I wrote a small wrapper on client-side as well to start/stop and pass on the required information to an API server (written in nodejs) which then pass on the information to another API which connects the browser to the respective client session. Since we had written this application it included authentication as well as command restrictions of what can be run on terminal. You can customize it a lot.
There will be no human being in the loop, and both endpoints are autonomous Node.js applications operating as independent services.
Endpoint A is responsible for contacting Endpoint B via secure web socket, and maintaining that connection 24/7/365.
Both endpoints will initiate messages independently (without human intervention), and both endpoints will have an API (RESTful or otherwise) to receive and process messages. You might say that each endpoint is both a client of, and a server to, the other endpoint.
I am considering frameworks like Sails.js and LoopBack (implemented on both endpoints), as well as simply passing JSON messages over ws, but remain unclear what the most idiomatic approach would be.
Web Sockets have a lot of overhead for connecting to browsers and what not, since they try to remain compatible with HTTP. If you're just connecting a pair of servers, a simple TCP connection will suffice. You can use the net module for this.
Now, once you have that connection, how do you initiate communication? You could go through the trouble of making your own protocol, but I don't recommend it. I found that a simple RPC was easiest. You can use the rpc-stream package over any duplex stream (including your TCP socket).
For my own application, I actually installed socket.io-client and let my servers use it for RPC. Although if I were to do it again, I would use rpc-stream to skip all the overhead required for setting up a Web Socket connection.