To use socket.io on the client side, usually we start a node.js server and go like this:
<script src="/socket.io/socket.io.js"></script>
or with specific port:
<script src="http://localhost:3700/socket.io/socket.io.js"></script>
Question is:
is it necessary to use node.js server to serve socket.io.js ?
...or is it possible to
make a local copy of socket.io.js instead of goes to server every single time we need socket.io?
like, we go to view source and copy everything we got from the source of script tag,
paste and save it as socket.io-local.js so that next time we use:
<script src="socket.io-local.js"></script>
will that work ?
Updates
Thanks for everyone's great response,
I'm asking this because in the case I'm involved, I don't actually have access to the server:
I am writing the client-side to connect to other developer's Socket Sever which is written in Java.
Therefore I'll have to think a way to work around the fact that I don't have a server there for me.
from what I've been testing,
this way seems to work but I really don't know what's happening behind the scene.
You obviously can host the socket.io client library anywhere and pull it in to a page. However, it will almost certainly not work with your Java-based server.
To understand why, you need to understand what socket.io is really doing behind the scenes; the client library is only a small part of it.
Socket.io actually defines and implements its own protocol for realtime communication between a browser and a server. It does so in a way that supports multiple transports: if—for example—a user's browser or proxy doesn't support WebSockets, it can fall back to long polling.
What the socket.io client actually does is:
Makes a XHR GET request for /socket.io/1. The server responds with a session ID, configured timeouts, and supported transports.
The client chooses the best transport that the user browser supports. In modern browsers, it will use WebSockets.
If WebSockets are supported, it creates a new WebSocket to initiate a WebSocket connection (HTTP GET with Upgrade: websocket header) to a special URL – /socket.io/1/websocket/<session id>.
If WebSockets aren't supported by the browser or fail to connect (there are lots of intermediaries in the wild like proxies, filters, network security devices, and so forth that don't support WebSocket requests), the library falls back to XHR long polling, and makes a XHR request to /socket.io/1/xhr-polling/<sesion id>. The server does not respond to the request until a new message is available or a timeout is reached, at which point the client repeats the XHR request.
Socket.io's server component handles the other end of that mess. It handles all the URLs under /socket.io/, setting up sessions, parsing WebSocket upgrades, actually sending messages, and a bunch of other bookkeeping.
Without all of the services provided by the socket.io server, the client library is pretty useless. It will just make a XHR request to a URL that doesn't exist on your server.
My guess is that your Java-based server just implements the WebSockets protocol. You can connect directly to it using the browser-provided WebSocket APIs.
It is possible that your server does implement the socket.io protocol – there are a few abandoned Java projects to do that – but that's unlikely. Talk with the developer of your server to find out exactly how he's implemented a "socket server."
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-client.js found at the root of this repository.
https://github.com/LearnBoost/socket.io-client
I have a module called shotgun-client that actually wraps socket.io. I needed to serve a custom client script as well as the socket.io client script, but I didn't want every user of my module to have to include multiple script references on their pages.
I found that, when installed, you can serve the generated client script from socket.io by reading the file /node_modules/socket.io/node_modules/socket.io-client/dist/socket.io.js. So my module adds a listener for its own URL and when it serves my custom client script it also serves the socket.io client script with it. Viola! Only a single script reference for the users of my module :)
While this is technically possible, I don't see why you'd need to do that. If you're concerned about reducing the data that goes over the wire, this change won't actually do much beyond the few characters saved in the shorter src tag. Simply changing the location of the JS file on the server won't actually improve performance - the JS has to be sent.
Proper caching (which Socket.IO has) will return a 304 Not Modified (and not re-send the JS file every time you load a page).
Related
This is kind of a weird question I think to ask, but I have browsing about for the past some time and cannot find a clear definite answer.
I understand that a client connects to its own server and communicates with the web-server through sockets and I kind of see how that works in php (I have never used php but have used sockets before so I understand the concept).
The issue is I'm trying to get a real view of this.
The question is, do websites generally use sockets and contact a web-server to fetch data or the actual html? Or is it a rare choice made in some areas?
If it is generally used, then is the "real" js usually in the server? or is it client-side (for performance sake)?
Context:
Let me explain a bit where I'm coming from, I'm not a web expert, but I am a computer engineering student so most concepts are easy to understand. A "real"-er view of this would be very helpful.
Now, onto why I'm asking this. I'm developing a web-app as part of a project and have done a fair bit of progress on it but everything was done on a local dev server (so basically a client?)
I've started wondering about this because I wanted to use a database for my website and since I want to connect to something, I will need to connect to a web-server first (for security sake).
My question's intent is to guide me on how and most importantly, where, to setup this server.
I don't think showing any code would be of help here, but assume I have my client running on localhost:1234, my database on localhost:3306, I think I should have a web-server on another port so I can establish this communication, but I want to do it in a clean and legitimate way so all of my current solutions can be ported online with little to no changes (except the obvious)
There's a bunch to unpack here.
First of all, servers can be distant or local. Usually they are distant, local server are mostly used for development purposes.
Even if your server is on your local machine, it still isn't the client. The client is the part that is connecting to your server. For web development it is usually the user browser.
Javascript is a language that can be used server-side, with a NodeJS server, but more often client-side, in your user browser.
Your website, or web application, communicate with your server through various means. Most common one is the HTTP protocol, used to make server requests such as data request to populate your page (in case of an API server, REST or otherwise), or simply request the actual page to display in the browser. The HTTP protocol works by resolving URLs, and making requests to your server registered to this url using special methods such as GET, POST, DELETE, etc...
Sockets are used to create a persistent connection with your server that works both ways. It is mostly used for realtime updates, such as a live chat, as it allows you to push updates from the server instead of having the client request everything.
In most cases the database can be found on the same server as the one serving the website or application, as it is a lot easier to handle, and often faster without the extra networks requests to get the data. However it can be placed on another server, with it's own API to get the data (not necessarily web related)
Ports such as 1234 or 3306 are often used for local development, however once your move your project to a host service, this is usually replace by urls. And the host service will provide you with a config to access the associated database. Or if you are building your own server you might still use ports. It is heavily dependent on your server config.
Hope this clear some things up.
In addition to #Morphyish answer, in the simplest case, a web browser (the client) requests an URL from a server. The URL contains the domain name of the server and some parameters. The server responds with HTML code. The browser interprets the code and renders the webpage.
The browser and the server communicates using HTTP protocol. HTTP is stateless and closes the connection after each request.
The server can respond with static HTML, e.g. by serving a static HTML file. Or, by serving dynamic HTML. Serving dynamic HTML requires some kind of server language (e.g. nodejs, PHP, python) that essentially concatenates strings to build the HTML code. Usually, the HTML is created by filling templates with data from the database (e.g. MySQL, Postgres).
There are countless languages, frameworks, libraries that help to achieve this.
In addition to HTML, the server can also serve javascript that is interpreted in the browser and adds dynamics to the webpage. However, there could be 2 types of javascript that should not be mixed. NodeJS runs on the server and formats the server response, client javascript runs on the browser. Remember, client and server are completely isolated and can communicate only through an HTTP connection.
That said, there ways to make persistent connections between client and server with WebSockets, and add all kinds of exotic solutions. The core principle remains the same.
It does not matter if server software (e.g apache, nginx) is running on your local machine or anywhere else. The browser makes a request to an address, the DNS and network stack figures out how to reach the server and makes it work.
I am new to WebSocket world and even after a week, I still could not find how to use it with PHP without using any 3rd Party Library. Or not sure if it is even possible.
I have 3 questions,
1) Do we must need to use some 3rd Party APIs or Libraries like Ratchet, PHP-Push-WebSocket or PHP WebSocket to enable PHP to communicate over WebSocket protocol?
2) If your answer to above question is yes then what is the advantage/purpose of using Apache's mod_proxy_wstunnel?
3) If I use any PHP WebSocket 3rd Party Library, then do I still need to enable and use Apache's mod_proxy_wstunnel? If No, then again what is the purpose of Apache's mod_proxy_wstunnel?
I went through this Using go-websocket behind Apache mod_proxy_wstunnel. In this question, the OP has indicated some go-websocket but unfortunately the link is giving 404 Error and hence I cannot understand if the user has used any 3rd Party API.
Any help would be highly appreciated. Thanks in advance.
PHP is not created for WS. Of course you can do this, but it is full of while (true) and fsock_open [*]. And you have to have access to the shell to run the WS-server with php-cgi. (usually)
Choose a language that supports threads / asynchronous communication. Now on the top is Node.js. In addition, better use dedicated libraries to support older browsers, etc. If you are thinking about alternatives to ajax then you can use socket.io. If you want to create one-to-all communication (eg chat, broadcast messaging), go one step further and use one of the Bayeux implementations, for example: Faye.
The mod_proxy_wstunnel extension adds an extra layer to the WS server. Depending on the configuration, it can support DDoS, queue, load-balancing, local port swapping, and https support. But better use this for nginx.
So, for test you don't need mod_proxy_wstunnel, and on production, you should add an extra layer of security, eg NGINX ws tunelling.
[*] Sorry, I made some mistakes. PHP has native support for WebSockets. That content is going to set you negatively to WS in PHP.
Websockets are events, and PHP is poorly managed with it.
Just to elaborate a bit on why Apache + PHP is unsuitable for WebSocket support...
1) Do we need to use some 3rd Party APIs or Libraries like Ratchet, PHP-Push-WebSocket or PHP WebSocket to enable PHP to communicate over WebSocket protocol?
No, you can just open a local socket and accept requests using low-level Socket API (example), or you can even upgrade an existing request to WebSocket. But there is a problem - read on...
2) If your answer to above question is yes then what is the advantage/purpose of using Apache's mod_proxy_wstunnel?
The advantage of mod_proxy_wstunnel is that it allows users to establish WebSocket connections with your server using the server's HTTP(S) port (usually 80 or 443) instead of connecting on a custom port (e.g. 9000). This does not eliminate step 1 though, as it simply proxies WebSocket connections from Apache to the custom port.
3) If I use any PHP WebSocket 3rd Party Library, then do I still need to enable and use Apache's mod_proxy_wstunnel?
The problem with Apache / PHP setup is that PHP code always runs in scope of a specific HTTP request. This is a problem because Apache is not designed for long-running requests. Apache can support a very small amount of active requests (usually 150 or so), which is barely enough to handle regular (short-lived) traffic on an medium-size site. In addition, by default max_execution_time is set to 5 minutes, which means any request (and any WebSocket connection inside of it) will be killed after that.
If No, then again what is the purpose of Apache's mod_proxy_wstunnel?
mod_proxy_wstunnel handles persistent connections without tying up a request thread. So it allows one Apache instance to handle hundreds of thousands of WebSocket connections. But again, it's just a tunnel, it can't "invoke" PHP, as it can only proxy a WebSocket connection to some other application.
If you have access to the server machine, you can run a standalone PHP script, which would handle WebSocket connections as a daemon outside Apache (e.g. via systemd), and optionally use mod_proxy_wstunnel to proxy requests to it.
But by itself, Apache + PHP architecture is unsuitable for production-grade WebSocket support.
What's the difference between socket.io-client and socket.io ?
I also find a bit confusing that socket.io-client also has a section for "server-side usage"
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'm creating an app where the server and the clients will run on the same local network. Is it possible to use web sockets, or rather more specifically, socket.io to have one central server and many clients that are running native apps
? The way I understand socket.io to work is that the clients read the web-pages that are served from the server but what happens when your clients become tablet devices running native apps instead of web pages in a browser?
The scenario I'm working with at the minute will have one central server containing a MEAN app and the clients (iPads) will make GET requests to the data available on the server. However, I'd also like there to be real-time functionality so if someone triggers a POST request on their iPad, the server acknowledges it and displays it in the server's client-side. The iPad apps will (ideally) be running native phonegap applications rather than accessing 192.168.1.1:9000 from their browser.
Is this technically possible to connect to the socket server from the native apps or would the devices have to send POST requests to a central server that's constantly listening for new 'messages'? I'm totally new to the whole real-time stuff so I'm just trying to wrap my head around it all.
Apologies if this isn't totally clear, it's a bit hard to describe with just text but I think you get the idea?
Correct me if I am wrong.
You have multiple iPads running native app. They send a POST request to your node JS server which is running in a computer in the same local network. Whenever the server receives a request from app, you want to display that a request has been received in your computer screen.
If my assumptions about the scenario is correct, then it is fairly easy to do. Here are the steps to do it.
Create a small webpage (front end). Load socket IO in the front end page like this -
<script type="text/javascript" src="YOUR_SERVER_IP/socket.io/socket.io.js"></script>
Then connect to server using var socket = io(). This should trigger connection event in your backend.
Handle all POST request from apps normally. Nothing special. Just add a small snippet in between. socket.emit('new_request', request_data). This sends new_request event to front end.
Handle the new_request in your front end using socket.on('new_request', function(request_data) { ... });. That's it. No need to add anything to your native app for realtime update.
The second step would be a little complicated as it is necessary to make socket variable available inside all POST requests. Since you chose node.js, I don't think you need any help with that.
Not totally clear on your project, but I'll try to give you some pointers.
An effective way to send data between native apps and a server is using a REST server. REST is based on HTTP requests and allows you to modify data on the server, which can connect to your database. The data returned is typically either JSON or XML formatted. See here for a brief intro: http://www.infoq.com/articles/rest-introduction
Android/iOS/etc have built in APIs for making HTTP requests. Your native app would send a request to the server, parse the response, and update your native UI accordingly. The same server can be used from a website using jQuery ajax HTTP requests.
Express.js is more suited to serving web pages and includes things like templating. Look into "restify" (see here: mcavage.me/node-restify/) if you just want to have a REST server that handles requests. Both run on top of node.js (nodejs.org).
As far as real-time communication, if you're developing for iOS look into APNS (Apple Push Notification Service). Apple maintains a persistent connection, and by going through their servers you can easily send messages to your app. The equivalent of this on Android is GCM (Google Cloud Messaging).
You can also do sockets directly if that's easier for you. Be careful with maintaining an open socket on a mobile device though, it can be a huge battery drain. Here's a library for connecting ObjC to Socket.IO using websockets, it may be useful for you: https://github.com/pkyeck/socket.IO-objc
Hope that helps!
To answer your question, it is definitely possible. Socket.io would serve as the central server that can essentially emit messages to all of the client. You can also make Socket.io listen for the messages from any of the clients and serve the emitted message to the rest of the clients.
Here's an example of how socket.io can be used. Simply clone, npm install, and run using 'node app.js'
All you have to do is to provide a valid server address when you connect your socket from the iPad clients:
var socket = io.connect( 'http://my.external.nodejs.server' );
Let us know if you need help with actual sending/receiving of socket events.
It is possible to connect to Websockets from your apps.
If you are using PhoneGap then you need a pluging that gives support to websockets in your app (the client) and then use websocket like normal way using Javascript see this.
If your app is native iOS look into this it could help you.
The primary use of the Sockets in your case is to be a bidirectional "pipe" between an app and server. There is no need of server sending the whole web-page to the native app. All what you need is to send some data from server to the client(app) in response to POST (or GET) request and then using this data on client side to update client's UI in real-time. If you are going to use moderate amount of devices (say tens of them), you may have connected all of them to the server permanently keeping individual socket connection open for every individual link server-to-app. Thus you may deliver data and update client's state in real time.
In fact web browsers also employ sockets to communicate to web servers. However as in general case there is no control on amount of concurrent clients in Internet, for the sake of limited networking resources conservation, servers do not keep sockets open for a long time, closing it just after the web-page was sent to client (or timeout has expired). That's how HTTP protocol works on the low level. The server waiting for the HTTP clients (browsers) by listening the 80 port, responding them by sending the whole web page content, then closing the connection and keep waiting for another requests on the same port.
In your case it's basically a good idea to use socket.io as it's a uniform implementation of sockets (ok WebSockets) on both client and server side. The good starting point is here
I'm working on a websocket based project. The main server, which includes both a web and websocket server, mainly acts as a forwarding hub to other websocket servers. These secondary websocket servers are not expected to also have web servers running, but are expected to be hosting files that may or may not need to be downloaded (transferred directly via websocket depending on need).
While the files aren't expected to be very large--current test file hovers around 2KB, but we expect a standard of around 10-20KB, and possibly much larger if we allow encoding of images and other data-heavy material--files are expected to be demanded from an array of hosts repeatedly. That is, clients may 'request' a file from multiple, independent websocket servers (not at the same time). However, it would be expected a single client may request the same file from a single websocket server as much as 20 times a day or more.
So, to cut down on bandwidth, I am wondering if it is possible to cache these dynamic files doing purely client-side work.
With HTML5 You can leverage the browsers Application Cache by using a Manifest.
In such a manifest you can specify files which should be cached on the clientside. Invalidation of these caches happens through Javascript so that is also on the clientside.
More on Application Cache and manifest files you'll find here: http://www.html5rocks.com/en/tutorials/appcache/beginner/