views:

678

answers:

2

We have a WCF service with multiple clients to schedule operations amongst clients. It worked great on XP. Moving to win7, I can only connect a client to the server on the same machine. At this point, I'm thinking it's something to do with IPv6, but I'm stumped as to how to proceed.

Client trying to connect to a remote server gives the following exception:

System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://10.7.11.14:18297/zetec/Service/SchedulerService/Scheduler. The connection attempt lasted for a time span of 00:00:21.0042014. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.7.11.14:18297. ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.7.11.14:18297

The service is configured like so:

<system.serviceModel>
  <services>
     <service
         name="SchedulerService"
         behaviorConfiguration="SchedulerServiceBehavior">
        <host>
           <baseAddresses>
              <add baseAddress="net.tcp://localhost/zetec/Service/SchedulerService"/>
           </baseAddresses>
        </host>
        <endpoint address="net.tcp://localhost:18297/zetec/Service/SchedulerService/Scheduler"
                  binding="netTcpBinding"
                  bindingConfiguration = "ConfigBindingNetTcp"
                  contract="IScheduler" />
        <endpoint address="net.tcp://localhost:18297/zetec/Service/SchedulerService/Scheduler"
                  binding="netTcpBinding"
                  bindingConfiguration = "ConfigBindingNetTcp"
                  contract="IProcessingNodeControl" />
     </service>
  </services>
  <bindings>
     <netTcpBinding>
        <binding name = "ConfigBindingNetTcp" portSharingEnabled="True">
           <security mode="None"/>
        </binding>
     </netTcpBinding >
  </bindings>

  <behaviors>
     <serviceBehaviors>
        <behavior name="SchedulerServiceBehavior">
           <serviceDebug includeExceptionDetailInFaults="true" />
           <serviceThrottling maxConcurrentSessions="100"/>
        </behavior>
     </serviceBehaviors>
  </behaviors>
</system.serviceModel>

The client connects like so:

String endPoint = "net.tcp://" + GetIPV4Address(m_SchedulerHostAddress) + ":" + m_SchedulerHostPort.ToString(CultureInfo.InvariantCulture) + "/zetec/Service/SchedulerService/Scheduler";

NetTcpBinding binding = new NetTcpBinding();
binding.Security.Mode = SecurityMode.None;

m_Channel = new DuplexChannelFactory<IProcessingNodeControl>(this, binding, endPoint);
m_IProcessingNodeControl = m_Channel.CreateChannel();

I've checked my firewall about a dozen times, but I guess there could be something I'm missing. Tried disabling windows firewall. I tried changing localhost to my ipv4 address to try to keep away from ipv6, I've tried removing any anti-ipv6 code.

Don't know if it means anything, but:

Microsoft Telnet> open 10.7.11.14 18297
Connecting To 10.7.11.14...Could not open connection to the host, on port 18297: Connect failed

The telnet test unfortunately doesn't seem to be key. I have successfully connected to my service's port from localhost and a remote computer when the service is running, but my client did not work from the remote computer.

Looks like connecting to localhost is not always guaranteed. Desktop (win7/32) works, Laptop (win7/64) doesn't work. Other win7/64 boxes do work though. Perhaps due to multiple nic's on the laptop? Also doesn't explain failures to connect on testers' systems.

I set up two win7 machines with IPv6 fully disabled (using 0xffffffff as in http://support.microsoft.com/kb/929852 ). No help.

+2  A: 

Something doesn't look right about your host base address and then the end point addresses. One has an explicit port reference, the other doesn't. Usually when you use a base address you use a relative URL in the endpoint address.

I can't think why this would be related to IPv6, because none of the error messages mention IPv6 addresses.

Perhaps try again after disabling the net.tcp port sharing option. Without port sharing, you should be able to confim a connection using telnet like you did.

Also, how is your service hosted in Win7? In IIS7 or self hosted in a Windows Service? Hosting it in a Service may require some permissions to be granted to your exe beyond opening ports on your firewall (like you sometimes have to do for hosting a windows service in HTTP in Win XP).

Sorry, I'm in a hurry and can't look up URLs for these.

thanks for the feedback, I'll play with the addresses tomorrow. This is a self-hosted service in an app that the user starts, running as administrator. It lives in the system tray.
Tom
Well, you didn't specifically solve my problem, but changing to relative paths really highlighted the fact that /Scheduler was being used for two different contracts, and that just seemed weird. I changed the second on to /NodeControl and its working on my dev setup! Wonder why it works on XP and not Win7. Thanks!
Tom
Well, deployed to test and things are worse. Neither the Scheduler clients nor the NodeControl clients can connect if the server is not on the localhost.
Tom
A: 

I don't have time to go back and test whether it is a combination of the help I received from ligos or not, but the primary fix appears to be adding SMSvcHost.exe to the exceptions in the Windows Firewall.

Thanks a lot for your help, ligos. I was ready to give up until you replied to my question.

Instructions for adding net.tcp to windows firewall:

  1. Go to Services, find the net.TCP port sharing service, and double click it. Swipe the Path to executable (don’t worry if it’s not all on screen, the swiping action should scroll it over) and copy it (ctrl-c)
  2. Go to your firewall and add a new program to be allowed to communicate through the Windows Firewall. Paste in the path from Services and hit ok.
Tom
My guess is that SMSvsHost.exe is the process that does the magic behind Net.TCP port sharing. Glad it's working for you.