C++ 中的 Linux 守护进程处理 PHP 请求
操作系统：Linux（红帽） 编程语言：C++
我需要使用 C++ 创建一个 Linux 守护进程（进程），它将持续侦听自定义端口上的 PHP 请求。 PHP 会将 XML 形式的请求数据发送给守护进程，守护进程将使用 Xerces 解析 XML，并将 XML 形式的适当回复发送回 PHP 页面。
我已经成功创建了一个守护进程，监听本地主机的 4646 端口，但我不知道来自 PHP 的请求将如何发送到守护进程，以及守护进程将如何发回回复。
我尝试用谷歌搜索这个特定问题，但根本找不到解决方案。 对于这个问题的任何帮助都将非常感激。
我还阅读了一些有关 PHP 守护进程的内容，但我不确定它们是否适用于这个特定场景。
这种方法并不困难且快速，因此任何替代方法也可以。唯一困难和快速的是结果，即 PHP 页面和守护进程之间的成功通信。
OS: Linux(RedHat)
Programming Language: C++
I need to create a daemon(process) for Linux using C++ that will continuously listen on a custom port for PHP requests. The PHP will send the request data in XML form to the daemon, the daemon will parse the XML using Xerces and send back an appropriate reply in XML form to the PHP page.
I have successfully created a daemon process listening on port 4646 on localhost, but what I can't figure out is how the request from PHP will go to the daemon and how will the daemon send the reply back.
I tried google-ing for this particular problem but couldn't find a solution at all.
Any kind of help on this problem will be very much appreciated.
I have also read a little about PHP daemons, but I'm not sure whether they are applicable in this particular scenario.
This approach is not hard and fast so any alternative approach will also do. The only thing hard and fast is the results i.e succesful communication between the PHP pages and the daemon.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
问题比较混乱。
为什么必须用 C 或 C++ 编写？
这是否意味着它不需要用 C/++ 编写？为什么您认为它们可能不适用？
为什么它必须使用 Xerces？据推测，守护进程应该做的不仅仅是解析 XML 和撰写响应 - 它还能做什么？
编写守护进程并不是一个简单的过程。编写套接字服务器并不是一个简单的过程。通过在每一端实现明确定义的协议，它在某种程度上得到了简化。
...这就引出了一个问题，为什么不直接使用 HTTP 作为协议和网络服务器来实现服务器内容，并将特定于应用程序的逻辑分离到 [f]CGI 程序中。更进一步，为什么不使用 PHP 实现特定于应用程序的逻辑。
一些选项：
将应用程序特定部分编写为 PHP 页面，然后使用 curl 通过 HTTP 请求调用它
编写一个分叉 PHP 中的服务器守护进程，将两端的连接作为网络套接字处理（需要您定义协议）< /p>
当然，在我上面提到的 PHP 的任何地方，您都可以同样使用 C、C++、Perl、Java...等。
Question is rather confused.
Why does it have to be written in C or C++?
Does that mean it doesn't need to be written in C/++? Why do you think they might not be applicable?
Why does it have to use Xerces? Presumably the daemon is supposed to do something more than just parse XML and compose a response - what else does it do?
Writing a daemon is not a trivial process. Writing a socket server is not a trivial process. It is somewhat simplified by implementing a well defined protocol at each end.
...which rather begs the question, why not just use HTTP as the protocol and a webserver to implement the server stuff, and seperate the application-specific logic into a [f]CGI program. And taking this one step further, why not implement the application-specific logic using PHP.
Some options:
Write the application specific part as a PHP page then invoke it via an HTTP request using curl
Write the server as a single tasking stdio server and use [x]inetd to invoke it, handling the client side connection as a network socket (requires that you define your protocol)
Write a forking server daemon in PHP handling the connection at both ends as a network socket (requires that you define your protocol)
write a single threaded server daemon (using socket_select) in PHP handling the connection at both ends as a network socket (requires that you define your protocol)
Of course anywhere I've mentioned PHP above, you could equally use C, C++, Perl, Java....etc.
最好您可以使用 php 套接字库来连接系统中运行的守护进程，然后您可以将数据传递给守护进程并可以处理守护进程发回的结果。
您可以参考 PHP Socket Library 创建与 daemon 进行套接字连接的代码。 ..
我认为这是比使用 CURL 更好的选择，因为守护进程也是一个自定义套接字接口，CURL 最适合 HTTP 请求，但我认为这里的守护进程不是 HTTP 守护进程。
Its better that u can use the php socket library to connect with the daemon running in your system and then u can pass data to the daemon and can process the result sent back by the daemon .
You can refer the PHP Socket Library for creating code to do socket connection with daemon ...
I think this is a better option than using CURL as the daemon is also a custom socket interface , CURL will be most suitable for HTTP request's , but i think here the daemon is not an HTTP one..
xinetd / inetd 可能有点老了，但可以使这变得简单且可扩展（有限制）
Inetd 将调用您的程序并将流量发送到标准输入，您的标准输出将进入连接。只要您不需要共享信息，您就不必担心程序无错误/无内存泄漏等问题......
Simon Loader
xinetd / inetd might be a bit old skool but can make this easy and scalable (with in limits)
Inetd will call you program and send the the traffic to stdin and your stdout will go to the connection. As long as you dont need shared information it stops you having to worry about making the program bug free/no memory leaks etc....
Simon Loader