RtcFunction response queueing

[zsleo]

I have another one of those ... situations.

I have one RtcHTTPServer that accepts requests from multiple RtcHTTPClients.

The RtcHTTPServer requests results from a third party application.

The third party application will only accept requests serially and in a single thread and single socket.

Results returned by the third party application are returned serially and via another single thread and single socket.

The returned third party application results are out of sequence to requests.

I need to queue replies to RtcHTTPServer requests and trigger the specific RtcHTTPClients reply upon the result from the third party application.

The RtcHTTPServer request are processed by RtcFunction

My plan is to:
- In RtcFunction.OnExecute
   * Place the RtcFunction into a global queue
   * "post" the request to the third party application
   * use SendMessage to post a "register and block" to a global section to wait for the result to be returned
- on receipt of result in the global section reply the specific SendMessage request.

Questions:

- is there a way to uniquely identifying each RtcFunction call
- is there a better methodology than my plan.

TIA

Zane

[D.Tkalcec (RTC)]

Provided your Servers only job is to forward requests to another Server, and the 3rd-party Server you are talking to can only work with a single connection at a time, the easiest solution, or option (A) would be to set MultiThreaded=False on your TRtcHttpServer component and use a single TRtcHttpClient component with MultiThreaded=False and Blocking=True. Doing this would mean that your Server would be processing a single request at a time, in blocking mode. This is the "quick and ditry" solution.

Other options that come to mind now are (B) the use of a critical section inside a remote function to serialize access to a TRtcHttpClient component instead of using a Server with MultiThreaded=False, or (C) use of RTC delayed calls to keep a connection idle while waiting for a response from the 3rd-party Server, then waking the remote call up and preparing a result once the response arrives, or (D) use of a TRtcHttpRouter component to manually handle all communication between your incoming Clients, your Server and the 3rd-party Server.

Best Regards,
Danijel Tkalcec

[zsleo]

Danijel thanks for the response.  

I cannot use solution A Server recommendation  but the Client will be as described.  

 Solution B will be possible but once the Server Function calls the 3rd parry app the Server Function "looses" control and must block ant wait for it's reply from 3rd party app -hence the queue. But option C is the one I use in the prototyping I will start today.  

I forgot about "delayed" calls.

What I am still unsure of is how I will identify the correct "delayed" call to release - hence my question about unique id for each Client's Function request but this may be reveal in use of "delayed" calls.

  I will post result results  - when I get there.

  Regards

  Zane

[D.Tkalcec (RTC)]

If you use a single-threaded Server and a single-threaded blocking client, as described in option A, then there is no need for a special "queue", because serialization is implied by that design.

If you use option C, you either need to send some identification from the Client to the Server (for example, a GUID), or generate some unique number for each request on the Server side.

Best Regards,
Danijel Tkalcec