RTC Forums

Hi Danijel,

Delayed Calls seem to be the best way to implement my idea for a notification system (on Windows) but I'm a little unsure of how to do it.

As an example, I have Client A, Client B and Client C connect to a Server and ask for any new data. 

The frequency of new data for each individual client could range from a few seconds to several minutes or longer, and the time will vary for each client as new data is specific to them (the data is messages). 

The Server is also a database server which the client programs connects to via a different port.

The basic flow is:

1. Each client calls an RTC function on the Server which is a delayed call.
2. At some point, the Server detects that new data is available for a specific client and posts the delayed call.  The function won't return the actual data.  It will just let the client know that there is new data to look for.
3. This bit is unrelated to RTC: the client then calls a stored procedure from the database server and gets its new data.
4. We then go back to step 1 and the loop continues.

So my questions are:

A. Is there an upper limit to how long the delay can be, and is there any downside to having long delay times? 

I'm thinking I'll just have delays of a couple of minutes because it's not a problem if the client gets a response saying there is new data and there isn't (when the stored procedure is executed nothing is updated in the client software unless there really is new data).  I want to get away from polling for data, hence the RTC delayed call solution.  Customers want to be notified the instant there is new data, but doing this using polling with a check time of every 5 seconds floods the network.  People are so impatient these days.  :(

B. Is there some sort of array I should use to keep a list of delayed calls and to respond to the correct one when new data is available for a specific client?

Thanks,

Steve

I forgot to add:

C.  Are there any benefits in using one of these over the other for the purposes of the situation I described: TRtcClient/TRtcServer or TRtcHttpClient/TRtcHttpServer?  I won't be using port 80.

Thanks,

Steve

A. No, but I would NOT recommend waiting longer than a minute, because of proxy servers - which might decide to close idle connections if they do not get a reply within their time limit.

B. Use whatever you want. Just make sure to secure access (with a critical section) to your list/array if your Server is multithreaded and do NOT destroy the delayed call object after posting it, because it will be destroyed by RTC.

C. For what you have described, delayed calls are a good choice.

If you need an example, check the RTC Messenger Client and Server demo.

Best Regards,
Danijel Tkalcec

I'd also recommend that you use some kind of message stack. Delayed calls are sometimes for some time without delayed call object on the server (when they are returning with a message to the client and until the client sends a new delayed call to the server).
I myself use a TDictionary with client Id and a client object, which holds a message queue and the delayed call object, when it's available.
When a message arrives for that client I put the message on the stack and wake the call up if one is waiting. If none is waiting atm. moment, i'm done here.

When I wake up the call or when a new delayed call comes in, it always arrives in the execute method of the function.

the first thing there is checking the message queue. If nothing is there, I create the delayed call. If something is in the queue at index 0 I take it and send it through the call as answer at once.

hope that helps. For me that way it works smoothe

Thanks Danijel.  It took me a while to work it all out but the prototype seems to be working perfectly.

Regards,

Steve

Thanks for the suggestion.  I'm trying it with a dynamic array and it's working great.

= Steve

Just wanted to let you know that the delayed calls are working brilliantly.  I have also used them to allow administrators to send broadcast messages to all users.  Works like a charm.   :)

Thanks for your help and guidance.

= Steve