What is a way for a web browser to communicate with a hardware device?

Question

I have a data acquisition hardware device attached to a PC via USB that I'd like to send some information and settings, acquire some data, and then retrieve the acquired data on the client and send it to the server. The plan is to use a web portal to communicate with the device attached to the client PC. I was planning on writing a DLL to talk to the device. My environment on the client is Windows using IE as the browser. The server side is Windows or Linux. What is the best way to communicate from a web browser client to a client-side device?

Clarification: The first goal is to allow the client PC to send acquisition settings to the device. The settings may be manually entered at the client or may come from the server. The second goal is to get the acquired data to the server's database. I don't need to display the acquired data at the client.

The hardware device has a CPU but very limited memory. The protocol to communicate with the device is undetermined but I may access the device like a USB drive.

Please respond with one method per answer so people can vote on indenpendent answers.

As with all StackOverflow Poll type Q&As, please make certain your answer is NOT listed already before adding a new answer

• If it already exists, vote that one up so we see what the most popular answer is, rather than duplicating an existing entry.
• If you see a duplicate, vote it down so the top entries have only one of each model listed.
• If you have interesting or additional information to add, use a comment to the entry it applies to rather than creating a duplicate.

Answer 1

It's not the web browser the one communicating with the device, it's the web server. IOW, write a small webapp that instead of (or in addition to) reading data from a DB, reads from the device, and present to the user as HTML.

a different way to achieve the same would be to write a daemon that polls from the device and writes to a DB, then write a frontend to present the stored data. This scheme is better if you want to present a record of past lectures against time. The first method is better to use the browser as a simple interface to the device.

Answer 2

You can take the easy way and use an embedded web server as a service to collect the data and access it like an ordinary web site from the browser. It requires the client to start the service though.

You can use it as a proxy to your portal also, in which case you don't have to deal with security restrictions of multiple domains.

Answer 3

Write an ActiveX plugin to collect the data but I am not sure if it will grant you the required permissions. You can try to write a Netscape plugin alternatively if you can run on another browser. I don't know any restrictions other than imposed over the plugin host.

Answer 4

Normally this issue is addressed by having a third party software/driver installed on the client machine. GEM Smart card reader uses this approach. However, we need to remember that taking such an approach makes the design deviate from thin-client model. A better way to do would be create a service on the client machine.

Answer 5

You could use a Java applet and communicate with the device via serial port.

Answer 6

If you using USB interface to connect your hardware i would suggest using USB CDC EEM class that is designed to provide Ethernet other usb simulation and used exactly for this purpose - expose web server on embedded devices, this one for example, in various designs.
Small addition you will need to implement CDC EEM class driver on PC side as well to get this working.

Answer 7

We have the same need and are evaluating the option of running a proxy on the client that listens on 127.0.0.1:8080. The proxy can talk to the device and any local browser can talk to the proxy by making requests to 127.0.0.1:8080 in js and then forwarding the results to the web portal. No idea if it will work as any security software could disallow the browser from making requests to 127.0.0.1 and squash the entire thing.