I have a little POC (proof of concept) WCF application whereby I use a
standard netTcpBinding and the code works on computer A, but does not work on
computer B (yes, they are on the same network ... one has IP 39 and the other
40).

My ABC's are: A) net.tcp://machineNameortNumber/BaseAddress/ZZ B)
netTcpBinding C) InterfaceName.



I've excluded the actual numbers and names above in the ABC's, but the
"format" is accurate. The fun part is the exact same code is installed onto
2 different client computers .... 1 can successfully use both TCP & HTTP
bindings to communicate to the WCF Service on the server. The 2nd computer
can only use HTTP ... TCP generates the following error:

"The communication object, System.ServiceModel.Channels.ServiceChannel,
cannot be used for communication because it is in a Faulted state."

Remember the same exact code is being used on both computers. Any ideas???
I've check the firewall ... it's configured the same for both machines. I've
also turned it off (even on the machine that is working correctly) to
eliminiate one possible speed bump.

Thanks for any suggestions on this.
--
Stay Mobile

Thus wrote MobileMan,

> I have a little POC (proof of concept) WCF application whereby I use a
> standard netTcpBinding and the code works on computer A, but does not
> work on computer B (yes, they are on the same network ... one has IP
> 39 and the other 40).
>
> My ABC's are: A) net.tcp://machineNameortNumber/BaseAddress/ZZ B)
> netTcpBinding C) InterfaceName.
>
> I've excluded the actual numbers and names above in the ABC's, but the
> "format" is accurate. The fun part is the exact same code is
> installed onto 2 different client computers .... 1 can successfully
> use both TCP & HTTP bindings to communicate to the WCF Service on the
> server. The 2nd computer can only use HTTP ... TCP generates the
> following error:
>
> "The communication object,
> System.ServiceModel.Channels.ServiceChannel, cannot be used for
> communication because it is in a Faulted state."
>
> Remember the same exact code is being used on both computers. Any
> ideas??? I've check the firewall ... it's configured the same for
> both machines. I've also turned it off (even on the machine that is
> working correctly) to eliminiate one possible speed bump.
>
> Thanks for any suggestions on this.

Just to be sure:

- Your app (client + server) works on A, but once you move either client
or server to another machine, NetTcpBinding breaks?
- And the HTTP binding you use is BasicHttpBinding?

If that's true, it's probably a service authentication failure. Are these
machines running in a domain or a workgroup?

Cheers,

--
Joerg Jooss
news-reply@joergjooss.de

Thanks for the reply Joerg:

If I run both the client and the service on the same computer, then in the
scenario the TCP bindings will work correctly on both workstations. But, the
moment I try to execute the test with the service on my main server (thus
workstations A and B are running the client code, but the Service is now
executing on "computer C") this breaks one of my workstations.

This only happens when using the NetTcpBinding (I'm using the default ... no
additions or modifications to its configuration). The BasicHttpBinding works
correctly at all times, including the test whereby computer B accesses the
service on our server.

None of the computers involved belong to a Windows domain. They all operate
in workgroup mode.

I have ensured all computers have the latest build of the application, and
they're using the same SDK's, .NET 3.0 RTM, etc., etc.

Any thoughts??

Thanks
--
Stay Mobile


"Joerg Jooss" wrote:

> Thus wrote MobileMan,
>
> > I have a little POC (proof of concept) WCF application whereby I use a
> > standard netTcpBinding and the code works on computer A, but does not
> > work on computer B (yes, they are on the same network ... one has IP
> > 39 and the other 40).
> >
> > My ABC's are: A) net.tcp://machineNameortNumber/BaseAddress/ZZ B)
> > netTcpBinding C) InterfaceName.
> >
> > I've excluded the actual numbers and names above in the ABC's, but the
> > "format" is accurate. The fun part is the exact same code is
> > installed onto 2 different client computers .... 1 can successfully
> > use both TCP & HTTP bindings to communicate to the WCF Service on the
> > server. The 2nd computer can only use HTTP ... TCP generates the
> > following error:
> >
> > "The communication object,
> > System.ServiceModel.Channels.ServiceChannel, cannot be used for
> > communication because it is in a Faulted state."
> >
> > Remember the same exact code is being used on both computers. Any
> > ideas??? I've check the firewall ... it's configured the same for
> > both machines. I've also turned it off (even on the machine that is
> > working correctly) to eliminiate one possible speed bump.
> >
> > Thanks for any suggestions on this.
>
> Just to be sure:
>
> - Your app (client + server) works on A, but once you move either client
> or server to another machine, NetTcpBinding breaks?
> - And the HTTP binding you use is BasicHttpBinding?
>
> If that's true, it's probably a service authentication failure. Are these
> machines running in a domain or a workgroup?
>
> Cheers,
>
> --
> Joerg Jooss
> news-reply@joergjooss.de
>
>
>

Thus wrote MobileMan,

> Thanks for the reply Joerg:
>
> If I run both the client and the service on the same computer, then in
> the scenario the TCP bindings will work correctly on both
> workstations. But, the moment I try to execute the test with the
> service on my main server (thus workstations A and B are running the
> client code, but the Service is now executing on "computer C") this
> breaks one of my workstations.
>
> This only happens when using the NetTcpBinding (I'm using the default
> ... no additions or modifications to its configuration). The
> BasicHttpBinding works correctly at all times, including the test
> whereby computer B accesses the service on our server.
>
> None of the computers involved belong to a Windows domain. They all
> operate in workgroup mode.
>
> I have ensured all computers have the latest build of the application,
> and they're using the same SDK's, .NET 3.0 RTM, etc., etc.
>
> Any thoughts??

Without a domain, the you lack the necessary Kerberos infrastructure to authenticate
UPNs and SPNs (which is what the default security settings for NetTcpBinding
will use).

Change the service authentication mode from Windows to something else, e.g.
a X.509 certificate, and the client authentication mode to whatever suits
your security requirements (e.g. None, UserName etc.).

Cheers,
--
Joerg Jooss
news-reply@joergjooss.de

I appreicate your thoughts on this. Though, I'm not sure, I don't think
security is the problem in this case. Is there a way I could determine
positively if that's the problem?

My app.config file for both the Service as well as the client does not
specify any TCP-based security settings. It uses the most basic
setup/configuration I think you can have for TCP and still have TCP work
(remember this does work correctly on workstation A ..... just not on
workstation B).

Here is my app.config file on the client computers:

<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BindingHTTP" closeTimeout="00:01:00"
openTimeout="00:01:00"
receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false"
bypassProxyOnLocal="false"
hostNameComparisonMode="StrongWildcard"
maxBufferSize="65536" maxBufferPoolSize="524288"
maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8"
transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32"
maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384"
/>
<security mode="None">
<transport clientCredentialType="None"
proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName"
algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
<netTcpBinding>
<binding name="BindingTCP" />
</netTcpBinding>
</bindings>
<client>
<endpoint address="net.tcp://vm1:1121/BaseAddressSO/SalesOrder"
binding="netTcpBinding" bindingConfiguration="BindingTCP"
contract="ISalesOrder" name="SalesOrderEndPointTCP" />
<endpoint address="http://vm1:1111/BaseAddressSO/SalesOrder"
binding="basicHttpBinding" bindingConfiguration="BindingHTTP"
contract="ISalesOrder" name="SalesOrderEndPointHTTP" />
</client>
</system.serviceModel>

...................................................................................
Here is the app.config for the Service:

<services>
<service behaviorConfiguration="SalesOrderServiceTypeBehaviors"
name="pti.WMServer.WCF.SalesOrderServiceType">
<clear />
<endpoint address="SalesOrder" binding="basicHttpBinding"
name="SalesOrderEndPointHTTP"
contract="pti.WMServer.WCF.ISalesOrder" />
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
<endpoint address="SalesOrder" binding="netTcpBinding"
name="SalesOrderEndPointTCP"
contract="pti.WMServer.WCF.ISalesOrder" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:1111/BaseAddressSO/" />
<add baseAddress="net.tcp://localhost:1121/BaseAddressSO/" />
</baseAddresses>
</host>
</service>
</services>

<behaviors>
<serviceBehaviors>
<behavior name="SalesOrderServiceTypeBehaviors" >
<!-- Add the following element to your service behavior
configuration. -->
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>


As you can see this is very "basic" in its configuration (almost none of the
optional elements have been employed in the configuration).

Again, thanks for your help on this.
--
Stay Mobile


"Joerg Jooss" wrote:

> Thus wrote MobileMan,
>
> > Thanks for the reply Joerg:
> >
> > If I run both the client and the service on the same computer, then in
> > the scenario the TCP bindings will work correctly on both
> > workstations. But, the moment I try to execute the test with the
> > service on my main server (thus workstations A and B are running the
> > client code, but the Service is now executing on "computer C") this
> > breaks one of my workstations.
> >
> > This only happens when using the NetTcpBinding (I'm using the default
> > ... no additions or modifications to its configuration). The
> > BasicHttpBinding works correctly at all times, including the test
> > whereby computer B accesses the service on our server.
> >
> > None of the computers involved belong to a Windows domain. They all
> > operate in workgroup mode.
> >
> > I have ensured all computers have the latest build of the application,
> > and they're using the same SDK's, .NET 3.0 RTM, etc., etc.
> >
> > Any thoughts??
>
> Without a domain, the you lack the necessary Kerberos infrastructure to authenticate
> UPNs and SPNs (which is what the default security settings for NetTcpBinding
> will use).
>
> Change the service authentication mode from Windows to something else, e.g.
> a X.509 certificate, and the client authentication mode to whatever suits
> your security requirements (e.g. None, UserName etc.).
>
> Cheers,
> --
> Joerg Jooss
> news-reply@joergjooss.de
>
>
>

Thus wrote MobileMan,

> I appreicate your thoughts on this. Though, I'm not sure, I don't
> think security is the problem in this case. Is there a way I could
> determine positively if that's the problem?

Sure -- turn security off ;-)

Remember that all bindings except BasicHttpBinding are secure by default,
and many use Windows security by default.

> My app.config file for both the Service as well as the client does not
> specify any TCP-based security settings.

As I said -- it's secure by default.

Reconfigure both service and client to use this NetTcpBinding:

<bindings>
<netTcpBinding>
<binding name="UnsecureNetTcpBinding">
<security mode="None" />
</binding>
</netTcpBinding>
</bindings>

That should work. Of course, this binding configuration is only useful for
playing around and not for a real piece of production software...

Cheers,
--
Joerg Jooss
news-reply@joergjooss.de