views:

212

answers:

2

Hello,

I have a simple ASP.NET web app which uses a WCF Client to talk to a simple WCF backed Windows Service.

All worked fine in local environments. We deployed to dev, which also worked fine. However on DEV - the Web server and App server are on the same machine.

Now that we have deployed to QA, we get the 'The socket connection was aborted. ' exception thrown immedately. For some reason, our QA Web server cannot talk to our QA app server via our WCF client/service. I can ping the QA app server from the web server I can telnet the QA app server from the web server I can connect to the HTTP WSDL on the QA app server from the web server

AND, I can connect FINE to my QA service from my LOCAL environment / visual studio !!!

So why can't my QA ASP.NET app talk to my QA WCF Windows service? I have tried and in every way possible, and still no go...

Here is my System.ServiceModel section on client:

<system.serviceModel>
    <bindings>
      <netTcpBinding>
        <binding name="BigFileBinding">
          <!-- required to receive files greater then default size of 16kb -->
          <readerQuotas maxArrayLength="5242880"/>
        </binding>
      </netTcpBinding>
    </bindings>
    <client>
      <endpoint address="net.tcp://NJQACNET01:58887/PriceService"
          binding="netTcpBinding"
          contract="IPriceService"
          bindingConfiguration="BigFileBinding"/>
      </endpoint>
    </client>
  </system.serviceModel>

Here is my system.servicemodel section on the service:

<system.serviceModel>
    <bindings>
      <netTcpBinding>
        <!-- required to receive files greater then default size of 16kb -->
        <binding name="BigFileBinding"
                 maxReceivedMessageSize="5242880">
          <readerQuotas maxArrayLength="5242880"/>
        </binding>
      </netTcpBinding>
    </bindings>
    <services>
      <service behaviorConfiguration="MetaDataBehavior" name="RK.Pricing.PricingPortal.MarketableSecuritiesService.PriceService">
        <endpoint address="net.tcp://localhost:58887/PriceService" binding="netTcpBinding"
          contract="RK.Pricing.PricingPortal.MarketableSecuritiesService.IPriceService" bindingConfiguration="BigFileBinding"   />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"  />
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:58889/PriceService" />
          </baseAddresses>
        </host>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MetaDataBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Thank you very much for any help! It is greatly appreciated..

+1  A: 

This is probably a firewall problem, the port you are using is blocked between the ASP.Net QA server ans the WCF QA Server.

You can test this using the telnet command.

Shiraz Bhaiji
dferraro
The cost would be that any client could call your service. Turning security off is definitely not recommended. Check out the guidelines that I linked to in my answer.
Ray Vernagus
@dferraro, what were your security settings before you changed them to none? Is the ASP.net server in the same domain? Which user context is the call from the ASP.Net server to the WCF server made in?
Shiraz Bhaiji
@Ray, this is an application that is freely available on our internal intranet to anyone who has windows authentication access on our site. Therefore I don't believe having 'none' as security mode is any issue if that is the only drawback - as anyone on our network can just go to the website and submit and jobs they'd like anyway...
dferraro
@Shiraz, I had no security settings set, so whatever the default is I suppose. I will look into this further as I get more time - I believe this is a TCP / windows auth issue, as stated below by Ray
dferraro
@dferraro - Just to be clear, setting SecurityMode to None makes it possible for *unauthenticated* clients to call the service, in other words, there is no authentication performed whatsoever against the caller. Your website may require authentication but if someone got a hold of your service endpoint information they could call it directly without authenticating through your web app.
Ray Vernagus
+1  A: 

I think this is likely a security problem. Keep in mind that by default, NetTcpBinding use Windows authentication.

You should review and follow the guidelines published here if possible.

Ray Vernagus