WCF：通过netTcpBinding通过TransferMode = Streamed将文件传输到服务器时，对客户端的响应延迟

Question

I'm using WCF streamming to transfer file from WCF client to service with netTcpBinding .

Once client makes a call to the service with a Stream instance, the service will start to read from the Stream instance over socket connection ( StreamConnection ). But, if exception happens in the procedure of reading from stream on the service side, the client side can't get the exception immediately.

I found the delay period related to sendTimeout of binding. If I set sendTimeout=20 seconds , the client gets the exception in 20 seconds delay; and if sendTimeout = 1 second , the client gets exception immediately.

I did some research. My understanding is, even when the exception is thrown on the service, it will not throw to client untill the time out of StreamConnection.Read()/StreamConnection.Write() . This time out period looks synchronized with binding sendTimeout.

Is it possible to keep the sendTimeout and let the client get exception immediately?

Here is the service binding, (In order to transfer file with large size, I change the value of maxReceivedMessageSize, sendTimeout and receiveTimeout etc)

  <netTcpBinding>
    <binding  name="StreamingNetTCPBinding" transferMode="Streamed" maxConnections="500" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" sendTimeout="00:45:00" receiveTimeout="23:00:00" listenBacklog="20">
      <readerQuotas maxArrayLength="2147483647" maxDepth="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" maxStringContentLength="2147483647" />
    </binding>
  </netTcpBinding>

Answer 1

The behavior you are seeing is due to the semantics of streamed mode compared with buffered. When using a buffered connection, underneath it's actually a duplex connection, even when using request/reply. A pending receive is always posted to accept incoming requests or replies to any outstanding requests. This is why you can have multiple outstanding requests sent on a single NetTcp connection from multiple threads with a single channel. With streamed mode, when a request is being made, the instance of the call owns the channel until the call has completed. The request stream is sent, and only after it has been sent do we issue a receive/read on the connection. This is because you can't have a reply to a request message if the request message hasn't actually been fully sent, even when the response message is a Fault message.

You have a few options on how to deal with this depending on your requirements, most of which will require a change only in your service code. On the service side, if you have an exception thrown, you need to catch the exception, drain the incoming stream and then re-throw the exception which will cause the Fault message to be returned. As the response stream was completely read, the client has completed all it's sending and is now waiting for the response. This does require the entire request stream to be sent, and in the case of a large request failing early, this may be undesirable. If it's the case that it is undesirable to spend the time/bandwidth to receive the rest of the message, then you could fault the channel (using Abort()) on the service side. This will cause the socket to be disconnected and you will get a CommunicationException on the client side. This has the disadvantage of not receiving information about what went wrong, but will be pretty immediate.

Another option which requires changes on the client and server side is to use two channels and use the second channel to receive OOB info about the status of the request on the first channel.