IPC request handling sync or async?

[wweyers]

Dear Pete,

I'm quite an experienced system level programmer but almost new to remote controlling FSX. I successfully updated your API for current Delphi versions and use it with no problems.

My first question is regarding the way requests are processed on the server side (FSX). If e.g. I do a write request on #0BB6 (Aileron Control Input) followed by an immediate read request within the same IPC call (SendMessageTimeout(...)), will the response for the value set during the write immediately be reflected on the read? Means, will the request be processed synchronously on the server side? Or is the request being processed asynchronously, such that the result will be reflected at some later read request?

My second question is regarding timing. Doing the same reads, without any writes, within a loop, the time for processing the request (i.e. the SendMessageTimeout()) differs significantly in the range of some few milliseconds up to around 40ms (using precision timers), all measured against a more or less idling FSX and an average CPU load of less than 5%. How comes? Has it to do with FSX periodically generating frames? Based on these findings, what would be your recommended polling intervall?

Thank you for reading, kind regards

Walter

Germany

[Pete Dowson]

My first question is regarding the way requests are processed on the server side (FSX). If e.g. I do a write request on #0BB6 (Aileron Control Input) followed by an immediate read request within the same IPC call (SendMessageTimeout(...)), will the response for the value set during the write immediately be reflected on the read?

If you are sending from a WideClient PC, yes, because WideClient updates the local memory at the same time. If you are talking about a program on the FS PC, then yes for FSUIPC3 on FS9 and before, no on FSUIPC4 and FSX/ESP, because it maintains two sets of offset data - write and read, and the latter will be updated according to the data received from SimConnect.

Means, will the request be processed synchronously on the server side? Or is the request being processed asynchronously, such that the result will be reflected at some later read request?

Depends as just stated. SimConnect is asynchronous because it is based on messages sent and received, not returns from functions or procedures. In FSUIPC3 it's all done by hacks into FS innards so it tends to be synchronous.

My second question is regarding timing. Doing the same reads, without any writes, within a loop, the time for processing the request (i.e. the SendMessageTimeout()) differs significantly in the range of some few milliseconds up to around 40ms (using precision timers), all measured against a more or less idling FSX and an average CPU load of less than 5%. How comes? Has it to do with FSX periodically generating frames?

Your messages goes into a message queue operated by Windows. FS itself uses messages also, profusely. It also has quite a lot else to do during which times the messages don't get a look in. So the main variability is how long it takes for FSUIPC to actually see the message. The other is how long it takes for Windows to switch processes in whatever processor they are running. FSUIPC is only part of the normal FS main thread, not a separate one. For reads only it responds directly, so once the message is seen it is no time at all. Writes are often different because they trigger other actions and possibly calls into other parts of FS.

Based on these findings, what would be your recommended polling intervall?

That's purely application dependent. If you only need things every second, then 1000 mS is okay. If you are trying to control the aircraft in real time, then 10-20 milliseconds might be needed. But then don't assume that all your polls will be equally spaced. If you need them to be, use the miilisecond timer to determine the true spacing and adjust variables accordingly.

Regards

Pete

[wweyers]

Dear Pete,

thank you very much for your comprehensive reply!

Regards

Walter