RPC w/ PHP - agnostic to transport mechanism

For a recent project, I have a PHP script running as a CLI-based daemon. This daemon will be responsible for monitoring/controlling independent worker processes.

Periodically, users will issue requests to manage workers through a PHP web front-end (CLI daemon and front-end code are on the same physical server). The front-end will need to make method calls to the daemon.

I'm confused about how to handle these "remote" method calls. I thought that using a RPC protocol such as JSON-RPC over a standard UNIX or TCP socket would be the way to go, but every implementation of JSON-RPC, XML-RPC, SOAP, etc. for PHP seems to be tightly cou开发者_如何学Gopled to HTTP. Since I'm not communicating over the web, HTTP is completely unnecessary.

So, two questions:

• Why are most of the PHP RPC packages coupled to HTTP?
• What is the best way to handle method calls as described above?

Why are most of the PHP RPC packages coupled to HTTP?

This is easy. PHP is tailored for the web. It's rarer to write CLI applications in PHP.

Why are most of the PHP RPC packages coupled to HTTP?

It's more common to have PHP perform RPC on programs running in another language, such as Java, and there are good options there.

For a CLI PHP program, I'm not aware of any out-of-the-box solution. But it should be possible to implement a custom solution with UNIX sockets. See the sockets extension. Note that the nonexistence of multi-threading support in PHP may make this a bit more difficult (to handle multiple connections you'll have to fork or implement your own single-thread scheduler...)

You could still use HTTP and connect to localhost, that would not generate any network traffic. I don't think there is any real advantage to be gained by using sockets directly, however if you really want a different transport layer, you could use Ripcord (http://ripcord.googlecode.com/) which allows you to specify your own transport layer class. For full disclosure, I am the author of Ripcord, so I may be biased.