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 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 2

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