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.
Related
I never done any API, I just recently become aware of REST, never used sockets or node.js, but I have this simple project in mind using all of these.
Imagine usual app with request/response stuff. Nothing fancy. But then sometimes I need real time functionality, lets say there's a live support for website, a chat. So majority of users never need sockets and everything is easy, but when they do, what's then? How that would look and work with restful api?
As you tag, socket.io is perfect for you. It creates a socket within the browser to your server without the user installing any third party program, using websockets and longpolling. And for the users that have old browsers and don't have those browser built-in functions, it can fallback to a third party plugin: Flash Player, but almost all browsers have it installed.
Is you are used to Javascript or object oriented programming, socket.io and node.js is a walk in the park. If you don't want to use node.js and socket.io, you can write your own implementation of client-server with this info:
WebSockets
Long Polling example
Flash AS3 Socket
As a small adition, simply you need your default web server (Apache, Nginx, Lighthttpd, whatever...) running in default port 80 and also running a node.js server in other port, let's say 8080. That second server will serve all the files needed to connect, because socket.io can only connect to the same domain and port that served the files (security reasons, I guess).
In short, you'll have 2 servers: One serving your entire webpage and another one serving the files needed to connect to your chat (and also serving the chat, obviously).
I have exactly that configuration made in one of my pages (a live sports streaming site) and to add the chat to my site I have this server running in port 8080 and I load it in the main page inside an iframe: http://www.example.com:8080/
As an adition, you can create a complete http server in node.js, but I don't guess that it is useful as a professional web server.
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.
Given a standard Node.js HTTP library, or an existing REST client library, what would be the most feasible way to allow such a library to perform those HTTP requests over the top of my own protocol?
To put this another way: I aim provide a module which looks like a HTTP client. It accepts HTTP requests headers, and returns HTTP responses. What options should I consider to adapt an existing REST library to work with my 'pseudo' HTTP client module, as opposed to the standard Node library HTTP client?
Further background information
I wish to create a server application (based on Node.js) which makes HTTP REST requests to a remote embedded device. However, due to NAT, it is not possible for the application server to make client TCP connections directly to the remote device. Therefore, to get around NAT, I will devise my own proprietary protocol which involves the remote device initiating a persistent connection to the application server. Then, once that persistent connection is established, the Node.js application shall be able to make HTTP requests back over that persistent connection to the networked device.
My objective is therefore to create a Node.js module which acts as a 'bridge' layer between incoming socket connections from the networked devices, and the main application which makes REST requests. The aim is that the application would make REST requests as if it were making HTTP client requests to a server, when in fact the HTTP requests and responses are being conveyed on top of the proprietary protocol.
An option I'm presently considering is for my 'bridge' module to implement an interface that mimics that of http.request(options,[callback]) and somehow enforce a REST client library to use this interface instead of the Node HTTP client. Supposedly at minimum I'd have to lightly modify whichever REST client library I'd use to achieve this.
As explained above, I'm essentially trying to create my own form of NAT traversal using an intermediary server. The intermediary server would provide the front-end UI to users, and make back-end data requests to the embedded networked devices. Connections between embedded devices and application server would be persistent, and initiated from the embedded devices, to avoid the usual NAT headaches (i.e. the requirement to configure port forwarding).
Though I mentioned earlier I'd achieve the device-to-server connection using my own protocol over a raw socket connection, the mechanism I'm actually experimenting with right now is to use plain HTTP together with long-polling. The embedded device initiates a HTTP connection to the application server and delayed responses are used to convey data back to the device when the server has something to send. I would then 'tunnel' HTTP requests going in the reverse direction over the top of this.
Therefore, in simple terms, my 'bridge' layer is something that accepts HTTP connections inwards from both sides (outside device connections, and inside web application REST requests). By using long-polling it would effectively convey requests and responses between the connected clients.
Instead of replacing the http layer, create a man-in-the-middle. Create an http server in node that is the target for all of the rest requests. It then transfers the request onto the proprietary protocol and handles the response by translating back to rest.
This way you don't have to hack the rest code and can even swap it out for another library if needed.
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).
I have a web application that requires PUSH notifications. I looked into node.js and socket.io and have an example that's working. The question I have is, Is it possible to use socket.io only in my client side JS without running a node.js server?
Can a third party server just send requests to a proxy server and may be socket.io just listens to a port on the proxy server and sends back events to it?
Thanks,
You need a server side technology to send data back and forth via web sockets. Socket.io is a communication layer. Which means, you need to have a server side method to send data.
However,
You can use various third party services to use web sockets and notifications. They are relatively easy to use, and they have support for many other languages.
Check some of these out:
http://pusher.com/
https://www.firebase.com/
http://www.pubnub.com/
https://www.tambur.io/
https://fanout.io/
You don't need to run Node.js to have a real time push notifications. You can use a third party service that does it for you. Most of them are cheap, sometimes free for low traffic instances.