I have an application that spins up websocket connections on random ports after checking to make sure the port has not yet been assigned. Each connection has a front facing card with a slider to create/destroy the TCP connection based on the port number they are assigned (and stored). It is simple to spin up a server for each socket with the predefined event handling that it comes with but i am unsure of a way to allow the user to kill the tcp connection. What this would look like is the user from the front end woudl slide the toggle intot eh off position and I would take that entities id, query for its port number and would then need to close that port's connection. I am hoping there is a way with node to be able to query for its active servers and act on them as one pleases but I have not found any articles suggesting a way.
I am hoping there is a way with node to be able to query for its active servers and act on them as one pleases but I have not found any articles suggesting a way.
There is no such thing built into node.js.
If you wanted to be able to operate on all the webSocket servers you had started, then you could just add them to an array as you start them.
const serverArray = [];
// code elsewhere that starts a server
let server = new WebSocketServer(someRandomPort);
// push an object into an array that has the port and server
serverArray.push({server, port: someRandomPort});
Then, you could iterate over that array at any time to do something to all of them or to find a server that is using a particular port.
But, it sounds to me like you don't really need multiple webSocket servers. Multiple clients (with however much security you want) can all share the same server. That's the usual client/server design (multiple clients talking to one server).
Related
I developing an app that connects devices on the same network.
Any devices can be the server, I want clients to be able to find the server automatically without users having to enter the IP address of the server manually.
This is how I plan to do it:
Find the IP of the client, eg 192.168.0.2
Loop through 192.168.0.(0->255)
Try to connect with all those IPs until the connection success
Is that the right way? Can I do it faster? Do IP on the same network always in the range of x.x.x.(0->255)?
I'm using both Java and JavaScript(Node.js) if that is relevance.
One option here: instead of "iterating" the address range and sending individual packets to each address; you could consider sending a broadcast to the whole subnet.
In other words: your client just shouts "I am here"; the server "hears" that and responds; similar to how protocols like DHCP work.
Edit on the comment on how to react to "broadcast not answered":
Actually, you are now coming closer to those topics that make "distributed" computing hard. There are many problems that could kick in; and many different solutions to them.
It starts with: do you go with one broadcast; or instead try multiple times?! And maybe increase the delays between subsequent broadcasts?
Thing is: nobody here can tell you that. The answers very much depend on your "domain", and what makes the most sense to the users of your application.
My suggestion here: look into existing open source products that do similar things; and study what kind of problems they identified; and how they deal with that. I know, this is pretty broad; but that "broadness" comes out of "the overall subject is really broad".
udp broadcast is how my client finds my server on the local network.
the server sends back the port number the socket server is using for connections
when the server is running, the response is near instant, so I only have a 2 second timeout, and only try once
I am using a web socket server (node JS) to act as a signaling server. I want to create a P2P mesh network - everyone is connected to each other.
What would be the order of operations/events when:
The 1st peer joins
The subsequent peers join
Do every connecting peer send an offer to the signaling server that is then sent to all other connected peers? I am unsure whether this is the right approach.
If what you are trying to do is create a mesh network with audio and video flowing at all times to everyone via a mesh network then I'd suggest reconsidering. Getting this to more than 3 or 4 users to work well is hard to impossible to achieve. See here for an explanation of what goes on the network for different network topologies: http://testrtc.com/different-multiparty-video-conferencing/
If you are trying to do this to get data connected (non voice or video), then you can do that, but again, the number of peer connections you can place in a single browser is limited and each one you add puts some overhead. Today, I wouldn't try to get this over 40 or 50 at most.
By your question, I am assuming all clients will be connected to your server via a WebSocket. You will probably end up routing messages through the server and creating peer connections judiciously when you want to connect a specific user to another one - or a small group of users together.
For the group scenario, I'd use an SFU model - look at Jitsi (https://jitsi.org/Projects/JitsiVideobridge) and Kurento (http://www.kurento.org/) for possible alternatives.
WebRTC connects client to client. If your client connects to at least one other - the other can have a list of others, as the others also has a list of as many others they possible can know. Then it propagates fast. The topology in the list is up to you. Signaling is not needed, because the information to connect with others is in the list.
Is it possible to allow two clients interact directly without a server?
I am referring to websites, for example is it possible to create a chat between two clients that are on the same website using only javascript on the client-side.
If not, what's the minimum server-side to make a chat work between active clients on a website? (eg: one PHP file and no database) ?
My idea:
Storing the conversation would be easily done using localStorage on each client, the problem is how to send some data from client1 to client2 without storing anything (or at most that message) in the database. Also, note that "past" conversations should not visible, so no storage needed for that.
Note that I don't want any nodeJS or websocket solutions, I want something as simple as possible. So, what's the minimum code and files to make a chat between online users?
The WebRTC APIs will allow JavaScript to initiate a direct browser-to-browser connection, but a server is still required to serve the page and coordinate session initiation.
The APIs are still rapidly evolving and only available in bleeding-edge browsers, so it's not yet ready for real production use.
However—to be honest—for what you're trying to do, the easiest option is Node and socket.io:
var http=require('http'), express=require('express'), sio = require('socket.io')
, app=express(), srv = http.createServer(app);
app.use(express.static(__dirname+'/static'));
sio.listen(srv);
srv.listen(80);
...and now you have a working websockets server in 5 lines. Put all your client-side stuff in the static folder and you're good to go.
HTML5 has got a new Web Sockets feature
With this the server intervention is almost nullified..The server and client communicate through the new protocols
ws - Web Sockets protocol
wss - Web Sockets Secure protocol (similar to https)
Live demo
No, It's not possible. If you want a chat box, you have to store the data in the server. And what connects the clients, like display the chat texts and the same things to every client, they come from the server.. So it's not possible like that. Well, even free chat boxes put the data of each sites in their servers.
As for your idea using localStorage, maybe it's possible (But still, using the new WebSocket protocol), but it doesn't work in the time dimension, right? if another user joins, they won't see what has been sent before.
Is there any advantages of having two distinct websocket connections to the same server from the same client? To me this seems a bad design choice, but is there any reason why/where it should work out better?
There are several reasons why you might want to do that but they probably aren't too common (at least not yet):
You have both encrypted and unencrypted data that you are sending/receiving (e.g. some of the data is bulky but not sensitive).
You have both streaming data and latency sensitive data: imagine an interactive game that occasionally has streamed video inside the game. You don't want large media streams to delay receipt of latency sensitive normal game messages.
You have both textual (e.g. JSON control messages) and binary data (typed arrays or blobs) and don't want to bother with adding your own protocol layer to distinguish since WebSockets already does this for you.
You have multiple WebSocket sub-protocols (the optional setting after the URI) that you support and the page wants to access more than one (each WebSocket connection is limited to a single sub-protocol).
You have several different WebSocket services sitting behind the same web server and port. The way the client chooses per connection might depend on URI path, URI scheme (ws or wss), sub-protocol, or perhaps even the first message from client to server.
I'm sure there are other reasons but that's all I can think of off the top of my head.
I found that it can make client logic much simpler when you are only subscribing to updates of certain objects being managed by the server. Instead of devising a custom subscription protocol for a single channel, you can just open a socket for each element.
Let's say you obtained a collection of elements via a REST API at
http://myserver/api/some-elements
You could subscribe to updates of a single element using a socket url like this:
ws://myserver/api/some-elements/42/updates
Of course one can argue that this doesn't scale for complex pages. However, for small and simple appications it might make your life a lot easier.
Greets to all!
I want to create private messaging based on websockets.
It is possible to implement session between two users using websockets?
Yes
WS connections go through a central server and as such it is impossible to bypass that and make a direct connection to two users. You can on the server facilitate communication between two users though. You would have to have the users either preselected or make some sort of "join" action, possibly from a group list of logged in users. Then your application would manage a "private" sort of chat between the two, essentially an instance of the main chat except users aren't added automatically but rather by intent.
I think that in order to do this, you will need to obtain the users' IP addresses and open the destination ports on each. Doing this should be impossible, given that the sockets should handshake (and you don't have access to the handshake process).
You can't do this directly between two browsers. The WebSockets spec does not specify a way to listen for incoming connections to the browser, only outgoing connections. You need some sort of WebSockets endpoint that both browsers can initiate connections to.