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

  • 2
    – mattnz
    Aug 11, 2014 at 22:43
  • The first thing that come to mind is HTTP and SOAP/XML/JSON/REST-like things. Is there a reason why not?
    – david.pfx
    Aug 12, 2014 at 14:13
  • Lots of stuff happening with HW/SW in robotics right now. Have you looked there?
    – david.pfx
    Aug 12, 2014 at 14:14
  • The unfortunate problem is that hardware is very...hardware specific. While it is simple to create a common API/messaging format at the application layer it becomes much harder at lower levels without imposing specific types of interfaces on the hardware. How are you going to interface a device with only a RS-232 port with one containing only an Ethernet port? Unless someone can come up with a really low cost/low power/high speed communications interface that everyone wants to use then I don't think this problem is solvable. At best, you can get the hw to be "My Standard Interface" compliant.
    – Dunk
    Aug 12, 2014 at 14:55
  • Did you look at the protocol buffers link that mattnz posted yesterday? Aug 12, 2014 at 22:51

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.