Reputation: 10828
I like to write a PHP script which will run in the background on Linux.
I am trying to figure out what are the solution to send and receive the meta data between PHP Daemon (script) and browsers clients?
I thought I could include http request handling in the daemon itself but a daemon script could receive 500-1000 requests every second. So http request in the daemon itself wouldn't be a good solution.
Is Redis or ZeroMQ are solution to this? Something like this:
(browser clients) <-----> redis <-----> PHP Daemon Script
If PHP Daemon send a message to a client then browser should get meta data immediately via ajax (long polling).
Upvotes: 0
Views: 318
Reputation: 13766
Chris Brand gave you the answer, websockets. I just want to go into a little more detail about your question to help point out some misconceptions that you've got.
The only effective way to make a non-http connection out of the browser is with websockets - it's the only interface that the browser has to communicate to an external server without including the full http overhead.
Your diagram:
(browser clients) <-----> redis <-----> PHP Daemon Script
... seems to treat redis as a communication protocol, which it's not, it's a data store. You wouldn't be passing communication from the browser to a PHP script using redis any more than you would use MySQL for the same task. Regardless, upon first glance it appears as though Redis is not capable of receiving a websocket connection directly, so you can't connect the browser directly to it in any event, so the picture would look more like:
(browser clients) <-----> PHP Daemon Script <-----> redis (or any other data store)
You can use ZMQ to manage your communication if you wish, and there may be compelling reasons to do so but that's application specific. Regardless, ZMQ would live on top of websockets, and add its own brand of overhead to do so. That said, it's designed for just this sort of high volume messaging.
My suggestion is to look into using websockets directly to communicate to your backend. Chris Brand made another good suggestion to look into using node.js, but the learning curve (while relatively small if you're familiar with JS) may not be worth it for this iteration of your project. If you run into issues of messaging/connection reliability, then you might look into what ZMQ can offer you.
Upvotes: 1
Reputation: 1990
If you want the browser to get feedback in realtime via long polling...I don't think Redis is an option. As far as I know, Redis doesn't allow for long poll queries...if the value doesn't exist at the time of query...it will return null.
My suggestion would be to use something like websockets. PHP has a few libraries that work with websockets, one I am familiar with is http://socketo.me/. However, this will mean that the client will interact directly with your PHP script. You can scale this by adding a load balancer infront of it and having multiple daemons on different ports/boxes etc.
If you don't have to use PHP, I would rather suggest something like NodeJS. It's made to do things like this and it does by default what things like Ratchet PHP tries to mimick.
Upvotes: 2