Random timeout errors when using WCF net.tcp binding

Question

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.

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

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.

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.

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.

Thanks

Answer 1

After some testing and monitoring the network, I was able to find out that the problem was more of a network issue with fluctuating connection that caused the TCP channel to break. I am not yet 100% sure of the problem but this has been the most promising conclusion that I could come to. If anyone has any other inputs please feel free to share it so that I can improve my service reliability.

Answer 2

About comparsion. TCP is transport level protocol that provide reliable delivery of data. HTTPS based on tcp and have some data overhead. I see no reason for that is the same for the operation is complete different because of protocol. What type of data you try to send?