WCF client connection issue

Question

I am using VSTS2008 + C# + .Net 3.5 to develop WCF service hosted in IIS. Then I generate client proxy code automatically by using Add Service Reference function from VSTS 2008.

My question is, suppose I create a client proxy instance, then use this specific instance to call various methods exposed by WCF service at server side. Then, each time I make a method call will it establish a new connection? Or there will be a constant connection between client and server (i.e., the life time of the connection is from creation of the client proxy instance, to the disposal of the client proxy instance)?

I am using basicHttpBinding.

Answer 1

The connection is held until the proxy is disposed.

EDIT

It will keep the TCP connection open, atleast if you use reliable messaging. I base this on, that reliable messaging fails if the TCP connection is lost. See:

http://codeidol.com/csharp/wcf/WCF-Essentials/Reliability/

EDIT 2

I take back the comment about the using statement. See:

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

A little off topic, but we have stopped using the Add Service Reference, instead we use the method describe here:

http://www.dnrtv.com/default.aspx?showNum=103

Note: This only works if you have control over both the client and the server.

Answer 2

The connection will be closed when the underlying channel closes - by default, the BasicHttpBinding sends a connection HTTP header in messages with a Keep-Alive value, which enables clients to establish persistent connections to the services that support them.

This doesn't mean an instance of the service is kept alive, just the connection to the web server, if the web server supports it.

If you want the connection to close after every call then you can turn it off on the server side by defining a custom binding thus

<services> 
 <service>
  <endpoint address=""
        binding="customBinding"
        bindingConfiguration="HttpBinding" 
        contract="IContract" />
 </service>
</services>

<bindings>
 <customBinding>
   <binding name="HttpBinding" keepAliveEnabled="False"/>
 </customBinding>
</bindings>

Connections will close depending on how long your proxy hangs around for, and the generated proxy will reopen it again if it needs to.

Answer 3

George, one thing to consider is that your code should try not to care about how, if, or when, the connection opens or closes. That's primarily the concern of the channel, and the channel should be able to manage the connection as it sees fit, without having to worry that you've written code that depends on how the channel "minds its own business".

Only if you see, or suspect, a performance problem, should you worry about implementation details like this. If you're concerned that there might be such a problem, then create a quick proof of concept application, and watch the network traffic with Fiddler or some other tool. In most cases, that will be a waste of time.

Answer 4

Then, each time I make a method call will it establish a new connection?

Yes, that's the default behavior and the preferred behavior - it saves you a lot of grief!

"This doesn't mean an instance of the service is kept alive" -- what do you you mean "an instance of the service is kept alive"?

In the default and preferred case of a "per-call" services, this is what happens:

• the client proxy issues a call to the service
• the message is serialized on the client side and sent across the wire
• the server side has a "channel listener" which will pick up that message and see which service class will handle the call
• the message dispatcher on your server side will instantiate an instance of "YourServiceClass"
• the message dispatcher on the server side will now call that method on the newly created service class instance, and grab the results and package them up for the respose
• the service class object on the server side is freed
• the response is sent back to your client

That's one of the reasons that your service classes should be as lean, as independent of anything else as possible - they'll typically be instantiated for each request coming in, and freed afterwards.

This may seem like a really bad idea - but if you had service object instances lingering around for a longer time, you'd have to do a lot of bookkeeping in order to track their state and so on, so in the end, it's actually easier (and in general a lot safer and simpler) to create a service class, let it handle the request, and then free it again.

Marc