Interference with other comms

[DPerkins]

Using BCB2007, RTC v6.24.  We've almost moved to v11.1 & RTC 9.51 but for now our customers are using RTC 6.24.

Our 3-tier application with RTC works really well.  Our software can optionally talk to telephone systems via the use of a TAPI driver.  For one particular telephone system, their TAPI driver produces strange output when our application uses 3-tier mode with RTC.  If we enable Client-Server mode with doesn't use RTC, everything works fine.

Which working with other comms libraries (ICS, Synapse) to talk to phone systems, my colleague has noticed that when 3-tier mode is enabled (which uses RTC), comms packets may be received out of sequence.  Without RTC, the packets are received in order. 

I appreciate that we should not assume packets are received in a particular order and we can code around that.  However, this third-party TAPI driver (from 2016) appears to not have that flexibility.  Are these common effects and is there any way around these issues?

Many thanks.

[D.Tkalcec (RTC)]

1. What do you mean by "TAPI driver produces strange output"?

2. What do you mean by "comms packets are received out of sequence"?

3. What is the difference between your "3-tier mode" and your "Client-Server mode"?

4. Are you using RTC components in Asynchronous mode ("Blocking" property on TRtcHttpClient/TRtcHttpServer components is FALSE)?

5. Are you using RTC components in Multi-Threaded mode ("MultiThreaded" property on TRtcHttpClient/TRtcHttpServer components is TRUE)?

6. Are RTC components in this scenario used to implement a Server (TRtcHttpServer) or a Client (TRtcHttpClient) or both?

Best Regards,
Danijel Tkalcec

[DPerkins]

1. Some events from TAPI are not received, so we're had to ask customers using that specific telephone system to not use the 3-tier/RTC mode.  This is across multiple customers.

2. I assume he means messages are not received in the order they were sent.

3. In client-server mode, the client application talks directly to the database (No rtc involved).  In 3-tier, the client talks to the middleware using RTC and then that talks to the database.

4. Blocking = false.  In the code I will sometimes use Call or Exceute depending on circumstances.

5. Multi-threaded = true.

[D.Tkalcec (RTC)]

1. Is a "TAPI driver" some 3rd-party DLL that you load from your Application, and then make calls to specific functions exported from that DLL, or is it an external process that you communicate with by using TCP/IP or UDP or HTTP?

2. Are you making calls to the "TAPI driver" from inside RTC events on your Server in your 3-tier RTC mode?

3. Does this 3rd-party TAPI driver use asynchronous sockets to communicate with external processes or devices?

[DPerkins]

1. TAPI = Telephony API.  Think of it as similar to a printer driver, but for telephone systems.  The driver is installed in Windows.  There's a common interface and then the driver communicates to the phone system in whatever manner they choose, though usually via the network (in this particular case) but in olden times down an RS232 link.  In this case, the driver communicates to the telephone system at a known IP address on the network.

2. The TAPI driver is installed on the client PCs, so our main application is performing RTC comms to our middleware, and the TAPI driver (a system level driver) is doing it's business and sending events to our app saying things like "Incoming call", "Call answered", "Call disconnected" etc.

3. Unknown, but I would assume so.

[D.Tkalcec (RTC)]

If the TAPI driver (which you are utilizing from your Clients) is using Asynchronous Sockets, changing the "Blocking" property of your TRtcHttpClient components to TRUE should eliminate any possible conflicts at the socket communication layer, since RTC would then use Blocking Sockets instead of Asynchronous (default).

If your Clients (TRtcHttpClient components) are already Multi-Threaded (their "MultiThreaded" property is TRUE), changing the underlying API that RTC uses (from Asynchronous to Blocking sockets, for example) should NOT require other changes in your code, since RTC would simply use background threads to keep the main thread free.

If your Clients are NOT Multi-Threaded, then changing to Blocking is going to make all your RTC calls blocking, basically "freezing" the Main Thread for all kinds of communication and message handling, until a RTC request has been sent, a response received and processed.

[DPerkins]

Thanks Danijel.

My client is not multi-threaded and I assume making them multi-threaded will just affect Call requests and not Execute?

[D.Tkalcec (RTC)]

When you set MultiThreaded on a TRtcHttpClient component to TRUE, it won't change the way the Execute method works (it will still be blocking while waiting for a result), but ...

All the events you have implemented on that TRtcHttpClient component, as well as any events you have on any components linked to it (TRtcDataRequest, TRtcClientModule, TRtcResult, ...), will be running from Background Threads.

RTC components that link to the TRtcHttpClient component have the "AutoSyncEvents" property, which you can set to TRUE if you want all your events on these components to be called synchronized from the Main Thread, instead of background threads. For RTC components which do NOT have the AutoSyncEvents property, you can manually call the Sync() method from inside the events, to call the event synchronized from the Main Thread.

If you search this Forum for "multithreaded", you will find quite a few topics related to using RTC components in multithreaded mode. Should you have any other questions, feel free to ask.

[DPerkins]

Thanks for that.

I'll create a test version for the people with the problem TAPI driver/Phonesystem.

My application has 5 rtcHTTPClients/Modules/Results as I download a lot of zip files at start-up.  I've set them all to Blocking/MultiThreading/AutoSynchEvents.  I'm assuming when I call clientModule->Call(..), even though the result appears in the rtcResult->OnReturn event that Sync() has already been called by the clientModule.

MultiThreading - I've looked in the help files and read some old posts, will investigate further.

Thanks again.

[D.Tkalcec (RTC)]

Yes, if you set AutoSyncEvents to TRUE on a TRtcClientModule component, all events triggered by that component will be synchronized with the Main Thread, which also includes events called on any linked TRtcResult components.