Server IPC design issue

i have a design issue regarding sending user data from a mobile phone app to a server (Debian 5 LAMP). I need t开发者_如何学Goo send various details such as username , date of birth, customer order no. etc. These will be passed onto a C code app (always on process)running on the server.

I am currently using named pipes for IPC between my external mobile app and the C code server process. I have a permissions issue with this method of communication but instead of just trying to resolve this i was wondering whether i have the correct approach in the first place!

Firstly i was wondering from a design and security point of view is this an acceptable method of IPC in this case or SHOULD i be writing the data into a database and then running a cron job which reads new entries from the database and then sends these to the server process.

With my current method i am concerned that if there are a few users update at the same time some might not get access to the pipe, so maybe the entries need to be queued so in this case picking up entries from database may resolve this.

The only concern i had with this database solution was there would be a delay between receiving data from the mobile and app and passing it on unless the cron job ran every 10 seconds but then it might be running needlessly when there are no new entries.

Not having much server side experience i was just wondering whether there were any standard solutions to this issue.

I currently use the following php code (called from apache) to communicate with the server process

$pipe="/tmp/pipe";
$mode=0600;
if(file_exists($pipe))
{

   $f = fopen($pipe,"w");
   $result = fwrite($f,"some string");
   echo $result;  
}

I'd probably suggest your best bet is to use a shared data store to process these requests asynchronously.

You've not said how the results get back from the process to the web app, but as it seems to be a single-direction pipe, perhaps there are none.

The technique you've alluded to above will not be thread-safe / process-safe, as race conditions will cause the output from different threads to be intermingled, resulting in garbage being received.

My suggestion would be to write files into a "spool" directory - but be sure to write them under a temporary name and rename them when finished (rename is atomic, writing files is not).

Have the daemon check for files in this directory (with a non-temporary name) and process them in whatever fashion. Optionally write the results into another directory by a similar mechanism.

Ensure that your monitoring systems monitor the number of files in these directories, and the age of the oldest one, so that a fault is picked up.

I would say that your approach was wrong in the first place. You are trying to make your mobile app (it runs on the mobile device, doesn't it?) communicating with a C-App process on your Debian server via named pipe IPC which never works! IPC stands for Inter Process Communication and it is about communication between 2 processes on the same machine. Named pipe is one of the ways implementing IPC and thus works on the same Linux machine only.

So, use another approach instead. From what I have read, you should use a client/server architecture in which your server (C code app) allows multiple clients (mobile app) to connect & send data simultaneously. The server decides whether it flushes incoming data to the database or caches that data in the memory... This way of communicating is not passive so you don't have to run an external cronjob to update the database. You can use an internal scheduling module to regularly udpate the database though.