Hello may be you can help me. I'm wondering about the fastest way to send and receive information between a WPF App (client) and a PHP (web hosting server).
Is TCP with sockets the way to go? or it'll have problems with the firewalls and IT related stuff?
Do you recommend me to go for a REST PHP version?
Webservices?
I would like to connect this two technologies in the fastest way without enviroument restriction (like the firewall or IT stuff).
Really, anything that uses HTTP on standard ports would probably work. At least, as well as it would be able to behind a firewall.
So that leaves your options open. Here's a few ideas:
Use JSON and normal HTTP requests.
Use XML and normal HTTP requests. (this may be a bit easier for the .NET side)
Use SOAP.
Use XML-RPC.
Pick one. The first two are easier to implement on the PHP side, and relatively easy to implement on the .NET side. SOAP is fairly easy to connect with .NET; I'm not sure about PHP SOAP libraries. XML-RPC is somewhat hard on the .NET side, and I'm not sure about the PHP side either.
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
}
Whats the best method for posting some data from a server side script, to a PHP web app on another server?
I have control over both ends, but I need to keep it as clean as possible.
I'm hoping people don't mistake this as a request for code, I'm not after anything like that, just a suitable method, even the name of a technology is good enough for me. (FYI the recipient web app will be built in Yii which supports REST if that matters).
Use cURL: http://curl.haxx.se
If you're calling from a PHP script, you can use PHP:cURL https://php.net/curl
Probably best to do it over SSL, if you want to keep the info safe.
Most of the answers here mention cURL, which is fine for smaller use-cases. However if you have more complex and/or growing needs, or plan to open up access to other servers in the future, you might want to consider creating and consuming a web service.
This article makes a somewhat compelling argument for RESTful web services over SOAP-based, but depending on who will be consuming the service, a SOAP-based web service can be both simple to consume (How to easily consume a web service from PHP) and set up (php web service example). Consuming a RESTful web service is easily done via cURL (Call a REST API in PHP).
The choice really comes down to scope and your consuming audience.
You can access your REST API with PHPs cURL Extension.
You will find examples here.
If you use a framework, some have alternatives to cURL, which are easier to handle (like Zend http client).
Or for very simple purposes (and if php-settings allow this), you could use file_get_contents().
Is it possible to send data from C++ to PHP? I have wrote a server in C++ that connects to a database, and I was wondering if it is possible at all to use the socket library built into PHP to connect to the socket server written in C++. Would it just be PHP itself? I mean, would I not use JavaScript (AJAX) to call a PHP script that might do the socket work?
Basically, how do Google do this? I know some of their applications use C++/Java as their back-end, but is there any performance at all?
For those wondering why I am asking this question, then the answer is I don't want to rely on PHP to handle data as I am writing a game. I would like PHP to handle the web part, but not necessarily the game client so-to-speak; and I just think C++ would be a lot efficient at sending and receiving data to store in the database.
Has anyone done something like this and if so did you run into problems; and is this a practical solution at all?
Thanks.
Google use protocol buffers for data exchange between different services. Facebook has Thrift. Etc, etc. There's a plenty of protocols and libraries for you to choose from, but I'm afraid you'll have to do the research yourself.
Last time we had such a task (connecting C++ backends with PHP frontend), we wrote our own, very simple protocol. It's not that hard, in fact, it might be easier than implementing some abstraction on both sides.
I'm working on a project that involves a database (My SQL), website (PHP) and a custom high performance server application (C++). The C++ application (and its accompanying client application) make up the main bulk of the project, with the database storing long term data for it. The website is primarily for displaying various statistics, and administration.
1) I want the PHP scripts and c++ application to be able to communicate in some way, since the database is only used for persistent data, and additionally the c++ application may cache some things so needs to be told to reload the data in some cases. It is highly likely they will be on different machines, and even possibly different OS's. I've been considering the idea that TCP may be the best option with some simple command - response protocol?
2) What is the best way to write the common database interface code once, and be able to use it from both the PHP website and the c++ applications?
1) Use the database to communicate. The C++ application can
select * from table where some_last_modified_timestamp > '<last time checked>';
2) Use stored procedures in preference to hardcoded queries both in PHP and C++.
You might try not allowing PHP to access the database at all. Make the C++ app do all the database work, and make it serve data to the PHP site. You could run part of the C++ app as a server for the PHP to fetch reports etc from it.
#1: If you're on different OSes, then TCP sounds like a decent idea.
#2: Sounds like you need a C library, and then call that from both C++ (trivial) and PHP. A search on Google returns lots of articles about writing PHP extensions in C, for example:
http://devzone.zend.com/article/1021
http://www.devarticles.com/c/a/Cplusplus/Developing-Custom-PHP-Extensions-Part-1/
1) I would also suggest TCP. Depending on the complexity of request-response I'd probably pick either some ad-hoc text protocol or use XML (especially suitable if responses or requests are structured and more complex). If you use XML you won't need to write your own parsers/generators. You could even try using XML-RPC but I have no practical experience with that yet.
Best way to use the same SQL in both PHP and C++ is prepared statements.
A good way to communicate is for one to host a server (custom/soap/rest) which the other connects to. PHP can easily both host and connect, and since that code is written in C it should be easy in C++ too.
Writing a PHP extension like Eric Seppanen suggest is way beyond the scope and need of your project Id say.
Use Thrift or Protobufs (possibly Avro) to declare a communication protocol and use that over a tcp socket. It'll solve your cross language problems without having to roll a custom protocol, and you end up with actual objects on both sides (statically typed for c++!). I've seen Thrift used like this very successfully.
My approach is to use SWIG. I use it with python, but it supports PHP also.
Then it's very easy to use it from your script.
Other solutions could be some RPC (wich would allow to have the server and the PHP application in different places).
I am a beginner here, so please excuse if my idea is terribly bad.
But why cant we just transfer XML over TCP. Have a C++ TCP server and PHP TCP Client. I think PHP has a pretty powerful socket APIs
I'm thinking of building a game along the lines of Farmville - items, events, time management system etc. Options I am thinking of:
1) Flash UI frontend that uses AMFPHP to get all data for the view from a PHP powered backend.
2) Actionscript to power the whole game
Any input is appreciated. My concern with Actionscript is scaling, my concern with PHP is having to build an update system that would need a lot of back and forth xmlhttprequests which might get complicated.
If there's a better way to build something like this, I'm all ears :)
Don't clone/copy Farmville, there are hundreds doing the same thing.
But to your question:
Frontend: Flash
Server: AMFPHP
Backend/CMS: PHP
seems like a good idea.
Actionscript on the frontend side will definitely scale, it has be done a thousand times.
PHP as server and backend part should be no problem, too.
Why you would need xmlhttprequests if you have a NetConnection for Remoting the AMF I don't know.
In this interview "Luke Rajlich" from Farmville mentions using AMF and doesn't mention using XML sockets.
"How do you talk to the backend? Is it Request-response, XHR, long-polling, Flash XML sockets, or "COMET"?
We use a standard HTTP request/response protocol called AMF. The AMF transactions happen asynchronously from the client and if the server sees something it doesn't think the client should be sending, it returns to the client an "Out of Sync" message which tells the client it is in an invalid state and the client reloads itself."
http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html
Since they don't seem to use sockets, I assume they don't use a socket server like smartfoxserver or electro server? Do you think they build their own server, they said they use PHP in the followup interview to the interview linked to above, do you know of any software that will work as a server with all of these AMF connections and PHP--is that what AMFPHP is? (I couldn't find many clear descriptions of AMFPHP online.)
Also, do you know of any good socket servers which work with PHP, it seems like you need to know Java to use smartfox server or electro server, is that correct?
Also, if Farmville uses AMF, would mean they don't use sockets, and would that mean they use polling for changes?
My personal advice:
Backend: Haxe targeting flash9
Frontend: Haxe targeting PHP or neko
Use Haxe remoting for communication, SPOD for database with templo for HTML, or try haXigniter ... I'd personally advise to compile to neko for speed and footprint, but that's up to you ...
write all in one beautiful language ... reduce communication to transparent calls, and database actions to transparent object manipulation.
Me and some friends built argblargs on that exact stack. It's worked great for us, I can't vouch for the scaling into thousands of users, but I don't really think you should worry about that this soon.
Could Farmville be using AMF, perhaps AMFPHP, with a PHP socket server? I'm confused as to whether you would use one or the other, AMF and sockets, are they mutually exclusive? From what I read here, you can use AMF with sockets, is this correct?
"flash.net.Socket is a simpler or, rather, more raw API that allows you to create your own persistent connection but leaves the protocol and communication format up entirely up to you. With the ability of flash.utils.ByteArray to serialize ActionScript objects using AMF you could also use AMF if you wanted to on your Socket so long as the endpoint understands this format."
http://www.mail-archive.com/flexcoders#yahoogroups.com/msg44653.html
However, reading other information such as here they seem to emphasize that AMF and sockets are for different purposes.
Thanks! I'm just trying to figure out all the different possible variations.