I have a node script I'm working on that connects to an IRC channel for twitch.tv and responds to commands, as well as moderates chat lines that are being sent by other users connected.
Currently I open a terminal to the file location and run node app.js to start the IRC connection. But this runs on my mac and I use my PC to play games and watch the chat, so I have to have the Mac next to me to start and stop the IRC chat client app.
I want to move this to a web server where I can log in and start or stop the chat client app from the website, so I don't have to have the Mac next to me all the time.
What would be the best way to go about this?
If you want to see the script I'm working with you can find it here
https://github.com/Jordan4jc/super-fly-twitch-bot
You could create an HTTP server and listen on a port (if you don't mind overkill, express.js could make things easier for you). This server would contain configurations for the URL, authentication, etc. Within the callback that you provide to a URL path, you could close the IRC channels, database connections, and call process.exit(0) once you're confident that you've done everything necessary and you're sure it's what you want.
You can use socket.io as a way to send signals in real time to the application.
Related
I'm new to working with sockets and have a small system design question:
I have 2 separate node processes for a web app, 1 is a simulator that is constantly running and the 2nd is an api server. Both share the same MongoDB database and we have a React app running for the client, served by the api server.
I'm looking to implement socket.io for real-time notifications and so I've set up a simple connection between the api and client.
My problem is that while the simulator runs, there are some events that I also want to trigger push notifications for so my question is how to hook that into everything?
The file hierarchy is like:
app/
simulator/
api/
client/
I saw this article for communication between node processes and I currently have 3 solutions in mind:
Leave hierarchy as it is and install socket.io package inside simulator as well. I'm not sure if sockets work this way but can both simulator and api connect to the same socket?
Move simulator file into api file to fork as a child process so that the 2 processes can communicate via child/parent messaging. simulator will message api which will then emit updates through the socket to client
Leave hierarchy as is and communicate via node-ipc. Same situation as above with simulator messaging api first before api emits that to client
If 1 is possible, that seems like the best solution in my impression. It seems like extra work to add an additional layer of messaging for 2 and 3.
Leave hierarchy as it is and install socket.io package inside simulator as well. I'm not sure if sockets work this way but can both simulator and api connect to the same socket?
The client would have to create a separate socket.io connection to the simulator process. Then, the client can receive data from the API server over one connection and from the simulator over another connection. You would need two separate, independent socket.io connections from the client, one to the API server and one to the simulator. Simulator and API server cannot share the same socket unless they are in the same process.
Move simulator file into api file to fork as a child process so that the 2 processes can communicate via child/parent messaging. simulator will message api which will then emit updates through the socket to client
This is really part of a broader option that the simulator communicates with the API server and sends it data that the API server can then send to the client over the single socket.io connection that the client made to the API server.
There are lots of different ways for the simulator process to communicate with the API server.
Since it's already an API server, you can just make an API for this (probably non-public). The simulator calls an API to send data to the client. The API server receives that data and sends it to the client.
As you suggest, if the simulator is run from the API server as a child process, then you can use parent/child communication messaging built into node.js. Note, you don't have to move the simulator files into the API file at all. You can just use child_process to launch the simulator as another nodejs app from another project. You just have to know the path to that other project.
You can use any another communication mechanism you want between the simulator process and the API server process. There could be a socket.io connection between them. You could use several forms of IPC, etc...
If 1 is possible, that seems like the best solution in my impression.
Your #1 option is not possible as separate processes can't use the same socket.io connection.
It seems like extra work to add an additional layer of messaging for 2 and 3.
My options #1 and #2 are not much code in each server. You're doing interprocess communication. You should expect to use some code to enable that. But, it's not hard at all.
If the lifetime of the simulator server and the API server are always together (they have no independent uses), then I'd probably do the child process thing where the API server launches the simulator and then use parent/child messaging to communicate between them. You do NOT have to combine sources to do this.
The child_process module can run the simulator process by just knowing what directory it is located in.
Otherwise, I'd probably make a small web server on a non-public port in the API server and have the simulator just send data to that other web server. I often refer to this as a control port. It's a way of "controlling or diagnosing" the API server internals and can only be accessed from within the private network and/or with credentials. The reason I'd use a separate web server (in the same nodejs app as the API server) is to make it easy to secure so it can't be accessed from the outside world like the regular public APIs can. You just put the internal web server on a port that is not exposed to the outside world.
You should check Socket.IO docs about adapters and Emitters. This allows to connect to sockets from different node processes and scalability.
I spend already 3 days for reading, watching tutorials about WebSockets, socket.io, node.js and so on.
Basically, I'm a Laravel developer and have just a basic idea about all the rest components.
With regret, after these 3 days I don't have in mind all logic step-by-step of implementing this architecture. I will try to explain what did I understand and you please correct me.
So :
WebSockets - is a bidirectional continuous connection between client and server. It uses another port, and basically it is not a HTTP/S connection.
For making this kind of app like I said, we need one more server, and idk why, but this is Node.js. At this Node.js server we should install socket.io (server-side package) and Redis.
Then, we need to add client-side socket.io (via CDN probably).
At Node.js server we are creating a server.js file where require all modules that we need, like socket.io and Redis. We open a connection for a specific non-used port (as 6001). Then we run this node server.
At front-end we are subscribe-ing to this channel and define method for emitting and listening to the server.
Example :
User1 is connecting to a specific route. User2 as well. User1 type a message for User2, when press Submit, message from User1 is sent to Node.js server, where it is sent in Redis(yes? if yes - Why?), and then Node.js is listening for what to do in this case, and send this message to specific user, or with broadcast to all users except the publisher.
Oh, it's even hard to explain that, too much steps and tehcnologies used.
Can please someone correct my logic? I really want to understand all that process and logic of using this components. Or please, give me some useful articles and videos, may be I didn't saw them. Thanks!
I suggest you read the official docs on how to build chat. Basically what you will have in the end is 2 servers, 1 for your Laravel app and the other for chat (Socket.io) . The key to this is using broadcasters and listening for events on both sides, frontend and backend.
Events are broadcast over "channels", which may be specified as public or private. Any visitor to your application may subscribe to a public channel without any authentication or authorization; however, in order to subscribe to a private channel, a user must be authenticated and authorized to listen on that channel.
I am building an app in which I provide functionality X, Y and chat.
Lets say that X and Y are non-interactive eg. reading articles - which will work fine with REST (on a node.js server) while chat is obviously interactive so it will work best with socket.io!
Questions: 1. Is it possible for me to 'switch on' a socket between the server and the user when the user navigates to the chat part of the application? 2. Can I open up a socket inside a GET request for the url: example.com/chats/usr_id on the node.js server?
3. How can this be accomplished inside a Backbone routing framework?
Yes. Just initialize the connection when the view is rendered (via a controller or script). See socket.io client documentation. You can just connect when the view is rendered and disconnect when the view is terminated. http://socket.io/docs/client-api/
You cannot open sockets with a GET request. Socket.io has it's own build in mechanisms for connecting to a socket server. It will start with Web Socket protocol and fall back to Long Polling. You can however use custom url's for unique things. One again, consult the socket.io documentation: http://socket.io/docs/client-api/
http://www.sitepoint.com/chat-application-using-socket-io/
p.s. I'd suggest reading up on how Web Sockets work, as you don't seem to have a very strong understanding.
this is my first post here so I hope I do well.
So, for a school project I'm handling our game's networking and we have chosen to create a multiplayer fighting game where users are able to use their phones as controllers. Originally, we were going to use phone mobile browsers and so I had some crazy Websocket server, TCP server combination going on.
Since then, we have decided to use a Unity app on the phone instead which has removed the need for the Websocket server. Before I explain the steps, these are two Github gists of the relevant code snippets that you can open in other tabs in order for this to be a bit easier to follow:
NodeJS TCP Server: https://gist.github.com/JesseLeitch/dce3f51eea893ea5872c
Unity TCP Client: https://gist.github.com/JesseLeitch/59212d34a6fad41a2efc
Now, my problem:
I will walk through the process here:
1) I start up my NodeJS TCP server on my laptop.
2) I start up a Unity game, receiving a message from the server that it has connected.
3) My team mate starts up a Unity "game"(it's our controller) on his laptop that connects to the server with a successful connection message once again from the server.
4) My friend presses a button on the controller.
5) The button sends a message to the server. For example, "Jump".
6) Here is where my problem arises. What should happen is the server then sends the message down to the game, the message is processed within the OpenStream function and then it is passed off to a movement script. This is not happening. Nothing is being read in the game and I do not know why.
I know that the writing function is working fine because the console.log on line 14 is outputting properly with his command. What I am unsure of is why the c.write(d) is not seemingly working properly - especially because this worked previously when I was using our previous Game <-> TCP <-> WS <-> Mobile browser set-up.
Any help people can offer is greatly appreciated as I'm stumped and I haven't seemed to find anything relevant in my searching because the server seems to communicate fine except for this issue.
Thanks!
~Camel
User case:
My nodejs server start with a configuration wizard that allow user to change the port and scheme. Even more, update the express routes
Question:
Is it possible to apply the such kind of configuration changes on the fly? restart the server can definitely bring all the changes online but i'm not sure how to trigger it from code.
Changing core configuration on the fly is rarely practiced. Node.js and most http frameworks do not support it neither at this point.
Modifying configuration and then restarting the server is completley valid solution and I suggest you to use it.
To restart server programatically you have to execute logics outside of the node.js, so that this process can continue once node.js process is killed. Granted you are running node.js server on Linux, the Bash script sounds like the best tool available for you.
Implementation will look something like this:
Client presses a switch somewhere on your site powered by node.js
Node.js then executes some JavaScript code which instructs your OS to execute some bash script, lets say it is script.sh
script.sh restarts node.js
Done
If any of the steps is difficult, ask about it. Though step 1 is something you are likely handling yourself already.
I know this question was asked a long time ago but since I ran into this problem I will share what I ended up doing.
For my problem I needed to restart the server since the user is allowed to change the port on their website. What I ended up doing is wrapping the whole server creation (https.createServer/server.listen) into a function called startServer(port). I would call this function at the end of the file with a default port. The user would change port by accessing endpoint /changePort?port=3000. That endpoint would call another function called restartServer(server,res,port) which would then call the startServer(port) with the new port then redirect user to that new site with the new port.
Much better than restarting the whole nodejs process.