As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have read in numerous places that in theory an ssl/443 websocket connection has a high percentage success rate when the client is behind corporate proxy/firewalls. This topic also touches on the issue: Websockets behind enterprises proxies.
Our setup is node.js with websocket-node server side, passing binary data to Chrome 15+ client. No issues with performance as it is blazing fast. I do however have failed connections within corporations, in one example I know they are using an explicit proxy, connecting to that proxy server on port 8080.
The first question is two part: a) what mechanisms can I use to debug the issue to know what is blocking the upgrade, and b) for those with experience what is most likely the culprit?
Secondly, what performance hit will I take if I fall back to flash (i.e. websocket-js)?
Many thanks in advance.
UPDATE: It is now clear that the upgrade handshake request is never being seen by the websocket server, so it is being blocked on the client side before the request ever gets out.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I build a web site which will be deployed and maintained by my company IT dept. My web site backend needs to access a third party API on the internet. The IT say it is not allowed to access external network from this site. Is this an acceptable security restriction? What is the secured way to make an external API call?
The reason why your IT department wants to restrict access to arbitrary external websites is to theoretically make it harder to move any data off your web server to another server in the circumstances where a hacker has managed to upload and execute some arbitrary code.
This is not a totally unreasonable policy to have, as it does help mitigate an attack, even if it doesn't totally block an attack.
The standard way to allows connections to the outside world, but in a controlled manner is for your IT department to setup a proxy, and then your application should make all connections to other websites through that. The proxy should have a white-list of all domains that your code is allowed to connect to, blocking all other requests.
That should allow your software to do what it needs to do, while still mitigating the potential for hackers to be able to move data off the server.
btw if your IT department is capable of it, you should be able to configure the proxy so that any request to a non-whitelisted site will trigger an alarm, as it would indicate a probably intrusion on the server, and it's now running hack uploaded code.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am learning Node.js and am currently studying WebSockets. As I understand it, Socket.io was intended to address inconsistent support that the various browsers had with WebSockets...If you check out caniuse WebSockets, it appears that WebSockets currently has practically full support. Can anyone explain why I should use Socket.io versus WebSockets in this case?
It handles graceful degradation for you to numerous technical alternatives to get bi-directional near-time communication flowing (web sockets, ajax long polling, flash, etc)
As of March 2013 that site lists web sockets at 61% support. This is not "practically full".
As of September 2021 that site lists web sockets at 98% support. All modern browser's support Websockets.
It handles browser inconsistencies and varying support levels for you
(these first 2 things are basically the same value created by jQuery, to put it in perspective)
It includes additional features beyond bare bones web sockets such as room support for basic publish/subscribe infrastructure and things like automatic reconnect
AFAIK it is more popular and easier to get help with than vanilla web sockets, at least at the moment.
However, just like there is VanillaJS for the jQuery haters, if you prefer using the official standard web socket APIs directly, by all means, knock yourself out.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am developing a ASP.NET MVC app deployed on Azure, and looking for a library providing asynchronous transport mechanism/fallback.
After my own research, I've concluded that there are two well-known candidates - Socket.io and SignalR.
My question is simple) What's the pros and cons of them? It there any good reason to use one over the other?
thanks :)
I'd have to say that SignalR is definitely the best approach for your application. With the current build our laptops serving as servers are pushing around 350k messages/s. With the next release it will be even higher (several multiples higher judging by current tests).
Check out the main site: http://signalr.net/
The GitHub: https://github.com/SignalR/SignalR
JabbR for questions: http://jabbr.net/#/rooms/signalr
I've never used SignalR and according to what google tells me it is a replacement solution for .Net apps.
So I guess you should give it a try.
Socket.IO is awesome, I love it but I'm a noder. According to their doc there is no .net/c# bindings. Maybe their doc is not up to date.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a production web service built with Node JS(HTTP Server) on a Linux box with a HAProxy Load Balancer and wanted some kind of graphical tool to do live reporting on the server. I specially wanted to look at requests/min, request failures, etc. Anything out there people would suggest. I need something non-intrusive b/c I will be handling 20mil+ requests a day.
Have you looked at cube (https://github.com/square/cube), graphite/carbon (http://graphite.wikidot.com/) or opentsdb for such data monitoring/display?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am looking for a way to get some sort of monitoring, statistic or management data out of a node.js server instance - not sure what to search for or where to start. Any advice appreciated.
Stats would be requests processed (if applicable) - number of connections and so on.
Don't know if it will fit your needs, but you can try to look at node-monitor. Also Joyent is doing some advanced real-time performance analysis stuff, but it's probably only for their cloud services.
Nodetime can monitor different metrics, such as HTTP Response time, CPU time, OS Load, etc. It is also possible to set up email Alerts based on these metrics. More in the blog post Monitoring Node.js Application Performance.