RTC Forums
April 29, 2024, 12:51:51 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: RTC clients in DLL called Intraweb app  (Read 4840 times)
zsleo
RTC Expired
*
Posts: 80


« on: January 08, 2012, 03:41:22 AM »

Danijel

Happy and prosperous 2012 - as well as to all other RTC enthusiasts.

My problem…

I have many (10+) Win 32 apps developed with Delphi XE & running RTC v 4.49 that are running redundantly across a bank of servers in a VERY secure network.

All of the apps except of one Intraweb app have RTC implemented in them.

One of the apps (WDMC) is a watchdog/monitor/alerter of all apps running in the secure network.

The WDMC is itself implemented as a DLL with a simple GUI EXE to users with an operating interface.

This has been working perfectly for almost 1 year now.

The Intraweb app is used by support and admin staff who are not allowed to directly connect to the secured network.  I now want to provide the Intraweb users with some of status information available through the WDMC DLL. The Intraweb app loads interfaces with the DLL successfully BUT I cannot get the WDMC DLL when loaded by Intraweb to connect any of the DLL RTC clients to connect to any of the EXE’s RTC servers.

Any suggestions to where I could be “going wrong” – I really don’t want to put DB access into EXE’s to achieve this functionality.

TIA

Zane

Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #1 on: January 08, 2012, 02:39:40 PM »

Does your IntraWeb Server have access to the secure network which your WDMC DLL is trying to access? For example, if you start your GUI EXE (which is using the WDMC DLL) on the same PC where your IntraWeb Server is running, does the GUI EXE connect to the RTC Servers and displays all the info?
Logged
zsleo
RTC Expired
*
Posts: 80


« Reply #2 on: January 08, 2012, 09:52:50 PM »

Yes. They are all inside the same network segment.

Even when running the Intraweb / WDMC DLL app and a few EXE on the same computer I cannot get a RTC client to RTC server connect.

Yes, when running the GUI EXE / WDMC DLL every connection attempt is successful.



Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #3 on: January 08, 2012, 11:48:42 PM »

Ok, so the WDMC DLL works from the GUI EXE, but it doesn't work from your IntraWeb app - even when the GUI EXE and the IntraWeb app are running on the same PC.

In your IntraWeb app ...

1) How are you handling multi-threaded access to RTC components? Are you (A) using only remote functions and have set the "HyperThreading" property on the TRtcClientModule component to TRUE, or are you (B) creating and destroying RTC components "on-the-fly", or do you (C) have a pool of DataModules with all required RTC components so you can take one set of RTC components out when you need them and put them back in afterwards, or (D) some other way?

2) Unless your IntraWeb app has an active message loop running inside the main thread (required for asynchronous WinSock to work), you will need to use blocking sockets ("Blocking=TRUE" on the TRtcHttpClient component). Since your Client shouldn't be behind a proxy (you've said they are all insidet the same secure network), the "useProxy" property should be set to FALSE.
 
Best Regards,
Danijel Tkalcec
Logged
zsleo
RTC Expired
*
Posts: 80


« Reply #4 on: January 09, 2012, 08:17:39 AM »

There are RTC components in the Intraweb App.

All RTC components re in the DLL. Calls from Intraweb to DLL are via std function / procedure calls to the DLL returning string results (your option A).

All DLL RTC calls are in blocking mode.

The DLL app has Tform that is the parent for all the RTC components.

At this time I am implementing (in the DLL) creating the RTC Client components on the fly (your option B) but I think I am going to run into problems with this when DLL is loaded from the Intraweb app because (if I am correct) the DLL will inherit the Intraweb application handle as DLL application handle - which is were (6 months+ ago) I ran into problems and failed. See my post of 15 July 2011 - I never did get that working.
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #5 on: January 09, 2012, 11:58:42 AM »

1) You should NOT use a TForm in non-windowed applications (like a Windows Service). Use TDataModule instead.
 
2) Provided you can guarantee that each thread will have its own set of RTC components (you are NOT using the same RTC components from more than one thread at a time), the following property settings should work ...

For TRtcHttpClient components:
AutoConnect:=True;
Blocking:=True;
MultiThreaded:=False;
UseProxy:=False;
UseSSL:=False;
UseWinHttp:=False;

For TRtcClientModule and TRtcDataRequest components:
AutoSyncEvents:=False;
HyperThreading:=False;

Please let me know if using these property settings solves your problem.

To make sure that RTC components are NOT being used from more than one thread at a time, you can either (A) create all RTC components "on-the-fly" from each function using them, or (B) use a single set of RTC components per RTC Server, but enclose all functions using RTC components inside critical sections to ensure that only one thread will be using them at a time, or (C) use a pool of RTC components / DataModules which will dinamically grow as needed and guarantee that there are enough RTC components for all active thread.

Creating components "on-the-fly" (option A) is the "quick and dirty" solution, which results in the slowest code execution and highest memory requirements because there will be a lot of object allocations/deallications and connections will need to be opened and closed for every single call.

Using a single set of RTC Client components per RTC Server and enclosing all function calls inside critical section is a good alternative to creating components "on-the-fly" in case each call will usually return quickly so there won't be long "waiting queues", but it isn't a good solution if you have longer running requests.

Using a pool of components/DataModule has the best of both solutions, because it will create new components if all the components from the pool are already in use, so there are no waiting queues, while at the same time avoiding constant allocations/deallocations and connects/disconnects (no need to connect and disconnect for every request will get you the response faster).

By the way ...

Unless I misunderstood something, your topic from July 15th was about using RTC Server code together with IntraWeb Server code in a single Application, which is something completely different than using RTC Client components from the IntraWeb Server.

The problem there (in your topic from July 15th) was that you can NOT have two TCP/IP Server sockets listening on the same Port at the same time, which is why you can't simply compile RTC Server code and IntraWeb Server code into a single Application - if you expect both of them to be accessible through the same TCP/IP Port. Using RTC Client components from a DLL imported by a Windows Service is something completely different.

Best Regards,
Danijel Tkalcec
Logged
zsleo
RTC Expired
*
Posts: 80


« Reply #6 on: January 10, 2012, 03:13:33 AM »


I decided to ditch the DLL interface for the Intraweb app.

I implement the RTC client(s) in a "global" TDatamodule within the Intraweb app that periodically updates a record object associated with each worker EXE. The record objects are exposed as read-only to each logged on user of the Intraweb app.

... all working perfectly ...

Thanks for your excellent support - as usual...
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #7 on: January 10, 2012, 01:08:27 PM »

Sounds like a good solution.

PS. Should your shared record object(s) contain periodically updated Strings or similar data types which can change their location in memory during a write operation, I would recommend using a critical section inside all functions accessing these shared record objects (for reading and for writing) to avoid possible Access Violations.

Best Regards,
Danijel Tkalcec
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.026 seconds with 16 queries.