FSUIPC SDK "SendMessageTimeout"

[737SimGuy]

Hi Pete,

First off, let me point out that I am not having any real performance issues with FSUIPC. However, I have been doing some snooping, and found something that I am wondering if it could be improved (on my end, not yours).

In the FSUIPC VB, (and C), interface code for sending Writes to FSUIPC it is using "SendMessageTimeout" like this:

While (i < 10) And ((SendMessageTimeout(m_hWnd, m_msg, m_atom, 0&, SMTO_BLOCK, 2000, dwError)) = 0) dwError)) = 0) do begin // return value

i = i + 1

Sleep (100) ' Allow for things to happen

So it tries a write and then *blocks* any more processing until it receives a response, with a 2000ms timeout, then tries again (up to 9 times). Do I really need to use SMTO_BLOCK or would it be more efficient to use SMTO_NORMAL which would allow other writes while waiting for responses. Or, maybe this would muck up FSUIPC? Also,would maybe a smaller timeout value be appropriate? With the 2000ms timeout and 9 attempts I would have to wait 18000ms for the next write! Seems high to me.

Any thoughts?

Regards,

James

[Pete Dowson]

So it tries a write and then *blocks* any more processing until it receives a response, with a 2000ms timeout, then tries again (up to 9 times). Do I really need to use SMTO_BLOCK or would it be more efficient to use SMTO_NORMAL which would allow other writes while waiting for responses. Or, maybe this would muck up FSUIPC?

If you don't receive a response in that time it is because the process you are sending it to (WideClient or FS itself) is tied up (eg reading or writing a large file) and not processing its message queue. Either that or its message queue is so long that it is taking ages to get through it, but that is less likely. Part of the delay could also be process switching, which may be also slowed by other processes and by memory shortages.

Sending another message before the first has responded merely complicates matters. The other will be dealt with first, in any case, as it will be in the queue first. FS will be processing the messages one at a time as it sees them, as will FSUIPC when it gets them handed down from FS's message loop.

The original code recommended by Adam in FS95/98 days had a single attempt with a timeout of 5 seconds or more. I didn't like that as it appeared to make the application more "hung", so I changed it to multiple attempts with a shorter timeout. The reason I extended it considerably was to allow good results with WideClient when "wait for new data" is set. If you don't use that then you could reduce the number of attempts.

With the 2000ms timeout and 9 attempts I would have to wait 18000ms for the next write! Seems high to me.

It would be high to anyone, but if FS was stuck not processing any messages for that long you'd probably be swearing about the hung state of FS, not worried about your application!

Pete

[737SimGuy]

Ok Pete, thank you. I may experiment a bit but most likely will leave as is...

James