none
Detecting "Keep Alive" Failures RRS feed

  • Question

  • So if I correctly understand this thread of discussion:

    http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/7fb25e30-fc74-4a52-9dfd-232c67c84f7a

    ...most all the bindings in WCF (including http*) send TCP "keep alive" messages as needed for high latency connections, but if the connection does fail (e.g. client unplugged from power) there is no mechanism for detecting this connection failure during a high-latency WCF service call?

    That seems like a surprising limitation.  Can we expect MS will provide the functionality soon?  Has it already been provided in the latest .net service pack? 

    I would personally be thrilled if MS merely exposed an "IsConnected" property or callback on IReplyChannel objects.


    -Brent Arias
    Tuesday, April 14, 2009 9:59 PM

Answers

  • -> That seems like a surprising limitation.

    Well, I think it's reasonable, in particular WCF is a general-purpose communication framework, and since the TCP Keep-alive mechanism is a controversial feature, and is not recommended to be turned on by default, quoted from the RFC 1122 TCP spec for reference:

    4.2.3.6  TCP Keep-Alives

                Implementors MAY include "keep-alives" in their TCP
                implementations, although this practice is not universally
                accepted.  If keep-alives are included, the application MUST
                be able to turn them on or off for each TCP connection, and
                they MUST default to off.

                Keep-alive packets MUST only be sent when no data or
                acknowledgement packets have been received for the
                connection within an interval.  This interval MUST be
                configurable and MUST default to no less than two hours.

                It is extremely important to remember that ACK segments that
                contain no data are not reliably transmitted by TCP.
                Consequently, if a keep-alive mechanism is implemented it
                MUST NOT interpret failure to respond to any specific probe
                as a dead connection.

    TCP Keep-alive or other keep alive mechanism introduced in other protocols is in my humble opinion is only a mechanism to solve a very small portion of problems/ scenarios (such as the long latency request scenario for instance), and is noisy or causing side effects in most other scenarios, and since WCF is a general purpose framework, and general purpose framework is designed for solving general purpose customer's scenarios, so in my personal understanding, it's not so surprising that WCF doesn't include this feature.

    I think what WCF could be able to provide is a Poll() or Select() type of methods just as what System.Net.Sockets.Socket provide which could help you to write keep alive logic easily, since in WCF, it's not so streightforward to implement Poll() or Select() type of methods which could send empty dummy header-only request, because WCF is heavily layered.

    Hope this makes sense to you.


    Another Paradigm Shift
    http://shevaspace.blogspot.com
    • Marked as answer by Brent Arias Thursday, April 23, 2009 6:04 PM
    Friday, April 17, 2009 6:02 AM

All replies

  • -> That seems like a surprising limitation.

    Well, I think it's reasonable, in particular WCF is a general-purpose communication framework, and since the TCP Keep-alive mechanism is a controversial feature, and is not recommended to be turned on by default, quoted from the RFC 1122 TCP spec for reference:

    4.2.3.6  TCP Keep-Alives

                Implementors MAY include "keep-alives" in their TCP
                implementations, although this practice is not universally
                accepted.  If keep-alives are included, the application MUST
                be able to turn them on or off for each TCP connection, and
                they MUST default to off.

                Keep-alive packets MUST only be sent when no data or
                acknowledgement packets have been received for the
                connection within an interval.  This interval MUST be
                configurable and MUST default to no less than two hours.

                It is extremely important to remember that ACK segments that
                contain no data are not reliably transmitted by TCP.
                Consequently, if a keep-alive mechanism is implemented it
                MUST NOT interpret failure to respond to any specific probe
                as a dead connection.

    TCP Keep-alive or other keep alive mechanism introduced in other protocols is in my humble opinion is only a mechanism to solve a very small portion of problems/ scenarios (such as the long latency request scenario for instance), and is noisy or causing side effects in most other scenarios, and since WCF is a general purpose framework, and general purpose framework is designed for solving general purpose customer's scenarios, so in my personal understanding, it's not so surprising that WCF doesn't include this feature.

    I think what WCF could be able to provide is a Poll() or Select() type of methods just as what System.Net.Sockets.Socket provide which could help you to write keep alive logic easily, since in WCF, it's not so streightforward to implement Poll() or Select() type of methods which could send empty dummy header-only request, because WCF is heavily layered.

    Hope this makes sense to you.


    Another Paradigm Shift
    http://shevaspace.blogspot.com
    • Marked as answer by Brent Arias Thursday, April 23, 2009 6:04 PM
    Friday, April 17, 2009 6:02 AM
  • Thank you for highlighting the TCP RFC on the matter...I was not aware that keep-alives are so restrictive.  All the same, all the WCF bindings that use an underlying TCP protocol do have "keep-alive" turned ON by default, contrary to the TCP RFC.  Very interesting!


    -Brent Arias
    Thursday, April 23, 2009 6:04 PM