Unable to establish a TCP connection in Surface RT, if LAN proxy is enabled. RRS feed

  • Question

  • I am using Windows Surface RT device for my development work.
    Here, I am using FTP scan for receiving a  files from a scanner.
    During scanning process, if LAN proxy is enabled, all the scanned JPEG files are not receiving.
    After receiving some files(5th file), the TCP connection is closing (Here we are creating new TCP data connection for each JPEG file). If we disable the proxy, it is working fine.
    This issue is not happening in Windows 8.1 PC. It is happening only in Surface RT device.
    Could you please help me regarding this?

    Thanks in advance,


    Monday, September 1, 2014 9:37 AM

All replies

  • Hi Hari,

    Could I understand your question like: here is an app that we can do something by socket, but if the Lan proxy is enabled. Here we have a documentation: StreamSocket class, inside there are some explanation for using proxy:

    Support for proxies

    In a Windows Store app, the StreamSocket class supports connecting to a remote endpoint when proxies are required to complete the connection. This support for proxies is automatic and transparent to the app. A  StreamSocket can establish a connection through authenticating proxies as well as through other proxies where authentication is not needed. Authenticating proxies  only work if Internet Explorer or an app that uses the HttpClient class in the Windows.Web.Http namespace has previously successfully authenticated with the proxy and the credentials previously used for the authentication are still valid. The support for authenticating proxies does not work if a web browser other than Internet Explorer was used to provide the authentication credentials to the proxy. Connecting through proxies is not supported if a local host address or a specific network adapter is specified on the ConnectAsync method.

    In a Windows Store app, the ConnectAsync methods on the  StreamSocket object try to discover proxies and the current proxy configuration both before and after name resolution to help speed up connection establishment. If a port is specified for the endpoint rather than a service name, both proxy discovery and name resolution are initiated internally. If proxy discovery  completes before name resolution and the CanConnectDirectly property on the ProxyConfiguration object is false, then a proxy connection will be attempted. Once name resolution completes, proxy discovery is initiated again with the resolved endpoint address to determine the current proxy configuration.  If CanConnectDirectly indicates after name resolution that the app can connect directly to the remote endpoint, then a socket connection will be attempted directly to the endpoint. If CanConnectDirectly is false after name resolution, then a socket connection will be attempted directly to the endpoint and a parallel socket connection is attempted through the proxy. The first connection to succeed is used by the StreamSocket and the other connection is canceled.

    There may be cases where CanConnectDirectly returns false, yet it does not mean you cannot access the resource directly. A local network could be configured to have support for both a proxy and network address translation (NAT). The WPAD script used to supply proxy information to a web browser or HttpClient tells Windows that it should use the proxy. This can cause problems when the remote endpoint is not expecting a proxy connection (an HTTP CONNECT request, for example). An app can use the  GetProxyConfigurationAsync method  on the NetworkInformation object passing the remote endpoint and port for the uri parameter to retrieve proxy information to help determine when this condition is suspected. A way to avoid proxy connection requests from being sent when a server can only handle direct connections is to use the ConnectAsync(HostName, String, SocketProtectionLevel, NetworkAdapter) method, since the proxy-related logic is disabled when a specific network adapter is selected.


    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Tuesday, September 2, 2014 8:12 AM
  • Do you see any errors when it fails to receive the 5th file?
    Tuesday, September 2, 2014 4:31 PM