Hardware-control on one computer. But how about several?

Question

For a while I have been pondering the question of, given a standard interface specification, whether there is a way to allow multiple programs to control multiple hardware devices across the network. The program I am working with is the standard implementation of the ASCOM standard.

In short, the principle is that any program can call another known program or driver and expect it (computer-wise) to implement certain standard interfaces, allowing the calling program to control hardware. Currently we only use COM and .NET to do this.

This allows many different hardware and software manufacturers to all build software and drivers that all work together. By now it is becoming quite standard, including standard telescope companies providing drivers.

Within the ASCOM group, we have discussed how to do this across the network, but since we are more of a user group with a couple core devs, we have never been able to really decide what's a good way to do this. In order to understand the situation better, since I have already made a proof of concept system that works, here are several questions.

1. What transports/pipes/interops are available that most or all languages support across OSs? Or is the transport OS specific? I mean, for instance, the COM interop is on windows. Is there an equivalent on Linux, for instance, that would work the same and the language could use interchangeably? Most languages support network IO. Do we have to use that for interprocess communication or are there other options?
2. To make something truly platform and language agnostic, it would almost need to be dealing with text strings, not binary objects. What standard formats are there, and what are the pros and cons of each.
3. What are your thoughts on getting multiple languages to work together on one computer? Can it work well? Inter-process or intra-process as well?
4. Is something like ASCOM done in any other field of computing? Or are astronomers the only people who connect various software programs and hardware devices together to get one working system?

If you need more information, feel free to ask. The ASCOM standards home page is short and hopefully might help illustrate things a bit, but I don't expect you to crawl all over the site before you can answer. :D

Answer 1

I assume the common underlying technology is TC/IP packets, and some kind of packet protocol layered on top. The question is which?

If the performance requirements are extreme and you have a willingness to write low level code then you will probably use something based on UDP. This is a connectionless protocol suitable for peer-to-peer communications, but you will have to write quite a bit of protocol code on top. Protocol buffers (as mentioned by @mattnz) provides a way to generate the structures and conventions required to support low-level binary protocols across a wide variety of different languages and architecture.

If the performance requirements are moderate and you have to support a lot of very low level devices, then you will probably use something based on TCP sockets. The natural approach is to write host servers and device clients, and again protocol buffers could be the way to go. You might use this for a camera data feed, but not so much for just sending instructions to position a telescope.

If the performance requirements are less demanding and the devices are all programmed with high-level languages, then you might well choose something based on HTTP. It is quite easy to write a sophisticated server on the host side supporting such things as SOAP, XML, JSON and REST. A simple client need only assemble a string and send it via a socket. There are libraries available in multiple languages to support these technologies, and in many ways they are the natural successor to the COM/DCOM you are already using. This would be well-suited to sending command strings and receiving responses, but perhaps less so for large batches of binary data.

Hopefully one or more of these will suit what you need.