StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Let's call the topmost machine 'Server', the middle machine 'Controller' and the bottom machine 'Device'. It does not matter if the device is a peripheral (say, USB or serial device), or a computer.</p> <p>The first task is to get the Controller to query the Device. The best way to do this really depends on the Device. If you consider things like USB audio/video devices, they need to be tuned, then they send a continuous stream of data. Things like temperature or humidity sensors are told to do a measurement, then they respond with data.</p> <p>Usually you write the required functions into a small library, and verify it works using command line tools. In some cases the library may not be necessary, for example if the Device is already supported by the kernel in Controller, and the information is trivially available. (For example, consider the temperature sensors in hard drives: if Device(s) are hard disks, then Controller can simply use the command <code>hddtemp /dev/sda</code> to get the temperature of the <code>/dev/sda</code> (first SATA/ATA/SCSI hard disk). I'd expect the end user to be able to pick which hard disks she is interested in, so that choice would have to flow from Server to Controller.)</p> <p>Next, you write a service that will run on the Controller. This service will incorporate the library functions already written and tested, so it can easily access the Device. (This way you <em>know</em> the Controller-Device communication works, and don't need to worry about it. One thing at a time.)</p> <p>There are many different designs for the service, from plain TCP/IP or UDP/IP sockets to Remote Procedure Calls (RPC), to high-level protocols like HTTP. In recent years, the last, using HTTP, has become more and more common, with responses being XML, plain text, or binary media (usually images). The idea is to have the service be basically just another web server that can access the Device directly. Security is simpler, because it does not need to be world-accessible: it can very well only answer to requests coming from the Server only. I've written such services using basic shell scripting (Bash), PHP (both PHP-CGI and command-line PHP, PHP-CLI), and C, among others. The best choice depends on the details, really. I personally prefer either a simple text-based TCP/IP socket, or HTTP.</p> <p>On the Server, you can write a PHP page, that connects to Controller, requesting whatever it wants to request (usually depends on user data, first checked for sanity and safety, of course). PHP has easy built-in facilities for doing both HTTP requests and connecting using raw TCP/IP, so it suits quite well for this. If HTTP protocol wrappers are enabled, then it is just <code>$handle = fopen("http://192.168.x.x/myservice?param1=" . urlencode($param1) . "&param2=" . urlencode($param2), "r+b");</code>. To get a socket connection, you use the <code>fsockopen()</code> function instead. (For details, see <a href="http://www.php.net/manual/en/function.fopen.php" rel="nofollow"><code>fopen()</code></a>, <a href="http://www.php.net/manual/en/wrappers.http.php" rel="nofollow">http wrappers</a>, and <a href="http://www.php.net/manual/en/function.fsockopen.php" rel="nofollow"><code>fsockopen()</code></a> at the <a href="http://www.php.net/manual/en/funcref.php" rel="nofollow">PHP Function Reference</a> at <a href="http://www.php.net/" rel="nofollow">www.php.net</a>.)</p> <p>In practice the PHP page code first creates a connection to the Controller. Then it sends a request, containing the relevant sanitized commands/parameters received from the end user. Then it waits for the Controller to respond with the results (by simply reading the response), then closes the connection. The response should contain all the data needed, so the PHP page is free to construct the page to the end user.</p> <p>None of this is really difficult, but there is a lot to do. I've found the Controller-Device communication to require the most work; after that is done, the rest has always been quite straightforward.</p> <p>If you can provide more details what the Controller-Device connection is, what kind of data (text? numbers? images? a lot of binary data?) the Device provides, and what kind of parameters/commands (just "one result, please?", basic commands like "move up", "where are you?") do you expect you need to send to the Controller/Device, I could perhaps be more specific.</p> <p>Also, are you limited to PHP, or would you be comfortable writing the Controller service using C? I've found that to be a very good combination myself.</p> <hr> <p>Edited to add:</p> <p>In a nutshell, the three points can be answered as follows:</p> <ol> <li><p>Either using <code>fopen("http://ip.add.re.ss:port/", "r+b");</code> if using the HTTP protocol and PHP is configured to allow http wrappers (they usually are), or using <code>fsockopen()</code>. See the PHP documentation linked above for details.</p></li> <li><p>With an IP-connected Device, Controller is basically a relay or translator. Usually this means a daemon running on Controller, managing incoming requests from Server (or Servers), and responses from Device (or Devices). This is more common when there are a varying number of Devices, and/or more than one interface is needed. In practice, the Controller runs a daemon just like described above, except the protocols may be standard or simple enough so there is no need to write a library.</p></li> <li><p>The PHP running on the Server must contain the request details (exactly what is desired) to the Controller. The Controller must pass them on to the Device. If the Controller provides a http URL for the PHPs on the server connect to, it can parse the query parameters, and translate them into a format the Device understands. One particular issue in practice is to handle concurrent accesses. There is usually only a single connection from Controller to Device, but more than one PHP might connect to the Controller simultaneously. So there is some book-keeping involved. In some cases the Device provides a continuous stream of data (or regular updates of data) to the Controller, and the Controller simply keeps tabs on it. When a PHP running on the Server queries something from the Controller, the Controller simply looks up the latest data (without contacting the Device at all, just receiving the data as normal), and responds with it. Here, it is common to include a timestamp, or better yet, the age of the data, in the response from Controller to Server.</p></li> </ol> <p>You really should add some details to your question. (I suspect the downvote is due to lack of details.) You don't need to tell us the exact make and model of the Device, only whether it is a receiver (TV? radio? weather station?) or a sensor cluster or a door lock, and if you know any details on the communications protocols (which ones)? Thus far, we only know it uses IP. That does not help at all, just about <em>everything</em> uses IP nowadays. This is also why my answer is so vague; I'd like to be more precise, but you do not provide enough information for me to do so.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload