i wrote a simple C++ Server which is waiting for clients.
I want users to be able to connect to this client by opening a webpage without installing anything. So the only thing that comes to my mind is using Javascript. Since the server needs to react in realtime later on ( performance is an issue ) sending data with POST/GET is not wanted.
Is this possible with Node.js or Socket.io ? I am trying to find a good example but i only find node.js servers. And when i open a socket with
var socket = io.connect('localhost:25003');
it is sending weird data.
Does anyone have a simple example with a javascript client that can connect to anything and send raw data?
You cannot do plain TCP from browsers (unless you're writing a browser addon/extension or using something like a Java applet or a Flash bridge possibly). Socket.IO always uses HTTP. However those HTTP connections can then be upgraded to WebSockets or other protocols, depending on what the browser and/or Internet connection supports.
The "weird data" you're seeing is probably an HTTP message.
Related
I having some doubts that:-
what is need to use the socket.io client we can use only the socket.io server to stop refreshing the app.
what is different between the socket.io client and socket.io server.
check this link
socket-io.client is the code for the client-side implementation of socket.io. That code may be used either by a browser client or by a server process that is initiating a socket.io connection to some other server (thus playing the client-side role in a socket.io connection).
A server that is not initiating socket.io connections to other servers would not use this code. This has been made a little more confusing that it probably should be because when using socket.io, it appears that both client and server are using the same socket.io.js file (because they both refer to a file with the same name), but is not actually the case. The server is using a different file than the client.
From the Github page for socket-io.client:
A standalone build of socket.io-client is exposed automatically by the socket.io server as /socket.io/socket.io.js. Alternatively you can serve the file socket.io.js found at the root of this repository.
Keep in mind that there are unique features that belong to client and server so it should not be a surprise that they use some different code. Though they share code for parsing the protocol and things like that, the server has the ability to run a server or hook into an existing web server and it has methods like .join() and .leave() and data structures that keep track of all the connected sockets and is expected to live in the node.js environment. The client has the ability to initiate a connection (send the right http request), do polling if webSockets are not supported, build on a native webSocket implementation if present, etc....
i want to make TCP server with Node.js and then connect it from browser without http , express and socket.io moudles. something like what i do in java or c# but this time from browser.
The browser does not contain the capability for Javascript in a regular web page to make a straight TCP socket connection to some server.
Browser Javascript has access to the following network connection features:
Make an http/https request to an external server.
Make a webSocket connection to an external server.
Use webRTC to communicate with other computers
In all these cases, you must use the libraries built into the browser in order to initiate connections on these specific protocols.
There is no capability built into the browser for a plain TCP socket connection. A webSocket (which can only connect to a webSocket server) is probably the closest you can come.
I am wondering if someone has used the socket.io-client library for communicating between servers instead of communicating between browsers to server.
Is this kosher?
Is the behavior of the library pretty much the same when the client library is running on a server vs running in the browser?
Can the socket.io-server library initialize connections with clients, or do socket.io-clients need to initialize connections?
Is this kosher?
Yes, that is exactly what the socket.io-client is designed for. It works great for communicating between two servers.
Is the behavior of the library pretty much the same when the client
library is running on a server vs running in the browser?
Yes, the behavior is identical. The only difference under the covers is that the browser implementation is built on top of the browser's webSocket support whereas the server-side client uses the socket.io webSocket implementation.
Can the socket.io-server library initialize connections with clients,
or do socket.io-clients need to initialize connections?
Only socket.io servers are "listening" for incoming connections. Somebody has to connect TO the socket.io server. You can't connect TO a socket.io client. A client must connect to a server. So, a socket.io client (which can be either in a browser or on a server) must be the one that creates the connection. Once connected, data can be sent either way on that connection.
Considering you are talking about the JavaScript version of the socket.io-client:
Yes, of course it is legitimate to use it server-side. it is just a "client" library, not only a "client-SIDE" library.
The behavior is the same, yes.
Clients need to initialize connections.
There is a server side usage example the Socket.io-client documentation
Other versions of the socket.io-client are also available in different languages (swift, java, CPP), that you can find on their Github page.
I have a program in an embedded device that outputs an xml string to a socket. The embedded device has lighthttpd has a web server. I want to use a web based client (no flash/silverlight) to connect to the socket and pull the xml data every second.
I looked at Node.js with Socket.io to get what I want to do, but I am not clear about how to proceed. Searching through the Node.js and Socket.io documentation and examples I see standard client-server behavior, nothing regarding what I am trying to do.
Basically, the web server is just there to accept a connection from a client on the socket that the embedded application is outputting data to. Basically the web server's purpose is to just let the client retrieve data from the raw tcp socket that the embedded application is writing to. Please advice.
I solved the problem using Websockify, which acts as bridge between a TCP Socket and a browser.
The html client will connect to a websocket, and Websockify will listen on the websocket port and transmit data between the websocket and the tcp socket.
Web browsers have the ability to do HTTP requests (which can be web page requests or Ajax requests for data) and webSocket connections. You will need to pick one of these two mechanisms if you're sticking with stock browser access.
If the lighthttpd web server in the embedded device does not support webSockets, then your choice will like be an Ajax call from the browser to your server. This is basically just an HTTP request that make return something different than a web page (often JSON data) and is designed to fetch data from the server into a web client.
If the lighthttpd web server does support webSockets, then you could use a webSocket connection to fetch the data too. This has an advantage of being a persistent connection and allows for the server to directly send data to the client (without the client even requesting more data) whenever it wants to (more efficient for constant updates).
An Ajax connection is generally not persistent. A client sends an Ajax request, the server returns the answer and the connection is closed. The next request starts a new Ajax request.
Either Ajax requests or webSocket connections should work just fine for your use. All browsers still in use support Ajax. WebSockets are supported in modern browsers (IE10 and higher).
Once you decide upon a client connection strategy, then you'd build your web app on the embedded device that served as the middleman between the browser and the data on the embedded device. It would collect the appropriate data from the embedded device and then be able to send that to browser clients that connected and requested the data.
I'm not sure exactly why you mentioned node.js. In this circumstance, it would be used as the web server and the environment for building your app and the logic that collects the data from your device and feeds it to the requesting web browser, but it sounds like you already have lighthttpd for this purpose. Personally, I recommend node.js if it works in your environment. Combined with socket.io (for webSocket support), it's a very nice way to connect browsers directly to an embedded device. I have an attic fan controller written in node.js and running on a Raspberry Pi. The node.js app monitors temperature probes and controls relays that switch attic fans and node.js also serves as a web server for me to administer and monitor the node.js. All-in-all, it's a pretty slick environment if you already know and like programming in Javascript and there's a rich set of add-in modules to extend its capabilities available through NPM. If, however, your embedded device isn't a common device that there is already support for node.js on or it doesn't already have node.js on it, then you'd be facing a porting tasks to make node.js run on it which might be more work than using some other development environment that already runs on the device like lighthttpd.
I basically want to know if its possible to use Socket.io using the server-side only with no client side? BUT I want to know if my server-side can instead connect with a different site that I cannot use Socket.io to connect to.
Use PhantomJS to load the third-party site and then inject your own javascript into the page to catch events and send those events back to your own server.
socket.io is a two-way connection. Client <--> Server. You must have a socket.io endpoint at both ends to even establish a connection in the first place. And, then once you establish the connection, you must have agreed upon messages that can be exchanged between the two ends for it to do anything useful.
It is not useful to have a server-side socket.io that doesn't actually connect to anything and nothing connects to it. It wouldn't be doing anything, just sitting there waiting for someone to connect to it.
It is possible to have two cooperating servers connect to one another with socket.io (one server just acts like a client in that case by initiating the connection to the other server). But, again both endpoints must participate in the connection for the connection to even be established and certainly for it to do anything useful.
If you just want to download the contents of a site for scraping purposes, then you would not use socket.io for that. You would just use the nodejs http module (or any of several other modules built on top of it). Your server would essentially pretend to be a browser. It would request a web page from any random web server using HTTP (not socket.io). That web server would return the web page via the normal HTTP request. Your receiving server can then do whatever it wants with that web page (scrape it, whatever).