Gets or sets the interval of time that a connection can remain inactive, during which no application messages are received, before it is dropped.
Assemblies: System.ServiceModel (in System.ServiceModel.dll)
System.ServiceModel.Primitives (in System.ServiceModel.Primitives.dll)
abstract ReceiveTimeout : TimeSpan with get, set override ReceiveTimeout : TimeSpan with get, set
Property ValueType: System.TimeSpan
The Timespan that specifies how long the application has to receive a message before timing out. The default value is 10 minute.
When using a reliable session, there are two different inactivity timers that must be satisfied to keep the connection alive. If either of these inactivity timers goes off, then the connection is dropped.
The first inactivity timer is on the reliable session and is called the 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 setting of the binding. This inactivity timer fires if no application messages are received within the timeout period. This specifies, for example, the maximum time a client may take to send at least one message to the server before the server will close the channel used by a session. This behavior ensures that clients cannot hold on to server resources for arbitrary long periods.
Since the connection is dropped if either inactivity timer fires, increasing InactivityTimeout once it is greater than has no effect. The default for both of these timeouts is 10 minutes, so you always have to increase both of them to make a difference when using a reliable session.
If transaction flow is enabled on the binding or the channel, the operation may take longer to execute than the specified timeout. In these circumstances the operation fails due to the expired timeout and the transaction aborts appropriately.
When security is used with sessions, the value set on the binding is also used as the session timeout.