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.
Question is rather confused.
I need to create a daemon(process) for Linux using C/C++
Why does it have to be written in C or C++?
I have also read a little about PHP daemons, but I'm not sure whether they are applicable
Does that mean it doesn't need to be written in C/++? Why do you think they might not be applicable?
the daemon will parse the XML using Xerces
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.
The only thing hard and fast is the results i.e succesful communication between the PHP pages and the daemon
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.
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 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
Related
I have a question regarding the titled question. So, I'm attempting to create a program which passes data/requests for data between a program in C++ and a PHP site running off of an Apache web server.
I've been researching Socket communications, but I'm not understanding the concept. I understand how to create a socket in PHP, and another in c++, and I have them running using a test application. But only individually, not talking to each other OR talking to my web server (the PHP is not on the server at the moment, it is on a different server). So how does this work? From my understanding, you need one to be listening to a port number, and the other one to send something to that command.
Ideally, I would prefer not to use any libraries to help me achieve this. I know this question has been asked many times before, but I'm still getting nowhere.
Could someone provide an explanation of how the above works, or links to a question on here/elsewhere that may be of help? Or if there is a better method of doing this than using sockets? They will be talking to each other a lot, and speed maybe an issue.
Edit, further explanation:
Web server: I'm running an Apache web server. The PHP script is located on this server.
C++ Location: While testing, my c++ application is stored on the same Raspberry Pi that the web server is running on. In the real application, my C++ application will still be stored on the same device (but it won't be a Raspberry Pi - still Linux based though).
Communication: The PHP script will need to be triggered to do things by the C++ script, and vice versa. They will need to both need to pass data (common data structures, but they could be fairly large) each way (so both need to be able to send and receive data).
I think the easiest way is:
1) PHP -> C++ : tcp
2) C++ -> PHP : http
Will try to explain.
1) To take something from C++ app PHP connects to that app using stream_socket_client function. C++ app is listening on host and port using socket, bind and listen functions. As soon as connection arrives C++ app accept it and then in a separate std::thread serves it (recv to get request, send to send response). How to socket.
2) As PHP is working under Apache Web Server, I think the easiest way is use of libcurl library to make HTTP request from C++ app. How to curl.
Another approach could be SOAP or REST Web Services. On both sides, you could provide a SOAP Web Service to exchange data or to call remote functions. On C++-side, you could use Apache Axis to provide a SOAP Server. On PHP side, you can use the build-in SOAPServer class (http://php.net/manual/de/class.soapserver.php).
With SOAP you simply would exchange XML-based messages between both applications over HTTP / HTTPS. With this approch, both applications can trigger each other and exchange data.
Adding to the answer of Ben Schnarr, I think probably the most elegant and easy solution would be to make the C++ program a client for web services implemented in the PHP code. Using sockets directly would force you to have an additional protocol over it to represent the data being transmitted (unless the data is trivially simple, like a stream of ASCII text), which would be a bit like reinventing the wheel.
I'm partial to REST+JSON, because they are simple to implement and use, and very powerful. In contrast, SOAP is quite complex, heavy in resources, and brittle, especially if you use it with C++. One popular implementation I've already used, for instance, would force you to recompile your code every time you change the layout of any of the messages, even if the server is adding a field that the client won't use.
On the PHP side, it's quite easy - it already has all the infrastructure you need. On the C++ program, the minimum you'll need would be an HTTP client library and a JSON codec. I use libcurl for the first (by far the most popular) and jsoncpp for the latter, but there are other options for both. More recently, some libraries appeared with the whole package, but I hadn't had the chance to use them yet. Some examples:
restclient
REST SDK
Restbed
I recommend you to use Unix Sockets
For c++ check this: http://www.linuxhowtos.org/C_C++/socket.htm
For php check this: stream_socket_client
You can pass info internally from both processes.
Hope you can solve it, don't give up.
A SOAP solution could be something that solve the problem, but in my opinion it complicates a lot the application deployment.
You could go down a few levels and work directly with XML-RPC.
Here you have two interesting links, that shows how to implement the client and the server in both languages.
XML-RPC for C++
XML-RPC for PHP
There are other implementatios of XML-RPC for C++ (I have not used this approach with PHP, so I don't know others alternatives), don't stick with only one, try with others and use what you feel more comfortable with.
If you need some guidance on what stas told you then I suggest you look at
http://us2.php.net/manual-lookup.php?pattern=fsock&src={referrer:source?}
http://us2.php.net/manual-lookup.php?pattern=socket&src={referrer:source?}
In C++ you'll want to create a TCP listener that accepts commands (clearly you'll want to put some method of validation in),
then use PHP to open a connection (use fsock or socket your choice - fsock is easier), and write data to your C++ listener. It's ezpz
//updating with some example code
// protocol://ip, port, $errno, $errstr, $timeout
$fp = fsockopen("tcp://ip", 1337, $errno, $errstr, 30);
if(!$fp) die('failed connection or something');
//write something
fwrite($fp, "stuffs to write");
// get a reply?
while (!feof($fp)) {
echo fgets($fp, 128); // where 128 is size
}
I will try to make my first post here as interesting as possible.
Lately I have been interested in the feasibility of handling WebSocket requests on a shared hosting server.
Please don't tell me "upgrade your plan". All this would be trivial on at least a VPS. I realize that.
As many know, shared hosts will...
Kill a daemon if they see one
Block usage of server sockets
Deny you shell access
Keep apache off limits (no module installations)
These restrictions eliminate phpwebsocket, python altogether. A no-daemon solution that masquerades as a web page is needed.
PHP being my favorite server-side language, I crafted a PHP websocket gateway posing as a web page.
So far I have been successful in sending the right headers for the handshake and streaming output (using output buffering), but I still can't figure out how to continue to read data after the initial request.
In short, I want to continue to receive data from the client even after the PHP script is started. I have tried reading the php://input pseudofile, but I can't seem to get any more reads out of it after the end of the GET. Is there any setting or hack that will allow this?
Thanks!
the short version: What you're trying to do is simply not possible.
the long version: the best you can get is a oneway communication channel that looks like a websocket connection in your browser, but that only works on one direction. From the server to the browser. The other direction will simply not work, because the webserver isn't aware that you're trying to use a different protocol than HTTP, and there is no way of telling it. At least not in the scenario you just outlined.
Your problem here is Apache itself. Once Apache has read the first HTTP request (the websocket handshake) it will continue reading from the TCP connection for any additional HTTP requests. Thus any new data send on the TCP connection will never be passed on to your script. This is necessary as the HTTP/1.1 protocol supports Keep-Alive by default meaning multiple Request/Response cycles are done on one TCP connection. The browser doesn't open a HTTP connection for each request (which was the default in HTTP/1.0). You can't change this behavior. To implement a websocket server you will need to setup your own socket.
After the WebSocket handshake is done, it works pretty much like regular sockets. There is no reason why Apache would allow unidirectional communication without headers.
I have been searching Google for a while, but the problem I am running into is I am not exactly sure what it is I need to be searching for. (Searching for PHP C++ communication doesn't seem to be what I need) I am basically developing a c++ plugin for a game server, and I would like to create a web interface that can pass/pull data to and from the C++ plugin. The game already uses an RCON port for remote administrative access, but I stumbled across a header for the Network interface they use, so I assume I could use this.
My problem is I am not very familiar with using sockets. I assume I will basically need to open a socket in C++ and leave it listening, and then in the PHP, connect to that socket, pass the data, and close it.
Here is the interface...
http://www.ampaste.net/m2f6b6dbc
I am mostly just going to be pulling information like current list of connected players, names, and scores. And passing commands to restart the server, shut it down, etc.
Any help would be great, thanks!
You could try Thrift. It was written by the engineers at Facebook, and it's now an Apache project.
Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml.
Link: http://incubator.apache.org/thrift/
In a nutshell it does exactly what you're trying to do. It makes it easy for different languages to communicate with each other. Rather than trying to come up with some socket based protocol for communication, you can call a function in PHP like this:
$game->getScores();
And it automatically plugs into a function named getScores in your C/C++ program. The only drawback is it can be a bit of a pain to configure correctly.
I'd dare to recommend to use some standard means of distributed components communication, for example, XML RPC. There are libraries for both PHP and C++: http://en.wikipedia.org/wiki/XML-RPC#Implementations
This approach will keep you from reinventing the wheel during communication protocol implementation, and will make further maintenance cheaper.
I assume I will basically need to open a socket in C++ and leave it listening
err, yes, that's the description I'd give to my 12 year-old daughter - but if you're going to have more than one client connecting its a bit more involved. Especially if you are bolting the code onto an existing server. So have a read of the socket programming FAQ.
You do need to define a protocol of how data will be represented when travelling across the socket. THere are lots of 'standard methods - but sometimes things like CORBA / SOAP etc can just be overkill and more effort than starting from scratch.
If you are bolting code ontp an existing server, life will be a lot simpler if you use the current socket and extend the protocol if necessary.
There are 3 models for writing a socket server - the code snippet you provided does not seem to include details of which you are currently working with:
forking server (may split threads rather than processes)
single-threaded server
socketless server
forking server
An instance of the server is started (call it p1), calling setsid()
p1 starts listening on the relevant socket
a client tries to connect
p1 forks to create p2
p2 then accepts the connection and starts conversing with the client
p1 continues to listen for further connections
p2 exits when the connection closes
There are variations of this - p2 may accept further connections, p1 might fork prior to a connection coming in)
single-threaded
An instance of the server is started, calling setsid()
it starts listening for a connection, and creates an array of the sockets in use (including the initial one)
socket_select() is used to identify activity from any of the sockets
when a client connects, the connection is accepted and added to an array of connections
whenever socket_select() returns activity on one of the sockets, the server generaets an appropriate response / closes the socket / binds the new connection
socketless server
some process (e.g. inetd) handles all the socket stuff
when a client connects, this other server starts an instance of your program and binds the socket I/O to the STDIN/STDOUT of your program
when your program exits, the other process closes the socket (if its still open) and handles the clean up (e.g. if it is implemented as a forking server, then the spawned process may end)
What it appears you want to google is C++ client / server. There are two approaches I could suggest here.
First, would be to make a very basic HTTP protocol server so that your php script can simply go to http://yourip/ and send your commands through the POST variables. You can find an example of a C++ Web Server at: https://stackoverflow.com/questions/175507/c-c-web-server-library
The second approach which allows a lot more flexibility is make up your own basic protocol and use PHP's SOCKETS to connect to the server and send commands. You can find an example of a C++ client / server application at http://www.codeproject.com/KB/IP/client_server_socket.aspx. Keep in mind, for the C++ end, you are only concerned about the Server part. You can find a basic PING client in PHP, using sockets, at the following URL: http://www.planet-source-code.com/vb/scripts/ShowCode.asp?lngWId=8&txtCodeId=1786. There are also classes out there to handle most of the protocol part, though I am not aware of any that work for both languages.
Please note I have not tested any of the codes I linked to. I simply found them on google.
A good place to start would be http://php.net/manual/en/book.sockets.php.
Basically, you're going to create another remote administration port and method for PHP to connect. Naturally, if your going to only be accepting web communication from one IP, that's a good way to secure it (check and allow access to only the one IP which will connect). However, you will need the C++ server to listen on a (secure?) port and have PHP connect to it (as long as host allows it).
So overall, if you already have a server running, this should be simple from the C++ side. All you need to do from the PHP side is really research connecting to different servers and passing information along (which PHP is more than capable of doing efficiently)
But, this is obviously an alternative to the poster up 2. I personally enjoy (in many cases) "reinventing the wheel" so to speak as to be able to manage my own work. But of course, that is not always efficient by cost or otherwise.
Good luck!
Python, Perl and PHP, all support TCP stream sockets. But exactly how do I use sockets in a script file that is run by a webserver (eg Apache), assuming I only have FTP access and not root access to the machine?
When a client connects to a specific port, how does the script file get invoked?
Does the script stay "running" for the duration of the connection? (could be hours)
So will multiple "instances" of the script be running simultaneously?
Then how can method calls be made from one instance of the script to another?
Scripting languages utilize sockets exactly the same way as compiled languages.
1) The script typically opens and uses the socket. It's not "run" or "invoked" by the socket, but directly controls it via libraries (typically calling into the native C API for the OS).
2) Yes.
3) Not necessarily. Most modern scripting langauges can handle multiple sockets in one "script" application.
4) N/A, see 3)
Edit in response to change in question and comments:
This is now obvious that you are trying to run this in the context of a hosted server. Typically, if you're using scripting within Apache or a similar server, things work a bit differently. A socket is opened up and maintained by Apache, and it executes your script, passing the relevant data (POST/GET results, etc.) to your script to process. Sockets usually don't come into play when you're dealing with scripting for CGI, etc.
However, this typically happens using the same concepts as mod_cgi. This pretty much means that the script running is nothing but an executable as far as the server is concerned, and the executable's output is what gets returned to the client. In this case, (provided you have permissions and the correct libraries on the server), your python script can actually launch a separate script that does its own socket work completely outside of Apache's context.
It's (usually) not a good idea to run a full socket implementation directly inside of the CGI script, however. CGI will expect the executable to run to completion before it returns results to the client. Apache will sit there and "hang" a bit waiting for this to complete. If you're launching a full server (especially if it's a long running process, which they tend to be), Apache will think the script is locked, and probably abort, potentially killing the process (configuration specific, but most hosting companies do this to prevent scripts from taking over CPU on a shared system).
However, if you execute a new script from within your script, and then return (shutting down the CGI executable), the other script can be left running, working as a server. This would be something like (python example, using the subprocess library):
newProccess = Popen("python MyScript", shell=True)
Note that all of the above really depends a bit on server configuration, though. Many hosting companies don't include some of the socket or shell libraries in their scripting implementations specifically to prevent this, so you often have to revert to making the executable in C. In addition, this is often against terms of service for most hosting companies - you'd have to check yours.
As a prior answer notes, scripting languages have operate in this regard in exactly the same way as compiled programs. Where they differ (potentially) is in the API that they use. The operating system (Windows or Unix-based) offers an API (e.g., BSD sockets) that compiled programs will call directly (typically). Interpreted languages like PHP or Python may offer a different API such as Python's socket API which may simplify some parts of the underlying API.
Given any of these APIs, there are many ways in which the actual handling of an incoming TCP connection can be structured. A great and detailed overview of such approaches is available on the c10k webpage: http://www.kegel.com/c10k.html -- in particular, the section on IO strategies. In short, the choice of answers to your question is up to the programmer and may affect how the resulting program performs under load.
To focus on your specific questions:
Many server programs are started before the connection and are running to listen for incoming connections. A special case is inetd which is a superserver: it listens for connections and then hands off those connections to programs that it starts (specified in a config file).
Typically, yes, the script remains running for the duration of the connection. However, depending on the larger system architecture, the script could conceivably pass the connection off to another program for handling and then exit.
This is a choice, again as enumerated on the c10k page.
This is another choice; operating systems offer a variety of Interprocess Communication (IPC) mechanisms to programs.
The only way I can make sense of what you're asking is if you use inetd or a similar meta-server, which is configured to invoke your "service a single client" program for a specific listening port, forwarding your "single client servicer" program's stdin/stdout to the remote client.
If that's the case:
1) inetd runs it
2) yes
3) yes
4) named pipes are one possibility
When a client connects to a specific
port, how does the script file get
invoked?
The script should be already invoked in order to receive any connects from any client. You will need script to be hanging on there forever (infinie loop) and setup Apache not to kill it on timeout. Basically, PHP is not a good choice for writting server applications. Why do you need this?
I have to build up a system which listens for requests from a GPS device which is only capable of sending UDP requests. Then I am going to analyze requests hopefully by PHP if it is possible.
I do not know where to start. What do I need? Can I make use of PHP? Would it be reliable to use PHP? Can I just adjust Apache for listening UDP requests?
I do not know where to start.
You need a notion of an overall program design, and, as #karim79 pointed out, an understanding of socket programming APIs for your chosen language.
Can I just adjust Apache for listening UDP requests?
Do you mean the Apache httpd? The short answer is "no."
Use something like PEAR's System_Daemon instead.
The long answer is "yes, that is possible." Particularly with modular plugins exposing the httpd's internals, you can do Just About Anything You Want (tm) (see, for instance, mod_perl). You could beat httpd into a sort of application server for a long-running (set of?) PHP process(es) which are not themselves intrinsically HTTP-driven.
The better answer of the two is, again, "no." :)
By all accounts I think PHP should be fine for that, but I haven't done anything like that myself. You will need to look into socket programming, here's a tutorial:
http://www.devshed.com/c/a/PHP/Socket-Programming-With-PHP/
You could just have your PHP script invoked by inetd.
Well, PHP supports a set of Socket Functions that allow you to deal with UDP, I've used them myself to build a NSLookup class which I could specify the name server (all in UDP) and a Ping class (RAW/ICMP). It works just like the standard C/C++ socket library. But I don't really think using Apache+PHP is a good choice to build those things. If you want to stick with PHP, its better to script it as a console application.