RTC Forums

Is this a bug..

When running with Client.UseProxy := True and the proxy address entered (Client.UserLogin.ProxyAddr := '192.1.2.123:8080') all works fine.

.. but just changing Client.UseProxy := False does not switch proxy off. I have to set proxy address to null string (Client.UserLogin.ProxyAddr := '') before I can get a non-proxy connection.

The same applies to all the authentication settings...

TIA
Zane

A slight correct/addition ...

For MS ISA proxy server the RTC setting MUST be set absolutely correct for proxy and non-proxy transmission.

For Squid it is not quite so. Is the proxy address it set but use proxy is False then the Squid proxy server processes the transmission. Squid proxy is not used only if use proxy is false AND proxy server address is set to null string...


One other "little" annoying thing: when Proxy server setting are set, upon connection, the connected IP Address returned by RTC is '0.0.0.0' and the connection status is returned as true but I am only connected to the proxy server and NOT the destination server. is it possible for RTC to return both the proxy server connection status and the destination server connection status. I base my "process RTC transaction now" on the connection status and if the destination server is not connected then processing rollback becomes a pain...

Zane

Hi Zane,

1) Setting useProxy:=TRUE and useWinHTTP:=FALSE will force the component to use the WinInet API, regardless of other Proxy parameters. On the other hand, setting the "ProxyAddress" property to anything but an empty string will use the WinHTTP API even if WinHTTP is FALSE. This is NOT a bug, this is how I intended the code to work and it has been that way since the addition of WinHTTP support.

If you do NOT want to use a Proxy, all Proxy properties have to be empty. It is not enough to set useProxy to FALSE. Also note that setting useSSL to TRUE will use either WinInet or WinHTTP APIs, which also normally means going through a Proxy.

2) When using the WinInet or WinHTTP APIs, you do NOT know the real status of a physical connection to the end-Server. These APIs maintain their own internal connection pools in their own discretion and do NOT inform the caller of a connection status or status changes. The only thing you do know is whether a request which you send out has succeeded or failed. And that's also the information RTC SDK passes on to you through its Request/Response events.

3) Also, when using a Proxy, the only place you might find the IP address of the Server is in HTTP headers. You will NOT be able to get the end-Server IP nor Port number by using APIs, because that's not how communication with a Proxy works. This is why the value of the PeerAddr property will always be '0.0.0.0' when you go through a Proxy. Most Proxies use different HTTP header fields to forward different information to connected Clients and Servers, so you should look at the HTTP response headers you get from your Proxy to see what is in there:
TRtcDataClient(Sender).Response[' ... ']

PS. When working with HTTP(S), you should stop thinking in terms of physical connections and start thinking it terms of requests and responses. Depending on proxies, routers and load balancers between your Client and its destination address, each request you send out from your Client can end up at a completely different Server and each request reaching one of your Servers through a single physical connection could be coming from a number of different Clients. There is absolutely NO guarantee of a co-relation between a physical connection and a physical Server or a physical Client when you work with HTTP(s). None.

Best Regards,
Danijel Tkalcec

Thanks Danijel,

A good reminder...

Point 1.: I did forget about this.

Point 3.: I will look at implementing additional feedback info for the user

PS.: I agree, but the users of my application are non-technical; I need to provide a best endeavor at interpreting the status otherwise my support costs increase dramatically.

Regards

Zane