none
WCF Timeout Settings - sendTimeout Who Wins? RRS feed

  • Question

  • I have not been able to find any official documentation that explains the protocol for WCF settings when there are differences in server and client configuration for the sendTimeout setting. This is the setting of interest to me since it is the setting that dictates the entire lifecycle of the service call (from the client initiating the call, the service receiving it, processing it, sending the response, and finally the client receiving the response.)

    So...Who wins?

    Server - Maybe

    Client - Probably not since that could allow for clients to maliciously tie up the server (DOS)

    Shortest  - Maybe - I have read a few places online that the shortest time wins. Meaning whichever side (client or server has the lowest configured sendTimeout value.) However I cannot find anything official in any Microsoft documentation that addresses this.

    Thursday, March 30, 2017 7:36 PM

All replies

  • >>from the client initiating the call, the service receiving it, processing it, sending the response, and finally the client receiving the response

    For this process, the Client sendTimeout wins. This request is sent from client.

    SendTimeout governs the whole process of sending a message, including receiving a reply message for a request. As you could find, SendTimeout is corresponding to sender. If you send request from client, the client SendTimeout will work no matter which is shorter.

    Sometimes, you may implement callback contract which will make service send request to client, now the sendTimeout in service side will take effect. But, it does not mean it will win. It depends on who meets the limitation first.

    There is no document to indicate this, but I think you could make a test with sendTimeout in both client and service to check the result.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, March 31, 2017 2:27 AM