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.
Related
I've been "recruited" so to speak to help work on a web project that is currently written in PHP with an Apache server. We would like to integrate a real-time (or at least something very close to it) chat feature. Scalability is a definite concern, and this type of work is definitely not my typical.
Everything I've read about creating such a chat feature requires the use of "long-polling" so the servers don't get rapidly overloaded and, well, crash. PHP and Apache are not conducive to implementing such a feature, so I've explored some alternatives, like Twisted Python for example.
The website has roughly ~7,000 lines of PHP (i.e., it'd pretty difficult to just straight switch languages for the entire thing), so my question is how can I manage this situation as far as trying to integrate python and setting up a separate server? Or, is this a very bad way to do this? Are there other alternatives that would be better suited? (Sadly many of the PHP Comet, or even AJAX, solutions I've found don't scale in the slightest. Note, the Apache server is not necessarily required; however, any server used must work with PHP and Python etc, short of having separate servers.)
Thanks for the help!
I would use Tornado on the server to write the chat application. Client server communication can then be over websockets. If you use SockJS on the client side you can also support older browsers via long polling. There are plenty of example chat clients written using Tornado. It's very simple to get started and it is wonderfully scalable. A chat server like this can be serving thousands of clients without showing any appreciable CPU activity.
This is an example, possibly a bit over engineered https://github.com/diggidanne/websocket-chat/blob/master/server.py
A page is sending AJAX call to server and should get item info in response. The array to look-up/return is a rather big one and I can’t hold it in the PHP file to accept the request. So, as far as my knowledge and experience tell, there are 2 methods:
Access database for each request.
Store items in files (e.g. “item12.txt”) and send contents to the user.
My C experience says that opening and closing a file takes much more system time than the rest of the program. How is it in PHP? What is the preferred method (most importantly, resource-wise) – file system or database? Is there any other way you would recommend (e.g. JavaScript directly loading the file with variable array from the server for each request)? Maybe there’s some innovative method lying around you’re aware of?
P.S. On the server-side a number only will be accepted, so no worries regarding someone trying to access files in the server or trying to do some fancy stuff on database.
Sockets
Depending on how many requests you will be handling, you could look into socket connections.
Sockets gives you 2 way communication between the client and the server, which would allow you to do interactive things, as needed.
Socket tutorial 1
Socket tutorial 2
Node.js
node.js is the new kid on the block. You write your own socket webserver, and use javascript to communicate with it. This is a great alternative to Ajax, as it's much more efficient and reliabe.
node.js can be run alongside PHP, and only be used for ajax-like calls.
node.js
node.js socket turotial
There are nothing innovative. If you have low frequency calls to data and you want super simple access to data then use files. But today is much better to use any database (SQL lite) is ok i think. IF you need more performance then use MySQL or NoSQL solutions. Tools made to solve things. Use the right tool for your purpose.
I'm setting up a realtime app that will be using socket.io. There's currently some core functionally in php, that utilizes memcache and mysql backend.
Would it make sense in the socket.io server to do an ajax request (if that's even possible) to the php page that handles this? There's a lot of MySQL querying, I know it can be done in node.js, but I'd rather keep this part abstracted in php if possible.
So, my question is, is that a proper thing to do? Call a php page from within the socket.io server to then return to the client?
Thanks!
I don't see any problems with having your node.js app communicate with your PHP app by exposing a RESTful API or some PHP script that you can POST to or GET from your socket.io node.js server. There are plenty of npm modules (like request) that can make HTTP requests like that a breeze for you. After retrieving the data from PHP in your node app, you can use socket.io to emit() the data to the socket.io client on the frontend.
There is nothing wrong with that. You are simply using a RESTful API to access the MySQL data, thus isolating the database details.
If one day you are tired of PHP, you can easily switch to Ruby, Python or Whatever for that part without even touching the node.js. If your logic is already written in PHP (you are upgrading an old app), it make even more sense as you can reuse what has already been tested and debugged. A lot of folks are advocating for that kind of separation between systems. Just look at all the SOA (Service Oriented Architecture) buzz.
Where I work we are using this very architecture in a project (though in this case its an ASP.NET MVC Website calling a Java EE app) and it served us very well. With the event model of node.js, its even better since you won't block waiting for the PHP.
But of course, there are some drawback
Performance overhead
Architecture is more complicated
You now work with two language instead of only one (though javascript and PHP are so often used together that I don't think it's really is a problem in this case)
So you need to ask yourself if your problem really need that solution. But in a lot of case the answer may be yes. Just don't forget the virtue of Keeping It Simple and Stupid (the KISS principle)
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.