title: Server IPC design issue
body: <p>i have a design issue regarding sending user data from a mobile phone app to a server (Debian 5 LAMP). I need to 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.</p>
  
  <p>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!</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Not having much server side experience i was just wondering whether there were any standard solutions to this issue.</p>
  
  <p>I currently use the following php code (called from apache) to communicate with the server process</p>
  
  <pre><code>$pipe="/tmp/pipe";
  $mode=0600;
  if(file_exists($pipe))
  {
  
     $f = fopen($pipe,"w");
     $result = fwrite($f,"some string");
     echo $result;  
  }
  </code></pre>