D.Tkalcec (RTC)
|
|
« Reply #2 on: December 03, 2010, 10:57:21 AM » |
|
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
|