none
Inconsistent http and nettcp binding, how to fix. RRS feed

  • Question

  • I have looked a bunch over stack overflow and via google, but haven't found anything discussing the arcane configuration for .net services and ip stack selection.

    Basically, I have a service configured as

      <service behaviorConfiguration="MyServiceBehavior"
        name="MyCompany.Service.MyService">
        <endpoint address="MyService" behaviorConfiguration="EndPBehavior" binding="netTcpBinding" bindingConfiguration="NetTcpBinding_Default" contract="MyCompany.Service.IMyService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:15030" />
            <add baseAddress="net.tcp://localhost:15035" />
          </baseAddresses>
        </host>
      </service>

    My problem is when looking using netstat -nab

    I see

     TCP [::]:15030
    Can not obtain ownership information

    and

      TCP 0.0.0.0:15035
    [TestHost.exe]

    So, one of the endpoints binds via ipv4 and one binds using ipv6.

    The ipv4 of course will not respond to a ipv6 request, and the ipv6 bound one ignores ipv4 requests.

    So, how can I get the service to bind such that all ipv4 and ipv6 addresses are listened to, or at least ipv4 is listened to by both?

    The current inconsistent behavior is giving a number of problems on Windows 7 machines. Local traffic is tending to use ipv6 addresses while the routers in use only understand ipv4 so non-local traffic is using ipv4.

    What is more frustrating, some Windows 7 machines work while some don't.  All XP machines work (or XP embedded).

    Any links to sites I may have overlooked explaining how to support both ipv4 and ipv6 would be appreciated. Any magic changes to the configuration snippet so that both ipv6 and ipv4 would be supported by the service would also be greatly appreciated.

    Also, changing all those localhost addresses to 0.0.0.0 results in the exact same behavior.  The http bindings always bind to ipv6.  While the local segment of the network has ipv6, the services must be accessible via other segments, and the routers are all ipv4 routers.  Therefore, I need everything working over ipv4.

    Thursday, February 27, 2014 4:31 PM

Answers

  •  So, how can I get the service to bind such that all ipv4 and ipv6 addresses are listened to, or at least ipv4 is listened to by both?

    Hi B. Lloyd,

    Thanks for your post.

    For the issue, I think you should notice the Peer-to-Peer Programming with WCF.

    You can get its concept from below article.

    http://msdn.microsoft.com/en-us/library/cc297274.aspx

    Being a P2P application, its binding is set to netPeerTcpBinding and the contract for the endpoint is

    set to QuickReturnTraderChat.IQuickReturnTraderChat (following the namespace.interface format).

    the NetPeerTcpBinding:

    <netPeerBinding>
        <binding name="string"
             closeTimeout="TimeSpan"
             openTimeout="TimeSpan" 
             receiveTimeout="TimeSpan"
             sendTimeout="TimeSpan"
             listenIPAddress="String"
              maxBufferPoolSize="integer"
             maxReceiveMessageSize="Integer" 
             port="Integer"
             <security mode="None/Transport/Message/TransportWithMessageCredential">
                <transport credentialType="Certificate/Password" />
            </security>
        </binding>
    </netPeerBinding>
    

    By default, Peer Channel uses all available IPv4/IPv6 addresses to bind to (including link-local/global

    IPv6 addresses). However, if you choose, you can make it listen on specific IP addresses using the

    ListenIPAddress property on binding instance.

    http://blogs.msdn.com/b/peerchan/archive/2007/12/14/getting-started-a-fresh-look-windows-vista-peer-channel.aspx?Redirected=true

    Hope this helps, thanks.

    Best regards!

    Sunday, March 2, 2014 2:58 PM