Poor quality proxy, best response?

[Andrew.W]

Hi Daniel

We have installed our product into a client with a poor proxy server. Every so often it returns 503 (and other) errors, but you retry and it works. Maybe one in 250 requests get rejected.

Is there anything on the RTC client components I can set that will instruct RTC to 'wait 500ms and then retry' if there is an error interacting with the remote server.

Cheers

[D.Tkalcec (RTC)]

I guess you are referring to error codes received from WinInet or WinHTTP API and not HTTP status codes you receive as a response on your HTTP request(s).

If there are problems posting a request (for example, because of proxy issues) and you don't want to immediately repost the request without a delay (using the "AutoRepost" property), you can implement your own method for the "OnRepostCheck" event. For example, if you wanted to wait 500 ms before reposting the request, your OnRepostCheck event could look like this:

procedure TForm1.RtcDataRequest1RepostCheck(Sender: TRtcConnection);
  begin
  Sleep(500);
  TRtcDataClient(Sender).Request.Repost;
  end;

Best Regards,
Danijel Tkalcec

[D.Tkalcec (RTC)]

By the way ... I think that adding a pause after failed connection attempts or proxy problems will reduce your overall response times and could even result in other problems. Every time there is a problem with a proxy, it will become more visible to the client by forcing a delay. You might even get into situations where the same client will be forcing delays upon itself several times in a row because some other client (or more clients) will have more "luck" getting through. By forcing a delay after an error, you are only giving a larger share to those who already have a good share, taking even more away from the one who didn't have the luck to get through.

In other words, I recommend you to NOT force delays between failed request attempts. If a request attempt fails to reach the server, just make another try (as you probably are already doing). Doing that will most likely give you the best overall response times.

Best Regards,
Danijel Tkalcec

[Andrew.W]

Hi Daniel

Our client code doesn't retry!

I was hoping there was something on RTC client component that would take care of this for us, I take it not so?

Andy

[D.Tkalcec (RTC)]

To have requests reposted in case of communication problems (or bad responses when using RTC remote functions), you need to set the AutoRepost property to the number of retries you want to make in case of a problem, or implement the "OnRepostCheck" event and call the "TRtcDataClient(Sender).Request.Repost" method from that event to have the request reposted.

If the "AutoRepost" property of the component you are using to post requests is zero (0) and you have NOT implemented the OnRepostCheck event to mark failed requests for reposting, then there will be no automatic reposting done by the RTC SDK.

Best Regards,
Danijel Tkalcec

[D.Tkalcec (RTC)]

Ah, there's one more thing ...

if you are NOT using RTC remote functions, but are sending and receiving data using the TRtcDataProvider component, you can also mark the last request for reposting from the OnDataReceived event by calling the "Request.Repost" method. This is useful in case you receive a response, but the content received is not what you expect (for example, you get an error response from a proxy instead of the Server you wanted to talk to). For example, adding the following code at the bottom of the "OnDataReceived" event will repost the request in case the status code received is not 200 (OK):

with TRtcDataClient(Sender) do
  begin
  if Response.Done and (Response.StatusCode<>200) then
    Request.Repost;
  end;

I hope that solves your problem. Should you have more questions or problems implementing this, please let me know.

Best Regards,
Danijel Tkalcec

[Andrew.W]

Thanks Daniel, this is exactly what I was hoping for.

OnRepostCheck is only getting called once though. How do I get this event to fire a certain number of times before giving up?

[D.Tkalcec (RTC)]

The "OnRepostCheck" event will be fired after every request that fails. If you repost the request and the request fails again, the event will be fired again - until you stop calling the "Request.Repost" method. You can use the "Request.Reposted" property to check how many times the request has already been reposted.

[Andrew.W]

Hi Daniel

It's without question firing the once for me. Does it depend on some other property or event to fire multiple times?

This is the test I'm doing. I have a proxy set-up between my client and server. I keep switching the proxy server off, but I get error messages quickly. It's only calling the event once.

Code:

procedure TRTCBase.handleCliModRepostCheck(Sender: TRtcConnection);
var
	lsoClient: TRtcDataClient;
begin
	lsoClient := TRtcDataClient(Sender);
	if lsoClient.Request.Reposted < 100 then // a big number just for testing
	begin
		sleep(100); // commenting this out makes no difference
		lsoClient.Request.Repost;
	end;

[D.Tkalcec (RTC)]

AutoRepost is the only property related to the OnRepostCheck event. Unless a request was already reposted automatically by using the AutoRepost property, the OnRepostCheck event will be called once for every request which was fully prepared but not entirely sent. If the OnRepostCheck event is NOT firing, it either means that (A) there is a bug in the code responsible for preparing the request for sending, or (B) a response was received.

If you are using the TRtcDataRequest component, you need to make sure that your code is handling re-posted requests correctly. When you call Request.Repost, events which are called the 1st time when you have posted the request will be called again, but any variables you might have stored inside the Request object or anywhere else will still be there. First event you should take a closer look at is "OnBeginRequest". Make sure you are preparing the request on consecutive calls the same way you are doing it the 1st time around.

If you are using the TRtcClientModule component (which has its own implementation for the OnBeginRequest event) or if you are using the TRtcDataRequest component but you can't find any problems in your own code, please send a sample project which reproduces the issue (using only RTC SDK and standard Delphi components, no third-party code) to:


Best Regards,
Danijel Tkalcec

[D.Tkalcec (RTC)]

Sorry, I forgot about 2 more things which play an important role: TRtcHttpClient's "AutoConnect" and "ReconnectOn" properties.

The "AutoConnect" property is best set to TRUE. This way, the components will try to open a connection only when a request is waiting in a queue. With AutoConnect=FALSE, you always need to open the connection manually by using the CONNECT method.

The "ReconnectOn" property, on the other hand, is responsible for opening a re-opening a connection in case the last connection attempt resulted in an error (ConnectError = wrong address or other API error) or failed (ConnectFail = no listener at address) or was lost (ConnectLost = was probably connected, but then lost connection).

To stay on the safe side, you could set AutoConnect as well as all 3 ReconnectOn parameters to TRUE. As long as AutoConnect is TRUE and you don't repost requests after a certain number of failures, you won't run into endless connection attempt loops.

You could also leave AutoConnect=FALSE, in which case you have to call CONNECT once, but then make sure that only those ReconnectOn properties are TRUE which make sense for you. "ConnectFail" and "ConnectLost" are the ones I would recommend setting to TRUE, since they handle cases where the address is correct but there are other communication problems, while leaving "ConnectError" as FALSE because it would try reconnecting even when the address is wrong.

If the required ReconnectOn property is FALSE ("ReconnectOn.ConnectLost" in this particular case), the request would be placed in the request queue, but it would NOT be sent out unless you would manually call CONNECT to open the connection again.

Only with the ReconnectOn properties set to TRUE and AutoConnect set to TRUE, a connection will be opened automatically if a request was placed in a request queue (again) by using the "Request.Repost" method. As a result, the request would be sent to the Proxy again and a new OnRepostCheck event will be called again if the Proxy is unavailable or unable to handle the request.

I guess that was the missing piece of the puzzle.

If you are still unable to get automated reposting to work, please let me know.

Best Regards,
Danijel Tkalcec

[Andrew.W]

That was it!

It's now retrying on errors. It means I can issue a patch for my customer, and they don't need to wait for the morons who run the proxy to do anything.

Thanks a lot.

[D.Tkalcec (RTC)]

Thank you for your feedback.
I'm glad the problem is now solved.

Best Regards,
Danijel Tkalcec

[Andrew.W]

Hi Daniel

I heard back from the customer today: 'definitely better, not had any problems'.

Overall a great addition to my product.

Cheers

[D.Tkalcec (RTC)]

That's "music to my ears"

Thank you again for your feedback. It is much appreciated.

Best Regards,
Danijel Tkalcec