I'd netty running on my dev machine which runs Windows 7. Now, When I migrate my app to a CEntOS 6 server, all websocket communications do not work. I thought that it is because of iptables restrictions. So, I added entries for the ports used to the iptable.
My interface binding information is 0.0.0.0:port, and the URL I use in my client code to access the websocket is ws://SERVER_IP:port/. I've googled for sometime now in vain. Any assistance will be appreciated. My client uses JavaScript.
UPDATE:
When I run netstat -nlp, I see :::port_number for local address and :::* for the foreign address. I'm thinking that this should be 0.0.0.0:port_number for the local address and 0.0.0.0:* for the foreign address. May be I'm missing something in my configuration.
UPDATE:
After a painstaking troubleshooting process, I found out the root of my problem was my network security configuration. After resolving this, everything now works fine.
Related
I am building an application using react.js and socket.io, I have my backend code for the socket.io server in one folder and the client/ frontend react.js code in a separate folder. I have it set up to where the server is listening on local host:4000 and the client is listening on 3000, I have connected the front end and back end in my app.js using this line of code..
const socket = io.connect('http://localhost:4000');
I am curious as to what this means. does it mean that when I deploy my website that it will be hosting my server from my computer? Does it mean that it will be hosting the sockets from the client's computers? is the localhost:4000 used for testing purposes and will need to be changed later upon deployment of the website? If none of these are correct, any explanation would be greatly appreciated. If my code is fine the way it is and will not need to be changed upon deployment of my website, please let me know.
Thank you to anyone who can help!!!
does it mean that when I deploy my website that it will be hosting my server from my computer?
It means it will try to connect to a Socket.io server running on the same computer as the browser is running on.
This will usually fail. (Your development environment is an exception because you are running both browser and server on the same computer).
is the localhost:4000 used for testing purposes and will need to be changed later upon deployment of the website?
Yes.
Yes, you will need to change it when you deploy it to your site.
'http://localhost:4000' is an absolute reference meaning it will auto resolve to the localhost environment. It is also advisable to switch to https for a more secure connection.
I have a node server with several node projects. I use nginx to get them all responding on port 80. Now, this works for the initial http request. For the websockets, I need to use the direct server port. To keep everything alive while developing I would like to try this, projects will have a dev and live version. Once de dev is stable, I will copy it to the live folder. The live folder is runned by a systemctl script where I define a difrent port to the live version so I can dev without taking the live down. The problem I encounter now is, how can I get the running server port in my client side Javascript so that the dev page connect to the dev port and visa versa?
currently I'm only using express, socket.io and mysql. I have no further npm packages installed. I searched allot but there is not to mush I can find. I found how to connect the socket to the page url but I cannot use that because that URL will always be on port 80. Further I found allot of huge packages that has no use for me since the original page is just static, the dynamics all run over websockets.
Is there any way to parse the port number in the clients .js file like I could do fairly easy in php? And if so, what would be the most efficient way. I could let javascript check if the page uses the live or dev URL but I would prefer not to hardcode my dev URL into JS where it is for everyone to see.
run a third node.js socket.io server program, all your clients connect to this server first.
In this simple node.js program, determine the type of clients by any means. e.g. different user id for dev/production users
send the server url and port to your client according to its type (dev or production)
you may also use this technique to separate your users to different production servers.
I'm trying to configure an AWS Greengrass group through their JavaScript SDK, and I get everything up and running up to where I have a deployment. The issue is that the deployment seems to be stuck on "in progress" and there are no cloudwatch logs to help me.
I looked at the core device, and this is what I saw in the /greengrass/ggc/var/logs/system/runtime.log file:
[2019-01-18T03:17:22.64Z][INFO]-Greengrass Root: /greengrass
[2019-01-18T03:17:22.64Z][INFO]-Greengrass Write Directory: /greengrass/ggc
[2019-01-18T03:17:22.64Z][INFO]-Group File Directory: /greengrass/ggc/deployment/group
[2019-01-18T03:17:22.64Z][INFO]-Default Lambda UID: 498 GID: 496
[2019-01-18T03:17:22.64Z][INFO]-===========================================
[2019-01-18T03:17:22.64Z][INFO]-The current core is using the AWS IoT certificates with fingerprint: 7591dcd10e96f86dd2d323d468b84b419b26280bbcfd3c0eee45c5a12c6d2dd7
[2019-01-18T03:17:22.641Z][WARN]-worker process info: /greengrass/ggc/packages/1.7.0/var/worker/processes
[2019-01-18T03:17:22.641Z][WARN]-worker process info: /greengrass/ggc/packages/1.7.0/var/worker/processes
[2019-01-18T03:17:22.641Z][INFO]-Reloading registry
[2019-01-18T03:17:22.642Z][INFO]-The current core is using the AWS IoT certificates with fingerprint: 7591dcd10e96f86dd2d323d468b84b419b26280bbcfd3c0eee45c5a12c6d2dd7
I've checked and I'm able to successfully hit the ATS endpoint using OpenSSL and the certificates that I have. I'm using Amazon's recommended certificate from the Greengrass tutorial RSA 2048 bit key: Amazon Root CA 1.
What are some diagnostic steps or clues where to go from here?
I've had this issue before. I believe it's just a bug with the internals getting mangled from a bad deployment.
The way I brute force hanging deployments are to create a new core and then add known working lamdbas in a working group to the new core, kill and restart the deamon on the core device, and then redeploy.
So for me, I had 2 things misconfigured which prevented successful deployment
The deployment was stuck "in progress" because the permissions in the policy and role that were attached needed lambda permissions to deploy. Once I did this, the deployment went from "in progress" to "failed deployment" which brought me to the second mistake.
The EC2 instance which was hosting the core software somehow didn't run the setup shell script correctly (probably didn't run it as sudo) and my cgroups were not fully setup for memory (not sure what this means but you need it setup)
Thank you Steve B for the help!
I've encountered the mention issue many times. In my case, the problem was always related about internet connectivity.
To check your system, before starting the deployment process, please subscribe # (wildcard) to listen all topics and check out messages related about deployments. If you don't see any incoming messages, It means network connectivity is the problem.
Then you can run this command ping greengrass-ats.iot.region.amazonaws.com where the greengrass core installed to investigate the issue. If everything seems Ok, you can start deployment again. But If you see lost packages, you should investigate the main issues which causes the network problem.
I have problem with my app with Action Cable on Heroku:
WebSocket connection to 'ws://localhost:3000/cable' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
My production.rb:
config.action_cable.url = "wss://NAME.herokuapp.com/cable"
config.action_cable.allowed_request_origins = ['https://NAME.herokuapp.com', 'http://NAME.herokuapp.com']
I tried to specify the server in the cable.js as well:
#App ||= {}
App.cable = ActionCable.createConsumer("wss://NAME.herokuapp.com/cable")
I tried to change it in development.rb just in case but nothing helps. The Heroku is still trying to connect to localhost.
Another weird thing that has nothing in common with it I think, is that the app is not able to process some js code like: alert('test') or console.log("haha") despite of some js code works and I tried assets:precompile as well.
In localhost, everything works perfectly. Any idea what can be wrong with heroku and the setting?
While ActionCable was in development, I remember you had to startup 2 servers for the cable connection and for Rails. I don't think that is still needed for the final release.
My guess is that you don't have Redis provisioned on your Heroku instance, whereas in Production, ActionCable relies on Redis for it's server communication.
To fix this, you should do the following:
heroku addons:add redistogo
heroku config | grep REDISTOGO_URL
In your config/cable.yml, set the Redis url to the one given. I guess you should also be able to use ENV['REDISTOGO_URL'] in place of the url.
Let me know if that helps.
If it's working locally but not remotely it may be an SSL problem. Make sure you properly set up an SSL endpoint for the secure websocket (wss):
https://devcenter.heroku.com/articles/ssl-endpoint
Also, there is an excellent blog post on Heroku about how to set up Action Cable: https://blog.heroku.com/real_time_rails_implementing_websockets_in_rails_5_with_action_cable. Alas, the article does not mention the necessity of setting up an SSL endpoint for the Heroku deployment to work.
Merry Christmas!
I am trying to configure KMS on my Ubuntu 14.04 (64 bit). I could install the KMS server successfully following the guide at https://www.kurento.org/docs/6.0.0/installation_guide.html.
Also, downloaded the Javascript HelloWorld tutorial from https://www.kurento.org/docs/6.0.0/tutorials/js/tutorial-1-helloworld.html. I could run the example successfully on localhost on Google Chrome Version 47.0.2526.106 (64-bit) on the same Ubuntu System.
But, I could not see the local video nor the loop backed video. Only a spinner icon is shown on both the Video placeholders. Consulting the Console log reveals a problem after creating the SDP offer. The error is as described below.
kurento-client.js:21072 WebSocket connection to 'wss://127.0.0.1:8433/kurento' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
I am no expert on web sockets and stuff. Any help on this would really help me to proceed forward.
Note: I am running the example on HTTP, not on HTTPS. I guess that would not be the cause of the problem, though.
Regards,
LazyCoder7
I managed to solve it. I was wrong on my guess though, HTTPS was indeed required in order to make the WebSocket connection ( i was not aware of that part ). Created a certificate file (.pem) (from crt and key file already in the helloworld folder) and configured the KMS server to use the certificate. After this I was able to see myself and the same me in loopback :)
You are following an old version of the documentation. Since Chrome 47, in is mandatory to server pages through HTTPS if you want to use the getUserMedia APi. So we updated all our tutorials, and they now have a self-signed certificate. In case of the JS tutorials, you also need to configure KMS to expose a secure WS signalling connection, as the browser directly connects to the media server to control it.
Please follow the latest version of the documentation here
Be sure that the KMS is running on the port 8433 (not 8888), if you are using docker
docker run -d --name kms -p 8433:8433 kurento/kurento-media-server:trusty-latest