다음을 통해 공유


Session Lifetime on the Server

Why doesn't increasing the InactivityTimeout of a reliable session keep client connections alive for longer?

When using a reliable session, there are two different inactivity timers that must be satisfied to keep the connection alive. If either inactivity timer goes off, then the connection is killed.

The first inactivity timer is on the reliable session and is called InactivityTimeout. This inactivity timer fires if no messages, either application or infrastructure, are received within the timeout period. An infrastructure message is a message that is generated for the purpose of one of the protocols in the channel stack, such as a keep alive or an acknowledgment, rather than containing application data.

The second inactivity timer is on the service and uses the ReceiveTimeout setting of the binding. This inactivity timer fires if no application messages are received within the timeout period.

Since the connection is killed if either inactivity timer fires, increasing InactivityTimeout once it is greater than ReceiveTimeout has no effect. The default for both of these timeouts is 10 minutes, so you always have to increase ReceiveTimeout first to make a difference.

Next time: Glossary Updates

Comments

  • Anonymous
    June 26, 2007
    A ChannelFactory is a local client endpoint that can stamp out proxy instances for a remote service endpoint.

  • Anonymous
    June 27, 2007
    Temps near 100 F and 100% humidity make for some pretty uncomfortable days Windows Workflow Sometimes

  • Anonymous
    December 11, 2007
    Temps near 100 F and 100% humidity make for some pretty uncomfortable days Windows Workflow Sometimes

  • Anonymous
    December 02, 2008
    Temps near 100 F and 100% humidity make for some pretty uncomfortable days Windows Workflow Sometimes you have to go beyond the two root models of WF which are Sequential and State. We needed to and ended up using a hybrid of rules driven and state. Matt