title: Best practice for WCF Duplex client
body: <p>I can't deny the performance benefit of a duplex async call, but some things about makes me feel wary.</p>
  
  <p>My concern is that given a client object instantiated, will WCF be able to tell which particular client service instance will receive the callback argument?</p>
  
  <p>Can anyone tell me if this is a good idea? If not why not?</p>
  
  <pre><code>new DuplexChannelFactory&lt;IServerWithCallback&gt;(
     new ClientService(), 
     new NetTcpBinding(), 
     new EndpointAddress("net.tcp://localhost:1234/"+Guid.NewGuid()))
  </code></pre>
  
  <ol>
  <li><p>If the virtual path above is reserved how can it be discarded. I want the client service lifetime to be fairly short. IE make a request and receive a response and when done receiving, kill it. How bad is the performance penalty in making the client service lifetime short as opposed to pooling it and keeping it alive longer.</p>
  
  <p>The idea is to avoid timeout issue. When done receiving, sending, dispose ASAP. By convention - can't pass the client services around. If you need info, create a new one, simple - just like EF/L2S etc.</p></li>
  <li><p>From inside the WCF service itself, how do I kill the session with the client. ie. I don't want the client ending the session - I know I can decorate my operation accordingly, but I want the service to terminate itself programmatically when certain conditions are met. </p></li>
  <li><p>I can affix the port and forward accordingly to resolve any firewall issue, but what I'm worried about is if the client were to sit behind a load-balancer. How would the service know which particular server to call?</p></li>
  </ol>