title: Random timeout errors when using WCF net.tcp binding
body: <p>To give a general overview - I have a WCF service with multiple bindings. One is a HTTPS binding and the other a net.tcp. The service is hosted on a IIS. The HTTPS binding seems to be working fine, but I have random timeout errors with the TCP binding. </p>
  
  <p>This request operation sent to XXX did not receive a reply within the configured timeout (00:05:00).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client</p>
  
  <p>I can clearly see the issue is a timeout problem,but it doesnt happen always. The only thing that baffles me is that none of my operations take as long as 5:00 minutes to complete. I can actually see the result that I want to see on my screen which makes me assume my process is over. But then I get this timeout when i start the next process, which is when i realize that my "service is in a fulted state" and going back i find this error. </p>
  
  <p>Can someone give me an idea of what is happening? I assume the error is something to do with the way the TCP protocol works because i do not find this in HTTPS. Nither does the same call to the service always produce this error. It is very random.</p>
  
  <p>I used TCP to gain a performance boost with the binary encoded XML formatting, but all these random issues I question if I am really gaining any advantage. HTTPS seems to be almost a second slower in all my calls on average and that would be considered a good gain in terms of performance of TCP but with problems like these is it really worth going the TCP route? Some comparison of the two protocols would also be a good insight for me. </p>
  
  <p>Thanks</p>