The SimConnect_Open() call allows me to pass a client’s name and the remarks
explicitly mention the possibility of having multiple connections open at the
same time. Now in WASM this is not very useful, since we don’t have multi-
threading (yet), but outside the simulator we can use this to spawn separate
threads for separate client connections. In testing CsSimConnect with multiple
threads making calls using the same client connection, I noticed several times
errors that would only disappear if I added an explicit lock to ensure only
one thread would make “SimConnect_” calls at the same time. Can you actually
confirm that what I observed is indeed a known limitation? Is this still the
case if I use multiple connections? Being able to actually see the SimConnect
SDK’s source code would of course answer a lot of questions, but for some
reason or other it is very much walled off, even though it doesn’t (should
not) reflect any knowledge of your modern-day simulator. Even just publishing
the (TCP) network protocol would be a tremendous accelerator/amplifier for
addon development. (Admittedly to enable us to build an alternative API, but I
guess you already knew that. ;-)) Cheers, Bert
Hello @bert.laverman SimConnect is not thread safe. Even in the case of not
sharing clients across threads, there are some common ressources that will be
accessed in an unsafe way. When you say you have “errors” when making
SimConnect calls to a common client in multiple threads, what kind of error
are you talking about. I would expect something critical. Could you elaborate
on how providing info about the different SimConnect protocols (Pipe, IPV4 and
IPV6) would “be a tremendous accelerator for addon development” as opposed to
adding your own layer on top of SimConnect? Regards, Sylvain
As for the errors, my test application wasn’t that elaborate, so it was mostly
a matter of not getting the expected results. I’d have to redo the test to see
if I can reproduce those results, but given that you already acknowledge
SimConnect has shared data that is not threadsafe, I know my current approach
(using a single mutex to synchronize all calls to the static library) is what
I need to continue doing. I’ll also make sure this is done across client
connections. As for the benefits of having a published protocol: Addons that
do not run as a part of the simulator (so neither as DLL nor as a WASM module)
need to find a way to consistently connect. However, the biggest limitation is
that the SimConnect library is Windows only. So, if I want to develop hardware
using e.g. a Raspberry Pi, build a UI (Little NavMap is a good example) that
can run on multiple platforms such as Linux and macOS as well as Windows, or
(to shamelessly refer to another discussion) open up access to L-vars, (think
FSUIPC and WideFS) I am immediately forced to design my own network protocol
and write a Windows-hosted server component that translates my protocol to
SimConnect calls. Some people have put a lot of sweat and tears into reverse
engineering the network protocol (I found a jsimconnect library on GitHub, for
example) to be able to write their own cross-platform library, but the problem
is that this is unsupported. Any update on the simulator side may cause the
library to stop working in the most unexpected ways. Worse, it is impossible
to verify that the implemented protocol is even correct. As a result, most
add-on developers just keep re-inventing the wheel and writing their own
protocols, thus wasting the time and effort they’d rather have spent on just
using what is available. Another issue is the lack of lifecycle management in
SimConnect IDs. We have Define-IDs, Request-IDs, and Send-ID’s, to name the
most commonly encountered ones, and in most cases there is no clearly defined
moment when you can consider such an ID “ended.” Error reporting, with either
Send-ID or Request-ID is completely asynchronous, so we need to just add a
timeout or something like that. (say a FIFO queue with a certain number of
Send-IDs) The safest way of dealing with this in a dynamic environment, where
we cannot use static constants for IDs as most samples do, is to use throw-
away IDs. Just one request, and if it is not about repeating incoming data,
pick a fresh ID for the next call. But the documentation for SimConnect
exceptions contains this cute remark about a maximum number of IDs. Say what?
I don’t know when the ID ceases to be relevant, so how can I limit my number
of IDs? If we have a specification of the network protocol, even accepting
that it may change, just like the SimConnect library is changing over SUs at
the moment, we can stop doing double work. If we know how the SimConnect
library is doing things, we might be able to streamline error handling and add
ID lifecycle management. Putting a layer on top of SimConnect can only solve
some of these issues, but in a sense, I am just as guilty of reinventing the
wheel as everyone else.