i read that node.js can fully worked with WebSocket client.
my question is how to support WebSocket api in my node.js server side?
do i need to install something to support that, or just imepements build-in functions?
You can use socket.io, it has both the library for client side and server side (node.js)
Another good one is primus, which wraps up a few different websocket libraries. It is active, and has good documentation for use.
Note: Primus does not, and will not, support socket.io v1.0 or greater So if you must have what socket.io is doing, be aware of your choice.
socket.io is the most straight forward way to implement web sockets in your node app, handling both server-side (as an npm module) and client-side (a script that can be served from your server) features.
http://socket.io/
Related
The title pretty muchs sums it up... I am wondering if there is a way to use socket.io without node.js
socket.io is a library that connects a browser web pages to some server somewhere. There MUST be a socket.io server somewhere that does what you want that you can connect to.
That socket.io server does not have to be written using node.js. There is socket.io support for other languages or environments. The protocol and data format is fully documented so implementations can be written for any environment.
For example, here's a socket.io server implementation in C++.
You can look on github for various server implementations: https://github.com/search?q=socket.io+server.
I would like to communicate between my browser on the client PC and a C++ socket server running on an another PC.
I researched online pretty much enough. I came across socket.io, HTML5 Websockets.
Though I am not sure about socket.io, websockets require a server that supports websockets. The pure old C++ socket server does not. Changing the server side is not an option. Is there anything else I can do with websockets?
Using socket.io, can I achieve the goal without installing an interpreter like nodejs on the server side? Any additional introduction of Javascript/Jquery library on the client side is affordable.
Or is there any other approach I can use?
Thank you.
C++ sockets and websockets are quite different things, having "socket" in their names doesn't mean they operate the same. Websockets protocol is RFC6455. There're several C++ libraries for implementing websocket support, if you can't use any type of web server.
So my application is running Sails.js, which is an extension of node.js. I'm very new to the JS backend framework scene, and I'm attempting to send a TCP message using a socket from the client side. However, in order to do that I need to require('net'). How can I do this? I don't even see the net module in my node_modules folder - does it not come with Sails.js?
How can I resolve this issue?
Also, just for extra clarification, I need to use require() on the browser side - apologies for not being more clear in my original question.
You can't use the node.js net module on the client side. Browsers don't allow you to access plain TCP sockets. That would enable you to circumvent many of their security features, so it simply is not going to happen.
You can implement realtime communication with your own server with web sockets or a wrapper suck as socket.io, but that obviously doesn't let you talk in arbitrary protocols.
I have been working with node.js for a while, now when I'm looking deeper into it, for a chat aplication instead of sending message as client - server - client, there must be some possible ways for direct client to client message sending?
Browsers tend to communicate with servers via HTTP. Some implement other protocols, like websockets & SPDY, but again, these are mostly client-server protocols.
Some plug-ins (like Flash & Java) can open ports and communicate client-client. (AFAIK, haven't actually used them.)
Chrome is the only browser I'm aware of that can (soon) open TCP and UDP sockets from Javascript and do direct client-client communication. At the moment normal web apps can't do this, your app needs to be run as a "Chrome Packaged App", with a special manifest file.
Here are the docs, a blog post describing the feature and a browserify module that can behave like the net node.js module in the browser.
EDIT: This should probably not be tagged as [node.js] since you're trying to run in browsers (not in your node vm), this is a Javascript / Browser question.
This is maybe out of date question, but take a look on PeerJS.
It requires server only as a connection manager (broker). But all communication is done between clients directly.
This does not have anything with server. If you need something like that and if clients are flash you can use RTMFP . For JS i google this library which is js bridge for RTMFP, I dont know how it works. At the end you can write you own library to chat beetween clients but this is much harder(IP addresses are behind NAT, etc...)
I think answer for your question is here
PS Also exist open-source in-browser server which written using JS, but I didn't google it quickly. If you find it, please notify me.
If you just don't want to write your own server you can use:
https://httprelay.io
Use AJAX calls to communicate between peers.
I mean pure javascript client that uses HTML5 sockets and doesn't need to be installed, just open single js file in browser. Is it possible to write such client at all?
No.
JavaScript in the browser does not have raw TCP/IP socket support.
It would be possible to create an ssh client using some server-side technology to proxy the connection, and then do the client using JS. But of course for this you would require a server (like node or whatever)
You couldn't do it directly with Web Sockets, as they're (very deliberately) not a general raw socket capability. You would have to have a server-side proxy to forward keystrokes to the target ssh server.
Existing JS SSH implementations (WebShell, AnyTerm) are using XMLHttpRequest to transport data from the client to the proxy server. You could in theory improve their responsiveness by altering them to use WebSocket instead where available, but it's not really widespread yet. Given the number of incompatible changes that have already happened to the specification over its life, many are likely to be waiting for the ‘final’ version.