I want to create a facebook-like notification system (the one who appears on the bottom-left side of the screen when someone comment on your post, for example).
The thing here is that the server needs to send you a notification when someone comments in the site in this exactly moment. I think this is called PUSH-System (sorry for my bad english).
I tried with node.JS but my dedicated server can't install it. Only if I buy a very expensive VPS plan.
So, is there a way using jQuery or something like that to make this Push notification system?
Thanks !!
, rodrigo.-
If you want a low latency, efficient solution you should use WebSockets. However you need to have fallbacks in place such as long-polling / short polling available if the browser doesn't support WebSockets.
The WebSocket Protocol provides a full-duplex (two way) connection between the server and client. Traditional HTTP is half-duplex (one way). This link will give you an overview of the benefits of using WebSockets vs HTTP: http://www.websocket.org/quantum.html.
You need to be aware that most modern browsers support WebSockets, but use different protocols. See here: What browsers support HTML5 WebSocket API?.
In addition to the references I posted in the comments above, implementing a Long Polling technique is a common solution to eliminate large amounts of normal polling. Here is what Wikipedia says about it:
Long polling is a variation of the traditional polling technique and allows emulation of an information push from a server to a client. With long polling, the client requests information from the server in a similar way to a normal poll. However, if the server does not have any information available for the client, instead of sending an empty response, the server holds the request and waits for some information to be available. Once the information becomes available (or after a suitable timeout), a complete response is sent to the client. The client will normally then immediately re-request information from the server, so that the server will almost always have an available waiting request that it can use to deliver data in response to an event. In a web/AJAX context, long polling is also known as Comet programming.
Related
I'm looking for the 'way to go' (i.e. the most efficient, most used, general accepted way) when it comes to the reloading of data from a web server to a front end. In the end application, I will have several output fields where data has to be written to, for example like this:
The data streams will be different from each other in the end application. The lines will have to be reloaded with fresh, up to date data from the server.
I have been thinking of using Ajax requests to update like every second, but there has to be an other way to do this. Ajax requests will cause a lot data traffic. Also, when using the Facebook chat, you don't have to wait every second, chats are received almost instantly. Yet I don't see any Ajax polling requests being made when I use the developer tools of Mozilla Firefox. This made me think if there would be a different way to do this.
I've looked into Node.js, but it appears that isn't possible with my host.
I have heard people talking about Ajax Push, is that what I should use? If so, can you give me a basic usage example?
If not, what would then be the way to go when having multiple data streams that have to be reloaded within a second?
Requirements are speed and low data traffic. It therefore wouldn't be an option to continuously poll the server, I think, because that would create an enormous overhead.
I don't think it's of any importance, but I'm using PHP5.3 in the back end and JavaScript with jQuery 1.9.1 in the front end.
This question has been asked a number of times, but in a slightly different ways. Here are a few references that are worth a read:
What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?
Using comet with PHP?
Apache with Comet Support
Server Scalability - HTML 5 websockets vs Comet
How to implement event listening in PHP
In summary: if you are looking at building your solution using PHP on Apache then holding open persistent connections (HTTP long-polling or streaming) is going to use up resources very quickly (is highly inefficient). So, you would be better using a hosted solution (*disclaimer - I work for a hosted solution).
HTTP-Long polling and HTTP Streaming are solutions which have been superseded by Server-Sent Events and WebSockets. So, where possible (where the web client provides support) you should use one of these solutions before falling back to an HTTP-based solution. A good realtime web technology will automatically handle this for you.
Since your diagram shows you are subscribing to multiple data streams you should also consider a Publish/Subscribe solution that naturally fits with this. Again, a good realtime web tech solution will provide you with this.
Also see the realtime web technology guide.
I think what you are looking for is generally called Comet. The was this technique is often made to work is as follows:
The client (web browser) makes a request to the server for new data. This is not reloading the page, but rather is done in JavaScript
The server responds to the request when it has some data for the client. Again, this doesn't impact the UI since it isn't the page itself that's getting reloaded: the loaindg of data is done "in background" so to speak, in JavaScript code.
On the serve side, the request waits for new data, and returns the new data when available, or returns nothing if a timeout interval (defined on the server) is reached. This timeout is usually set to be lower than the browser HTTP timeout. The reason for this is so that the server can know whether a particular client got a particular piece of data. If the request is allowed to time out on the client side, the original request might be responded to by the server after the client has timed out, and the client will not get the data, even though the server thinks that it did.
The data is indeed usually transferred as JSON, but you can choose whatever encoding you'd like. See here for one example of how to do this. Goosh is another example of this technique, and so is Interactive Python Shell. The code for all is available.
On the PHP side you will want to create a page that will respond to these "background" JavaScript Comet requests. It could be the same page as the one that user loads, but let's say it is different, for ease of explanation. So the user loads index.php and the JavaScript Comet code calls getNewData.php to retrieve new data.
In your getNewData.php you will want to wait for your event and return the data then. You don't want to use polling for this, but there are PHP libraries that allow one to use various interprocess communication strategies to wait on events, see this question for instance. The high-level pseudocode for your getNewData.php would look as follows:
parse JSON request
Enter an efficient wait state (with timeout), waiting for your "new data is available" event
Did previous step time out?
Yes: send response indicating no data
No: send response with new data
I'm looking for the 'way to go' (i.e. the most efficient, most used, general accepted way) when it comes to the reloading of data from a web server to a front end. In the end application, I will have several output fields where data has to be written to, for example like this:
The data streams will be different from each other in the end application. The lines will have to be reloaded with fresh, up to date data from the server.
I have been thinking of using Ajax requests to update like every second, but there has to be an other way to do this. Ajax requests will cause a lot data traffic. Also, when using the Facebook chat, you don't have to wait every second, chats are received almost instantly. Yet I don't see any Ajax polling requests being made when I use the developer tools of Mozilla Firefox. This made me think if there would be a different way to do this.
I've looked into Node.js, but it appears that isn't possible with my host.
I have heard people talking about Ajax Push, is that what I should use? If so, can you give me a basic usage example?
If not, what would then be the way to go when having multiple data streams that have to be reloaded within a second?
Requirements are speed and low data traffic. It therefore wouldn't be an option to continuously poll the server, I think, because that would create an enormous overhead.
I don't think it's of any importance, but I'm using PHP5.3 in the back end and JavaScript with jQuery 1.9.1 in the front end.
This question has been asked a number of times, but in a slightly different ways. Here are a few references that are worth a read:
What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?
Using comet with PHP?
Apache with Comet Support
Server Scalability - HTML 5 websockets vs Comet
How to implement event listening in PHP
In summary: if you are looking at building your solution using PHP on Apache then holding open persistent connections (HTTP long-polling or streaming) is going to use up resources very quickly (is highly inefficient). So, you would be better using a hosted solution (*disclaimer - I work for a hosted solution).
HTTP-Long polling and HTTP Streaming are solutions which have been superseded by Server-Sent Events and WebSockets. So, where possible (where the web client provides support) you should use one of these solutions before falling back to an HTTP-based solution. A good realtime web technology will automatically handle this for you.
Since your diagram shows you are subscribing to multiple data streams you should also consider a Publish/Subscribe solution that naturally fits with this. Again, a good realtime web tech solution will provide you with this.
Also see the realtime web technology guide.
I think what you are looking for is generally called Comet. The was this technique is often made to work is as follows:
The client (web browser) makes a request to the server for new data. This is not reloading the page, but rather is done in JavaScript
The server responds to the request when it has some data for the client. Again, this doesn't impact the UI since it isn't the page itself that's getting reloaded: the loaindg of data is done "in background" so to speak, in JavaScript code.
On the serve side, the request waits for new data, and returns the new data when available, or returns nothing if a timeout interval (defined on the server) is reached. This timeout is usually set to be lower than the browser HTTP timeout. The reason for this is so that the server can know whether a particular client got a particular piece of data. If the request is allowed to time out on the client side, the original request might be responded to by the server after the client has timed out, and the client will not get the data, even though the server thinks that it did.
The data is indeed usually transferred as JSON, but you can choose whatever encoding you'd like. See here for one example of how to do this. Goosh is another example of this technique, and so is Interactive Python Shell. The code for all is available.
On the PHP side you will want to create a page that will respond to these "background" JavaScript Comet requests. It could be the same page as the one that user loads, but let's say it is different, for ease of explanation. So the user loads index.php and the JavaScript Comet code calls getNewData.php to retrieve new data.
In your getNewData.php you will want to wait for your event and return the data then. You don't want to use polling for this, but there are PHP libraries that allow one to use various interprocess communication strategies to wait on events, see this question for instance. The high-level pseudocode for your getNewData.php would look as follows:
parse JSON request
Enter an efficient wait state (with timeout), waiting for your "new data is available" event
Did previous step time out?
Yes: send response indicating no data
No: send response with new data
I've used a bit of AJAX with PHP for things like submitting forms and I've recently started looking into websockets. I followed this tutorial to understand the basics. From what I gather, websockets keep the connection open whereas AJAX opens and closes a request.
My question is do websockets provide any advantage over AJAX if you're just submitting forms or simple tasks like auto_complete (which there's a jQuery plugin for anyway)? Maybe the tutorial isn't the greatest, but it seems like there's a heck of a lot more code involved to get websockets to work(at least with PHP) than just a simple AJAX call (or using jQuery which bundles it). I've read in a few places that it's a bit quicker, but if I'm working on something that isn't receiving tons of requests, will it really make a difference? Correct me if I'm wrong, but not all browsers support websockets either, right?
Websockets have two advantages.
they have much less overhead, which results in a better network performance
they allow the server to send data which the client hasn't explicitely requested.
The second one is the most important advantage.
In AJAX, everything the server sends must be the response to a previous request by the client, and every request can only be answered once. But in many applications, especially multi-user applications, events happen on the server and these events must be pushed to the clients immediately. There are workarounds for that in AJAX, like delaying the answer to a request until there is something to report (long-polling), but these are quite dirty. That's why there are Websockets. With a websocket connection, the server can send messages to the clients when it wants and as often as it wants, without having to wait for a request from the client.
But unfortunately WebSockets also have disadvantages:
They aren't as well-supported by web development frameworks (yet!)
Not all web browsers support it (but most desktop browsers already do)
Many proxies and reverse-proxies can't relay websocket traffic (yet!)
Actually, AJAX and websockets are two different categories. AJAX is a concept, a technique. With AJAX you can perform (as the acronym stands for) asynchronous requests, so the browser doesn't need to reload/refresh the whole page. This is good for different things, e.g. checking form input.
Websockets are a protocol, technically quite the same as http, unless the connection will not be closed after transmition. This is good for things, where the webserver may need to contact the client (http can't do that), like a push service fore example (chat or mail client where you want to update the user interface even when the user does not refresh the page, or games). And it kills the http overhead as the whole thing has only to be done once in the beginning.
So, their for different purposes, even if they overlap. For your auto-completion I think it won't make a real difference in performance. And it even is a action/reaction thing, so the user types or submits (whatever) what can cause a request and the server responds.
Websockets is a powerful technology and could certainly cater for the limited use cases you;ve mentioned but there can be compatibility problems with older browsers and network intermediaries. In fact some folks even recommend having an HTTP fallback in case Websockets isn't supported.
Unless you have requirements that necessitate websockets, such as full duplex bi-directional communications for example, you might be better off using existing AJAX based solutions.
If you have requirements to push notifications to your user interface, Websockets can be a good idea, but if you are literally looking for form submission and auto-complete, then these problems have already been solved using Ajax.
Short task description: I want one signed in user to be able to send an instant short plain text message to another signed in user. The solution needs to be easily scalable and not too resource demandinng in terms of bandwidth and server load (and $$).
The first idea was do client polling but this idea was quickly abandoned since it didn't meet scalability requirement. So, after that I went into research and came accross a number of concepts including sockets, node.js, xmpp. The amount of information is a bit overwhelming, so I was hoping for some advice to point me in the right directions. Hopefully something with readily available hosting solutions.
#epascarello:
thanks for quick response. I did, but not in detail. Before going in-depth into any technology, I want to be know that this is actually what I need.
Most of the examples concetnrate on instant chat but my requirements are somewhat different. I don't need every signed in user to see a message, but only one particular user, for whom it was meant, while there can be, say, 100 000 users logged in...
#Saeed Neamati:
thanks! Yes, I pretty much understand the two client-server communication options and have come to the conclutions that the pulling is a no-go. What I am trying to find now is the most scalable (that's the main prerequisite) and (hopefully) easy to implement push option. For instance, the socket option is relatively easy but it seems like it's not going to scale well due to server overload (or am I wrong). The node.js (at least by concept description) should be better at that, but I wanted to get some confirmation to this assumption. With xmpp - I'm not even sure how relevant it is to my task and how to approach it.
#andyuk:
Andy thanks, yes socket.io is also something that I came accross while doing research. As far as I understand it requires a server module that needs to run on a host. Do you know if possible to run on any server or do I need to look for a specialized hosting company? THe socket.io site for some reason doesn't work on my PC (neither IE or FF).
Did you look at the source code of nodejs chat.?
Look, you only have two options for client-server communication. Either client starts a request (an HTTP request on the web), which is called pull model (like client pulls the request out of the server), and server responds to that, or server starts a response directly without receiving any request (an HTTP response on the web), which is called push model (like the server pushes the data out to the client).
What you described as polling is actually the pull model, and indeed it takes lots of resources from the server.
But on the other hand, when you want to use push model, your server should know the client. In other words, we know that HTTP (based on TCP/IP) is a stateless protocol, which means that after each request, your connection is closed, and server loses you and forgets about you.
If you want the server to know the client, you should keep the connection open. This is usually done via some HTTP headers like Keep-Alive and Connection.
But to do that you should read Comet Programming. However, this reduces your scalability, because more connections are kept open for a one-to-one map between connection and client (To understand this better, you can think of connections as doors of the server. The more you occupy the door as a client, the less other clients can use it).
Checkout socket.io. If web sockets isn't supported by the browser it will fallback to the next best transport technology.
There is even a chat example included in the source code.
As for your concerns about scalability, node.js is perfect for this due to it's event driven, non-blocking nature. Handling many open connections is one of Node's real strengths.
Plurk uses Node.js for their real time chat features and they support 100k+ users.
I'd like to develop a near real time web based chat system. Any suggestions on how to implement this via jQuery, any gotchas to look out for, and what is this Comet thing I keep reading about?
Ideally, I'd like to support up to about 5,000 concurrent chatters.
Comet, also known as Ajax Push, is often refered as "Reverse AJAX". Instead of pulling the information from the server in regular intervals, the data is pushed from the server to the browser when it is needed. That requires an open connection, for which there are several implementations.
I recommend that you use APE. Here is a demo: http://www.ape-project.org/demos/1/ape-real-time-chat.html
Advantage: It will be very responsive
and real-time.
Disadvantage: You need
to setup the APE server on your
webserver machine.
Comet is a "push" tecnology, created to avoiding the client (javascript code) to continously poll the server. This could cause bandwith problem, because you have to create (maybe) a new TCP connection, then contact the http server, he runs some server-side logic and then sends a response to the client. With comet, if the server decide that you should recive some information (e.g., new chat message) he directly send it to the client.
There are several different implementation, you can have a start here.
the simplest implementation tecnique is the hidden iframe, but I'd raccomend the long polling wich is much more controllable.
One more thing, thake a look at HTML5 websokets, wich could be an interesting solution to your problem (not very compatible with current browser, anyway)
Check out Node.js and nowjs for node.js. Node.js helps you build very efficient servers using server side JavaScript and nowjs is a library that allows you to build real time web apps. There is even a example screen cast that puts together a basic chat application in 12 lines of code.
You could also checkout Socket.io which is another node library thats helps you build real time apps by abstracting away different transport mechanisms and giving you a unified interface to code against (supports WebSockets, Flash Sockets, AJAX long polling, JSONP Polling and Forever IFrames).
I realize you tagged your question PHP but if you are seriously considering writing a scalable system with the least amount of effort (relatively speaking) then learning Node.js is worth your time (and the learning curve is not thats steep since you probably already know JS).