I am writing Web chat where you have several one-on-one conversations with people on the screen at the same time. (Basically, like a personal messenger, without group chats).
My technology options seem to be Long Polling and WebSockets, and I'm trying to choose.
The upside with Long Polling is that's it's very easy to implement, and I can return whatever data i want (a customized JSON-object with the data required to update the page).
What I'm afraid of with WebSockets is that there's no native library for it in PHP, so you have to shop between different 3rd party ones, and the concepts seem more complicated, what with channels and subscriptions and what have you.
Browser compatibility is not an issue for me.
Is the performance of Long Polling much poorer than with Websockets? If no, then my decision is easy!
Is there a really simple Websocket server for PHP? Or is the concept so simple I could write my own? (Mozilla has a really simple tutorial on writing a client, but not on a server).
Assuming that your long-polling scheme involves an endpoint hosted by the same web server as your frontend, this will mean two active connections for every user of the application, so you will basically cut the number of users you can support in half. Your websocket server would run on a different port and can bypass your web server, so the connections are a lot of saved overhead with websockets.
Another place websockets save on overhead is that once your connection is established, there is no need for constant requests and responses. Zombie websocket connections are essentially free in terms of both bandwidth and CPU.
Finally, I would not think that long polling would be simpler to implement. Since websockets are designed to do exactly what you want, I think that leveraging an existing websocket package will actually save you some lines of code. I would look at Ratchet (feature-rich) or phpwebsocket (lite), if you want to use PHP.
Long Polling is definitely way much poorer than Werbsockets.
It is not recommended to use whatever websockets library with PHP, specially for chat applications.
I suggest using Python, Ruby or Node.js instead.
Related
I have a web application driven primarily by javascript/ajax, somewhat similar to how google docs work; all people viewing a page will be seeing the same information in relative real-time. It's not crucial that the information is actually real-time, a second or so is fine.
Currently, the application is ajaxing the server every 5 seconds. I was researching server-sent events and they sound like exactly what I need... but this is my understanding: server-sent events essentially just move the polling to the server. The PHP script doing the server-sent events will check the database for changes every X seconds, and send an update to the application when it finds one.
Checking once per second would probably be adequate, but since I'm on shared hosting I want to avoid any unnecessary load possible. Is there way I can subscribe to updates to the database? Or is there a way I can notify the script from other PHP scripts that make changes to the database?
With PHP, polling the DB is the typical way to do this. You could also use TCP/IP sockets to connect to some kind of application server, that sits in front of your database, and knows about all writers and all consumers. I.e. when a write comes in, it both broadcasts it to all consumers and writes it to the DB. The consumers in that examples are the PHP scripts (one per SSE client).
If you use WebSockets, then you need exactly the same architecture, because PHP is single-threaded: each SSE connection is an independent PHP process.
If you switch to using, say, node.js, then that application server can be built-in. (Again, it would work the same way, whether SSE or WebSockets.)
But, you mention you intend to use shared hosting. SSE (and WebSockets, and comet technologies) hold a socket open, which interferes with the economics of shared hosting. So your sockets are likely to get closed regularly. My advice would be to stick with ajax (and therefore DB) polling every 5 seconds, instead of SSE, until your application is worth enough that the $10-$100/month for a real host is not an issue. Then consider using SSE to optimize the latency.
P.S. The decision between SSE and WebSockets is all about write frequency. My guideline is if your clients write data, on average, once a second or more frequently, web sockets are better, because it is keeping the write channel open. If once every 5+ seconds then web sockets does not bring much, compared to just using an Ajax post each time you have data to write. An SSE back-end is simpler to deal with than a WebSockets back-end. (Writes every 1-5 seconds is the grey area.)
What I would recommend is instead of polling the database for changes, you will know when there is going to be a database change because your application will be making that change. I would use web sockets (https://developer.mozilla.org/en-US/docs/WebSockets) and simply push an update to all active clients when any member makes a change.
Here is the difference between Server Send Events and Web Sockets. (In your case Web Sockets are the way to go)
Websockets and SSE (Server Sent Events) are both capable of pushing data to browsers, however they are not competing technologies.
Websockets connections can both send data to the browser and receive data from the browser. A good example of an application that could use websockets is a chat application.
SSE connections can only push data to the browser. Online stock quotes, or twitters updating timeline or feed are good examples of an application that could benefit from SSE.
In practice since everything that can be done with SSE can also be done with Websockets, Websockets is getting a lot more attention and love, and many more browsers support Websockets than SSE.
However, it can be overkill for some types of application, and the backend could be easier to implement with a protocol such as SSE.
I have a fairly big web application build with SproutCore and PHP as backend. What I want now is to use websockets to update my client application in real time.
From what I know, PHP is really bad to handle persistent connections. So I've been thinking that I could use Go to handle the websockets connections and call my PHP scripts each time a request is received (this package seem to make it possible).
So my first question is, do you guys think it's a good idea (and a viable idea, I haven't been able to find people doing so) or should I stick with PHP ?
If I use Go to handle the websockets connections I've also been thinking that I could progressively move away from PHP to only use Go (since it is a lot faster than PHP). If I do that, I will have to be able to call some Go package from PHP. Can this be done with the PHP exec function ? Is there a better way ? And again, is that a good idea ?
Go is a natural fit for websocket servers. I've built websocket servers in Go and have been extremely happy with how it all worked out. I have one service handling 300k users a month on a Go websocket server and it barely uses 1% CPU of an Amazon AWS micro instance. Couldn't be happier.
Websockets really need event driven frameworks like Go and Node.js in order to maximize server resources. Forked web processes like PHP consume far more resources than an event driven framework.
If you need to call Go from PHP at some point, I suggest using API calls. Although exec would work too.
It is an old question, but my two cents on this subject...
There is a very good php library that does exactly what you are asking for - websockets. It is called Ratchet. I would not use node.js (over hyped) or go when php can do exactly the same thing and it is the language that I am most comfortable with. In majority of cases, little gain in performance over websockets is not worth switching stack.
Other useful links if you plan on using Ratchet:
Backend - Ratchet Examples
Frontend - Autobahn WS
Only yesterday, I was asking a friend of mine how he would go about emulating direct communication channels between two clients through a web server, for the purpose of creating a chat application, but by using solely PHP/MySQL/JavaScript.
He told me that the best way to do this was by the use of SOCKETS, a term I had only heard of until then. This morning I started looking into it for the purpose of creating my chat application, but I'm quickly starting to believe that it's not as easy as I'd hoped.
So my question is this: if I don't have access to my own server (I have a domain hosted on a shared server that I also use for testing purposes), can I still use sockets to achieve my goal? If so, how exactly? (Please understand that I am completely new to the idea)
If not, what other way is there to accomplish the communication channels?
My only idea so far is to simply send periodic requests (AJAX) to the web server the application would be stored on and request any new messages, if any. But this does not seem very feasible.
Thanks in advance for your help!
I think what your friend is trying to get to is implementing Comet for your chat site.
Assuming he's getting you to use PHP sockets to act as a daemon, I highly doubt a shared hosting provider will let you do it.
You could try hanging the PHP script until there's data available. However, this will quickly consume resources on a CGI-based server since the PHP server can't tell if the client is still connected. I know this from experience.
For these kind of things, I highly recommend you get a dedicated server or VPS and write your backend in something like socket.io which automagically handles all your communication problems on both the client and server side. PHP, MYSQL and servers that fork to serve requests are usually the worst case scenarios for implementing Comet since they incur quite a bit of overhead and aren't scalable.
If you can't afford to run your own Comet server, then polling may be your only option. This will be the most resource intensive and least responsive.
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).
Is there a real solution for COMET AND PHP combination? Basically, I've come to a point that I need to update a user home page periodically whenever there is new data in the database. As far as I understand, I need to open a persistent connection between my server and my clients browsers to update the contents of their home page as soon as new info. available without dedicating a lot of resources but I had no luck finding anything clear about this issue. I read many articles suggests that PHP is not a good language to implement COMET. My web application is completely programmed in PHP and I don't want to learn another language but if I'm forced to, Would you suggest a good language to start with? Do you think that I can program an interface just to handle this issue?
Thanks in advance.
The times I've heard people say that PHP was not well suited for COMET (like you said yourself) was because of the way webservers and PHP work -- mostly, because there is one process per page, which means if you want 200 users connected to your server, you'll need 200 processes (which can quickly become a problem for a couple of hundred more users).
Maybe a solution to that problem would be to use nginx_http_push_module ?
I've not tried it (yet ?), but it might be just what we need...
I was working on a school project and ran into the exact same problem. Because each PHP process has so much memory overhead, it's impossible to support to many connections per box. It was at this point I decided to switch to using BOSH and XMPP. This is a rather new "wave" of technology but there is already quite a few libraries to help you on your way. I would suggest using Strophe and XMPPHP. Then your clients can connect to a BOSH server (I'm using Openfire) and that can scale to thousands of active connections per server.
You don't have to learn a new language to implement such a feature.
For example, you could use Quercus (Java implementation of PHP) and implement a server Comet application using the JVMs memory management model.
There are solutions you need:
almost COMET solution (uses php and one file written with perl):
http://translate.google.com/translate?js=y&prev=_t&hl=ru&ie=UTF-8&layout=1&eotf=1&u=http://dklab.ru/lib/dklab_multiplexor/&sl=ru&tl=en
exact COMET solution in php (this is what you want, I think):
http://translate.google.com/translate?hl=ru&sl=ru&tl=en&u=http://dklab.ru/lib/dklab_realplexor/
You would first need to understand what is a comet application like. The concept involved in building a comet application are explained at wiki at Comet (programming)
What you need to understand is that you can use any programming language to build a comet application as long as it follows the concepts explained at wiki
1.Ajax with long polling
2.Streaming
You can check some sample code at Simple “Long Polling” example code
Now coming to the problems -
1.You use ajax long polling then the browser(ajax request) would keep polling the server for data. This may eat up memory on the server or slow down the browser after some time.
Few Suggestions
JQuery PeriodicalUpdater (AJAX long polling/server polling)
Handling Long Polling
RobertFischer / JQuery-PeriodicalUpdater
What you need to check to implement this -
a) How often do you expect data to be updated on the server.
b) How much time the server side script would run to check, fetch and process data before sending it to the client side.
2.You can implement streaming by using the following -
How to implement COMET with PHP
Lightstreamer Dojo
Dojo Charting + Lightstreamer Comet Demo
Demo
Ajax Push Engine or The APE Project
What you need to check for this -
a) Will your hosting provider allow you to install these on hosting servers
b) Your RAM and Bandwidth utilization (You will need a dedicated server with package that gives you lots of RAM and Bandwidth)
It depends on what and how your requirements are. You will have to analyze and approach.
If what you are implementing is a small application you can go for Ajax Long polling given the fact that you analyzed and handled the negatives of this approach.
If you have a large application you can go for steaming.
Ajax with long polling is a easy solution, there are plugins in jquery and any other major js framework to help you do this.
Node.js seems like a pretty sweet solution for stuff like this. (Still a little gamey for production but cool all the same). PHP is a horrible environment for stuff like this, you have to change the way the server interacts with requests because you are no longer immediately responding. Python has a handful of servers like Twisted that are great for this because they let you be the server. No matter what language you write it in you've got to alter the typical request/response model. (Glassfish's Grizzly Comet server does this for Java as an example)
You should try Dmitry Koterov's Realplexor, which is a comet server, that provides Javascript and PHP APIs.
Readme.txt in english is provided in the package.