Is there a general way to implement part of an application with JavaScript and supplying a persistent connection to a server? I need the server to be able to push data to the client, regardless of the client being behind a firewall. Thanks in advance
See Comet - it's like ajax, but it holds a connection open so the server can push information to the client.
Note that compliant browsers will only hold 2 connections (note: most modern browsers no longer comply) to a particular domain (by default), so you might want to split your domains (e.g. www.yourdomain.com and comet.yourdomain.com) so that you don't drastically slow down the loading of your pages. Or you could just make sure you don't open the comet connection until everything else is loaded. It's just something to be careful of.
You should look into Comet:
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications
With HTTP, the connection has to start from the client. But there are techniques available for having the server hold the connection open and flush data as needed.
These are generally considered to be Comet or HTTP Streaming architectures.
You can use Comet programming techniques for this. Basically the page makes a call to the server that doesn't return until the server has something to send (at which point the client immediately makes the same call). This way the server can push content to the client pretty much whenever it wants.
Support varies depending on platform and is more an issue with the server than the client.
Here are a few questions in a similar vein. And of course all the questions tagged comet
Implementing a self resetting XMLHttpRequest object
Server-side Push in Rails
Is there an alternative of ajax that does not require polling without server side modifications?
Long-lived connections (asynchronous server push) with Apache/PHP/Javascript?
Related
I am building a small chat application for friends, but unsure about how to get information in a timely manner that is not as manual or as rudimentary as forcing a page refresh.
Currently, I am implementing this using simple AJAX, but this has the disadvantage of regularly hitting the server when a short timer elapses.
In researching long/short polling, I ran across HTML5 WebSockets. This seems easy to implement, but I'm not sure if there are some hidden disadvantages. For example, I think WebSockets is only supported by certain browsers. Are there other disadvantages to WebSockets that I should be aware of?
Since it seems like both technologies do the same thing, in what sorts of scenarios would one prefer to use one over the other? More specifically, has HTML5 WebSockets made AJAX long/short polling obsolete, or are there compelling reasons to prefer AJAX over WebSockets?
WebSockets is definitely the future now.
Long polling is a dirty workaround to prevent creating connections for each request like AJAX does - but long polling was created when WebSockets didn't exist. Now due to WebSockets,
long polling is going away no more.
WebRTC allows for peer-to-peer communication.
I recommend learning WebSockets.
Comparison:
of different communication techniques on the web
AJAX - request → response. Creates a connection to the server, sends request headers with optional data, gets a response from the server, and closes the connection.
Supported in all major browsers.
Long poll - request → wait → response. Creates a connection to the server like AJAX does, but maintains a keep-alive connection open for some time (not long though). During connection, the open client can receive data from the server. The client has to reconnect periodically after the connection is closed, due to timeouts or data eof. On server side it is still treated like an HTTP request, same as AJAX, except the answer on request will happen now or some time in the future, defined by the application logic.
support chart (full) | wikipedia
WebSockets - client ↔ server. Create a TCP connection to the server, and keep it open as long as needed. The server or client can easily close the connection. The client goes through an HTTP compatible handshake process. If it succeeds, then the server and client can exchange data in both directions at any time. It is efficient if the application requires frequent data exchange in both ways. WebSockets do have data framing that includes masking for each message sent from client to server, so data is simply encrypted.
support chart (very good) | wikipedia
WebRTC - peer ↔ peer. Transport to establish communication between clients and is transport-agnostic, so it can use UDP, TCP or even more abstract layers. This is generally used for high volume data transfer, such as video/audio streaming, where reliability is secondary and a few frames or reduction in quality progression can be sacrificed in favour of response time and, at least, some data transfer. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers, it still requires some way of exchanging endPoints data, where in most cases developers still use centralised servers to "link" peers. This is required only to exchange essential data for establishing a connection, after which a centralised server is not required.
support chart (medium) | wikipedia
Server-Sent Events - client ← server. Client establishes persistent and long-term connection to server. Only the server can send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol to do so. This protocol is HTTP compatible and simple to implement in most server-side platforms. This is a preferable protocol to be used instead of Long Polling. support chart (good, except IE) | wikipedia
Advantages:
The main advantage of WebSockets server-side, is that it is not an HTTP request (after handshake), but a proper message based communication protocol. This enables you to achieve huge performance and architecture advantages. For example, in node.js, you can share the same memory for different socket connections, so they can each access shared variables. Therefore, you don't need to use a database as an exchange point in the middle (like with AJAX or Long Polling with a language like PHP).
You can store data in RAM, or even republish between sockets straight away.
Security considerations
People are often concerned about the security of WebSockets. The reality is that it makes little difference or even puts WebSockets as better option. First of all, with AJAX, there is a higher chance of MITM, as each request is a new TCP connection that is traversing through internet infrastructure. With WebSockets, once it's connected it is far more challenging to intercept in between, with additionally enforced frame masking when data is streamed from client to server as well as additional compression, which requires more effort to probe data. All modern protocols support both: HTTP and HTTPS (encrypted).
P.S.
Remember that WebSockets generally have a very different approach of logic for networking, more like real-time games had all this time, and not like http.
One contending technology you've omitted is Server-Sent Events / Event Source. What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet? has a good discussion of all of these. Keep in mind that some of these are easier than others to integrate with on the server side.
For chat applications or any other application that is in constant conversation with the server, WebSockets are the best option. However, you can only use WebSockets with a server that supports them, so that may limit your ability to use them if you cannot install the required libraries. In which case, you would need to use Long Polling to obtain similar functionality.
XHR polling A Request is answered when the event occurs (could be straight away, or after a delay). Subsequent requests will need to made to receive further events.
The browser makes an asynchronous request of the server,
which may wait for data to be available before responding. The
response can contain encoded data (typically XML or JSON) or
Javascript to be executed by the client. At the end of the processing
of the response, the browser creates and sends another XHR, to await
the next event. Thus the browser always keeps a request outstanding
with the server, to be answered as each event occurs. Wikipedia
Server Sent Events Client sends request to server. Server sends new data to webpage at any time.
Traditionally, a web page has to send a request to the server to
receive new data; that is, the page requests data from the server.
With server-sent events, it's possible for a server to send new data
to a web page at any time, by pushing messages to the web page. These
incoming messages can be treated as Events + data inside the web page. Mozilla
WebSockets After the initial handshake (via HTTP protocol). Communication is done bidirectionally using the WebSocket protocol.
The handshake starts with an HTTP request/response, allowing servers
to handle HTTP connections as well as WebSocket connections on the
same port. Once the connection is established, communication switches
to a bidirectional binary protocol which does not conform to the HTTP
protocol. Wikipedia
I'm setting up a stock-ticker like web-page, written in JavaScript. I am also writing the server that the page talks to, in C++.
I would like to make the web page efficient, such that it makes sends single subscription message to the app server, and then holds a keep-alive connection open, constantly receiving inbound data pushed from the app server.
At the moment, I have to re-issue the web clients' subscription call every time I receive data from the server. The problem is that each time the XHR object hits readyState(4), the call is effectively completed. Any data arriving at the web page after this is ignored. The web-client can resend data and that resets the object, but the send is unnecessary, and is only being used to reset the XHR object.
I would like to know if it is possible to somehow reset the existing XHR object, and put it into a state where it expects more inbound data, so that when more data is pushed to the web page, the web page responds and processes it.
Thanks in advance for any help you can give. Note: Not using JQuery on this project.
I highly recommend looking into Websockets, especially a library like socket.io, which encapsulates various browser's implementations of Websocket transports into a single API (WS, JSON, JSONP, Flash and Long Polling).
Socket.io client libraries should be now be supported by all major browsers. Your only challenge might be locating a C++ specific server implementation. Hopefully this SO question might be of some help
Otherwise, your only other option is long-polling or comet on the client with a suitable server-side implementation that would scale (i.e. something like an event driven server like NginX as opposed to a thread-per-connection architecture.)
I do appreciate that you are committed to C++ but my humble advise would be to investigate Node.js as it can and does provide a very performant solution with very little effort.
HTH and all the best.
HTTP is a one-off protocol: one request, one response, and you're done. If you want to keep a connection open, you can use Websockets (MDN reference page, client-side code example). However consider it won't be supported on older browsers (IE, for example, just started supporting Websockets on version 10), so you'll probably need to implement a fallback using XHR and long-polling.
You know, a web server. Right now my Socket.IO server loads from a BATCH file that is a JavaScript file. Can you use node and make the socket.io server load from a web browser. Like a web-server utility tool or something of the sort.
That's explicitly not possible due to the design of WebSockets. It starts as a special HTTP request that, after the handshaking, drops the HTTP protocol and strips it down into the WebSocket protocol -- a nearly bare protocol similar to (but slightly more managed than) raw TCP. Because a web browser specifically cannot handle HTTP requests, it could never initiate the socket as a server.
This was done specifically so it wouldn't be possible to write a drive-by botnet website to use scores of users' computers for DDOS attacks without their knowing, amongst other security concerns.
So it wouldn't surprise me if Flash supported that kind of behavior. ;) (I know Java can, but who enables Java applets?)
I'd say you Can. Not that I can think of a good use case.
You would need to put the startup code somewhere where the web server could run it and you would need to get the web server to return some information to the browser to allow it to then connect. You would also have to insert the socket.io code into the browser after the socket server had started.
So I Think that it would indeed be possible but rather complex for little gain. I suppose one possible use case would be to restart a socket server after failure. Actually I'd do that a slightly different way, probably by calling an external script from Node.
fortunatly the answer is no. if you mean by load / launched , NO. but you can create a script on a server that launch another server once a url is requested by a a client.
I write a browser game (php, javascript) and I do not know how to make a callback. necessary that the server itself
found a client and call the function (only had one)
Don't write a browsergame if you don't know the basics! Browsergames are way too complex to learn programming.
If you want to make the server notify a client about something you will need to keep a connection open (search keywords: COMET, long polling) as you cannot initiate connections from the server to clients.
For this I can suggest you using Firebase. It is a API that let you to add cloud Data management that your user clients do. You can use that communication to search for client.
If I understand your question, what you need is a socket. Since you're using PHP and Javascript, a WebSocket might be just what you're looking for. With WebSockets, the connection between the client and the server is persisted, so the server can just push data/messages to any or all of the clients connected to it at any point in time. Likewise, the any client connected to the server can push messages/data up to the server.
Here's a video that describes how it works a bit https://www.youtube.com/watch?v=oJxWhmt5m-o
I just learned about the AJAX Push Engine but it runs on Linux/Apache which is not an option for me.
http://www.ape-project.org/
Currently with AJAX to keep a page current I have to poll the server frequently which is not great for a high traffic site. The option to push data to the client only when necessary is a great option, but natively JavaScript does not support sockets, AFAIK. One trick I read about, but the site is now gone, is to use a Flash module to handle socket communications and relay message to JavaScript.
The trouble with researching this approach is that "JavaScript push" as keywords come up with the push function for arrays instead of the context I want.
How could establish a persistent connection with the server to do push communications in the browser? Do I need Flash/ActionScript or is there another option that would work with all of the currently active browsers? (IE6/7/8, FF3, Safari, Chrome)
When it comes to the server I also need to work out the complications due to Origin policy as well as port security. I appreciate anything you can point out that will explain the available options.
What you want is COMET, or I would also look up long polling.
I asked a similar question.
The Direct Web Remoting (DWR) library supports Reverse Ajax, which sounds like what you are looking for. It supports Comet (along with Polling and PiggyBack). More info on their website: http://directwebremoting.org/dwr/index.html
This is interesting stuff, but I did not read anything about scalability issues on these Wiki pages. What does a web server do if you have 10,000 open long-polling connections?
Also, for those not familiar with the underlying concepts, it is important to understand that pushing data from the server to the client in an ad-hoc fashion is impossible and will always be. Even if the HTTP protocol supported this, the network would not, particularly if there is a NAT firewall involved.
So any solutions that claim to offer server push communication must rely on connections that are initiated by the client, kept open, and will eventually time out. I have concerns about this because it must have negative consequences for server scalability and performance.
The thing you are looking for is websocket https://en.wikipedia.org/wiki/WebSocket