I have made my personal project using WebSocket.
I already know that WebSocket will not connect directly raw TCP Socket.
so, I have thought what if I connect, at first, to Web Server(NodeJS) and then switch to TCP server.
is It possible to switch connection to another server using NodeJS?
If so.
Please let me happy.. Thank you! have a nice day.
I would assume it might be both possible and straightforward to tunnel/proxy TCP traffic. The high level design would be:
Start up a web server with integrated websocket server (use socket.io, really)
When a client makes a websocket connection, create an upstream TCP connection to your target server
Then do full bidirectional piping of messages between the browser<->node socket and the node<->otherServer socket
Devil might be in the details. I haven't tried, but seems feasible.
There's a node project called ws-tcp-bridge as well as a python project that claim to do this already. Neither luke terribly mature, but they might just work or at least provide good reference material.
Related
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/
I'm building a fast paced webgl game and as a common problem I'm experiencing is the retransmits of lost TCP(websockets) packets on higher packet send / receive frequency.
Two options I considered:
1. using webrtc with node.js client to simulate node.js as a peer and connect it to browser for UDP use. So far unsuccessful to connect it to heroku, though works great locally. Is this possible, are there any limitations I overlooked which made it impossible for me to implement into heroku?
2. using multiple websocket connections from single client to a single user on server. Server & client would discard those messages that come from an older tcp packet (let's say 30-60ms delay due to retrasmits). Therefore making it seems like it's a UDP connection. Is this valid, would those connections break each other or work independantly, are there other really bad drawbacks to this method ? This would be an easier alternative to implement.
The reason I would not like to connect two clients via webrtc, but rather need it to connect to server is security. Thanks in advance.
The Almond Plus router and home automation hub now exposes the state of its registered z-wave and zigbee sensors via a websocket.
The websocket API is here:
https://wiki.securifi.com/index.php/Websockets_Documentation
I've aimed a node-red websocket node at the router's local IP address, and have included authentication information in the URL. This seems to work for receiving status changes to devices.
But I need to also be able to send commands over the websocket to flip switches and whatnot. When I create both 'listen on' and 'connect to' websocket nodes in node-red, only the node that's listening connects. Do I need to make two nodes at all? I would have hoped there'd be a way to make one connection to the websocket and use it for two-way communication, but maybe this question just exposes my ignorance of how either websockets or node-red function.
Thanks for any help or information.
You should need both a Websocket in and a Websocket out, but both should be set to "connect to" mode. These handle the input and output side of the connection
I'd have to double check the code, but they should share the same client connection under the covers so there will only be one real Websocket connection. But even if the 2 nodes don't share the connection having 2 separate websocket connections to the same address shouldn't be a problem.
I'm having difficulty finding a robust socket library for doing local tcp socket connections in node.js.
I'm a big fan of using libraries like SockJS or Socket.io for client/server socket connections but I know those use websockets which are different from regular sockets.
I'm wondering if I could use a Websocket library for local connections with similar performance as just using regular sockets or would that include lots of undesired networking overhead?
Basically I want to achieve these three things with sockets and I don't think the native networking module can do them out of the box.
Monitor the health of each socket in it's pool (Alive or dead).
Attach an id to each socket so you know where data is coming from
Build the data from the chunks sent through the sockets
WebSockets are a TCP-like connection, but which actually runs on top of an established HTTP(s) connection (which itself runs within a TCP-connection). This means:
There is additional overhead: all data gets put into special frames, also you have the HTTP connection establishment additionally to the normal TCP connection establishment.
They are not compatible with normal sockets, e.g. you need a WebSockets-aware peer on the other side of the connection.
Apart from that they add no additional reliability or features to the underlying TCP connection. E.g. your requirements are already possible with normal sockets.
I'm developing chat application using app.js which is webkit+node.js framework.
So i have node.js plus bridged web browser environment on both sides.
I want to make file transfer feature somewhat similar to Skype one.
So, initial idea is to:
1.connect clients to main server.
2.Each client gets ip of oposite ones.
3.Start socket or websocket server on both clients and connect to each other.
4.Sender reads the file and transmits it to the reciver.
Question are:
1.Im not really sure that one client can "see" the other.
2.file is a binary data, but websockets are made for text messages so i need some kind of coding/decoding stuff. I thought about base 64 but it has 30% of "overhead" information. So i need something more effitient (base 128?).
3.If it is not efficient to use websocket should i use TCP sockets instead? What problems can appear if i decide to use them?
Yeah i know about node2node and BinaryJS, i just dont know should i use them or not. And i really what to do something myself.
OK, with your communication looking like this:
(C->N)<->N<->(N->C)
(...) is installed on one client's machine. N's are node servers, C's are web clients.
This is out of your control. Some file sharing apps send test packets from the central server to clients, to check whether ports are open and NAT rules are configured correctly, etc. Your clients will start their own servers on some port, your master server can potentially create a test connection to these servers to see whether they're started correctly and open to the web, BEFORE telling other clients that they can send files.
Websockets are great for status messages from your servers to the web GUIs and general client-to-client communication. For the actual file transfers, I would use TCP sockets, see the next answer. On the other hand base64 encoding is really not a slow process, play with it and benchmark its performance, then decide with some data to back up your decision.
You could use a combination: websockets from your servers to the web GUIs, but TCP communication between the servers themselves. TCP servers (and streams) aren't hard to set up in Node, I see no disadvantages. It might actually be less complicated than installing node2node on those servers, since TCP is already built-in.