Non blocking call question

[Theprasit]

Hi Danijel,

Have a question about non-blocking call.

I have a project with 2 RtcHttpClient, one for desktop and one for web access. I have a RtcClientModule connect to RtcHttpClient for desktop and this one is use for all client requests to remote function (mean I used only one RtcClientModule to call remote function), MultiThread is False. I used blocking call for all of client access and its work just fined.

Today I have to call remote function in non-blocking mode, I changed from "Execute" to "Call(nil)", a remote function was execute normally, but my client program still waiting a return result (even I used "Call" rather than "Execute").

Just search in this forum and follow your instruction that I need at least TRtcResult for non-blocking call, so I tried "Call(RtcResult1)" but the result is still waiting for.

I did more study and found that, if I put another RtcHttpClient, RtcClientModule, RtcResult and do calling with "Call(RtcResult)", this is fine, my client program just go to another part of code without waiting.

Could you give me an explanation on this, and please advice for any better practices for this approach. 

Regards,

Theprasit

P.S. Test on RTC 6.45

[D.Tkalcec (RTC)]

1. The Call method requires a TRtcResult component if you expect to receive a result back. You also need to implement the OnResult event on the TRtcResult component, where you will be processing the result received. Check this Quick Start Lesson for a step-by-step example.

2. Just like blocking calls, non-blocking calls also require a free connection to work. If the TRtcHttpClient component you are using is already sending out a request and you make another remote call before you receive a result, each new remote call will be placed in the queue and executed in sequential order, one at a time: make 1st remote call, wait for 1st result, receive 1st result, make 2nd call, wait for 2nd result, receive 2nd result, and so on.

If you have set up everyting correctly, then non-blocking calls will be working correctly with the same components you are using for blocking calls.

Best Regards,
Danijel Tkalcec

[Theprasit]

Hi Danijel,

Thank you for your clarification, I though the problem may came from using only single RtcHttpClient in my project.

While I sent out a "Call(nil)" to execute on the server, I also sent out another "Execute" request to the server, that why I still wait for the first "Call" to finish and return result of sub sequence "Execute" is appear.

So, using another RtcHttpClient to submit a "Call" is fine and should be a workaround in my case.

Thank you and Best Regards,

Theprasit

[D.Tkalcec (RTC)]

Ok. Just for the info ...

With "MultiThreaded=FALSE", non-blocking calls will truly be non-blocking ONLY on Windows and ONLY if "useBlocking", "useProxy" and "useWinHTTP" properties are also set to FALSE on the TRtcHttpClient component. If you want the same non-blocking experience on any other platform than Windows, or when your Client is behind a Proxy and you need to set "useProxy" or "useWinHTTP" properties to TRUE, you will also need to set the "MultiThreaded" property to TRUE.

This is because the async (non-blocking) API is available ONLY on Windows and will ONLY be used when "useBlocking", "useProxy" and "useWinHTTP" properties are all set to FALSE. Otherwise, one of the blocking APIs will be used (blocking WinSock, WinInet or WinHTTP on Windows; blocking BSD on MacOSX, iOS and Android). If you are NOT comfortable writing thread-safe code (which is normally required when using the components with MultiThreaded=True), but you still want to have the communication handled in the background (to keep the Main Thread free for other tasks while waiting for data), also set the "AutoSyncEvents" property to TRUE. The "AutoSyncEvents" property will make sure that all user events triggered by the component will be synchronized with the Main Thread, so you won't need to worry about writing thread-safe code inside the events, because all the code you write will be running inside the Main Thread.

In short ... setting "MultiThreaded=True" and "AutoSyncEvents=True" will give you a non-blocking user experience on all platforms and with all APIs, regardless of all other component settings. It is NOT the exact same thing as using the Async WinSock API on Windows (with useBlocking=False, useProxy=False and useWinHTTP=False), but it is as close at you can get from the User's point of view.

Best Regards,
Danijel Tkalcec