Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 484
  • Last Modified:

Send data from php on webserver to c++ app on local machine

I'm working on a project that needs to get data from a php script on a webserver and send it to a c++ app that is running on a local hardrive (not same computer as webserver). I know there are plenty of resources on wiritng sockets in php and c, however I need help understanding the specifics of making this work (if it is possible). First, the machine runninig the script will be connected to the internet of course. I know how to find the ip address of my pc, but I cannot seem to create a connection from a php script to it. Are there settings I need to alter or could there be a  block from the network i'm connected to? How do I choose a port and find out if it is open to send and receive on both ends?

My hack for the moment is to save the data i need to a file on the server and have the c app check that file. It does not seem to make sense to do it this way when I do not need to save the data but just transmit it. I also want to have the  c app just listening for incoming data, not actively accessing a file ona server.

Thanks for any help!
  • 2
  • 2
1 Solution
- I'd recommend a 'pull' not a 'push'.  That is, have the client pc connect to the server, not have the server try and push to the client.  That's just a general suggestion, usually helpful when the server/client might have particular firewall settings that make it difficult.

- In either case, yes, firewall or proxy could get in the way of opening a socket.  Depending on where the client PC is, opening a particular port could be blocked by the PC, or company (if internal) firewall, or ISP (if home) firewalling.

- The advantage of having the client PULL is that your webserver is already running, and accessible.  Thus, opening an HTTP connection is already possible -- so you use it.

- The C++ app and the webserver can obviously use a number of security methods to ensure safety of data -- assuming it's data that needs to be secured.  That, of course, would be a question in and of itself! ;)

I just had a user trying to use sockets with the opposite-direction problem -- he was trying to grab a page from a public website, but turned out HE was behind a firewall and proxy that was blocking the connection...

How often does data need to be transmitted between the machines?  Can you poll instead of push?  i.e., is there a reason you are trying to push from the server specifically?  I can think of things like say e-commerce orders on a website, and you want them pushed directly to you -- however, in most situations, you could do a check every 5 minutes, and batch-download any updates since the last check.

If you can detail the basic process, and where the client machine resides (home, work, etc.), I can give even more specifics.  But I think the above outlines the basic thought process.

csugrueAuthor Commented:
Thanks for the comments!

Well, this for digital art installation that allows multiple users to connect via mobile phone to the application which is projected inside a gallery. It uses vxml to capture keypad input and the php script would then send it (potentially) to the c++ application. The cellphone becomes a remote control to move things around in the projection so it needs to have a quick response time to the users input.

Right now it functions by saving the data on the server and looking at that  data in intervals (I think this is what you are suggesting). This works fine with some delay, but I thought it would be faster and more logical if the php (it could also be a perl or c app on the webserver) sent to the c++ app directly. Does that seem to make sense?

The webserver is on a university server and the machine running the app will be on seperate network inside a gallery...
Marcus BointonCommented:
I'd say this sounds like it should be done using a continuous delivery protocol like IRC or similar instead of HTTP, so that your PHP can send data immediately as it arrives. You'll get much better responsiveness that way. However, you can't reliably run a PHP script continuously from a web server - it needs to be a standalone process.You'll need to open a socket that the PHP process can connect to and keep open.  You can pass info to it via shared memory and kick it into action by sending it signals from scripts that are exposed to the web. This way you can do the 'push' technique you're after - maximum efficiency, minimum latency
You can do that with standard WAP/HTML inputs, that's easy.  As Squinky notes, a custom application running on the webserver that keeps an open socket to the gallery box might be a more straightforward approach.

However, so long as your networking is fast enough, php should be able to receive the input from the user, open a socket to the gallery box, send the command, and close down, in an interval of a second or two.  At some level, it actually depends MORE on the wap/web connectivity of the phones TO the webserver than it does the webserver to the gallery box.  Phone browsers and latency from their network to the live net are notoriously slow, so the further delta opening a socket on the fly to the gallery box shouldn't be much.

CERTAINLY, you can get to a completed, working prototype opening and closing the socket for every input.  That will have you at a stable implementation of nearly everything.  If that proves to be too slow, FIRST prove the slowness is the PHP->C++ socket stuff, and NOT the cellphone side of the equation.

If it is due to opening sockets on the fly across the net to the gallery, there are a few approaches -- my suggestion, in order to keep things best-abstracted, would be to simply change the PHP code to open a LOCAL socket on the webserver box to an always-running daemon/application (on an internal-only-needed port number, like up in the 20K range or something), post the SAME EXACT data you'd post to the gallery box, and close down.  The daemon would have a continuously-open connection to the gallery box, sending keep-alive pings every N seconds (and re-establishing connectivity if dropped, as well as possibly kicking off email/etc. to you!), and has a listening socket for the PHP script to connect to.  When the script connects, it literally just passes the data along -- basically, acting as a conduit, doesn't even need to look at the payload.

But this way, START with building the php->c++ process as an open-send-close socket process, and see where your issues/bottlenecks really are before doing further enhacement -- as you should then at least be at full functionality, though it might be slow/hesitant with commands.

csugrueAuthor Commented:
great, yess that sounds like the approach I'm looking for. I'm going to give these suggestions a try. thanks!

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now