Question What is the best way to communicate between add-ons?

[Wishbone]

What would you consider to be the "best" way to send small structs from one add-on to another? (i.e. from one MFD to another MFD to avoid duplicating rendezvous or other bulky calculations)

(have used named pipes and sockets in the past, but was not forced to deal with other authors)

Requirements:
1. Should work asynchronously, without hanging Orbiter, with as little overhead as possible.
2. Only local operation is envisioned (no remoting etc.)
3. Should tolerate presence of any known or suspected firewalls and antiviruses.
4. Should allow for precise specification of data items to be sent.
5. Should not propagate special floating point values (NaNs, denormals or infinities).
6. Should allow the server to signal data availability after lengthy computations have been completed.
7. Should force the client (programmatically) to cache and re-use last received value instead of continuously polling the server if the update frequencies differ at the client and server sides (i.e. the server uses 1 Hz MFD Update, while the client needs the data at each PreStep).
8. Should work on x64 and x32 Windows architectures, and even under Wine.

Of course, an existing (and well-debugged) solution is preferred to reinventing the bike.

 

[Bonanza123d]

move this to the SDK forum. I think it would be your best bet.

If you don't forget, you can use reference dlls. I would do that. I did that for a C# dll. I don't program in C++, but may get a head start on it.

 

[Wishbone]

?? what do you mean by reference dlls? How could this be construed as asynchronous comms?

 

[Bonanza123d]

I use the dll load calls described on msdn. I'm not sure how to use it. Though you then have access to the structs. I am not 100% sure. I am normally a C# developer.

 

[Urwumpe]

I'd use shared memory there, if you just want local communication. You could also create a DLL that acts as central communication hub API for your MFDs, permitting every MFD to link to the DLL and the DLL manage the shared memory or mail boxes.

 

[Wishbone]

Shared memory? OK, thanks. However, I was thinking in terms of a statically linked library, robust enough to be upward compatible, or simply not needing upgrading.

 

[Urwumpe]

Shared memory? OK, thanks. However, I was thinking in terms of a statically linked library, robust enough to be upward compatible, or simply not needing upgrading.

Make it dynamically linked. As long as you keep the interface fixed or only grow it (no modification), any add-on could use the most recent release of the DLL without problems.