This article is now a part of the Windows SDK.
The results are in and it looks like I'll be going full steam ahead with the plan to post totally unedited and uncensored prerelease SDK documentation for your trial consumption. I'd like to remind everyone that this is basically straight from my word processor to you, so there may very well be errors grammatical, technical, and otherwise. The formatting may be a little weird because I'm pasting these in from Word and it's HTML tag soup. Today's topic is the mysterious world of transport quotas.
Transport quotas are a policy mechanism for deciding when a connection is consuming excessive resources. A quota is a hard limit that prevents the use of additional resources once the quota value is exceeded. The purpose of transport quotas is to prevent Denial of Service (DOS) attacks, either malicious or unintentional.
Windows Communication Foundation (WCF) transports have default quota values that are based on a conservative allocation of resources. These default quota values should be suitable for development environments and small installation scenarios. Service administrators should review transport quotas and tune individual quota values if an installation is running out of resources or if connections are being limited despite the availability of additional resources.
WCF transports have three types of quotas: timeouts, memory allocation limits, and collection size limits.
· Timeouts are a mitigation of DOS attacks that rely on tying up resources for an extended period of time.
· Memory allocation limits prevent a single connection from exhausting system memory and denying service to other connections.
· Collection size limits bound the consumption of resources that indirectly allocate memory or are in limited supply.
This section describes the transport quotas available for the standard WCF transports: HTTP(S), TCP/IP, and named pipes. Custom transports can expose their own configurable quotas that are not included in this list. You will need to consult the documentation for a custom transport to find out about its quotas.
Maximum time to wait for a connection to close before the transport will raise an exception.
Size in bytes of the transmit and receive buffers of the underlying transport. Increasing this buffer size can improve throughput when sending large messages.
Maximum lifetime of an active pooled connection. After the specified time elapses, the connection will close once the current request is serviced.
This setting only applies to pooled connections.
Maximum time a pooled connection can remain idle before being closed.
Maximum number of unserviced connections that can queue at an endpoint before additional connections are denied.
Maximum amount in bytes of memory that the transport will devote pooling reusable message buffers. When the pool cannot supply a message buffer, a new buffer is allocated for temporary use.
Installations that create many channel factories or listeners can allocate large amounts of memory for buffer pools. Reducing this buffer size can greatly reduce memory usage in this scenario.
Maximum size in bytes of a buffer used for streaming data. If this transport quota is not set or the transport is not using streaming, then the quota value is the same as the smaller of the MaxReceivedMessageSize quota value and Integer.MaxValue.
Maximum number of incoming connections that can be serviced. Increasing this collection size can improve scalability for large installations.
Connection features such as message security can cause a client to open more than one connection. Service administrators should account for these additional connections when setting this quota value.
Connections waiting to complete a transfer operation can occupy a connection slot for an extended period of time. Reducing the timeouts for send and receive operations can free up connection slots quicker by disconnecting slow and idle clients.
Maximum number of outgoing connections that can be associated with a particular endpoint.
Maximum time to wait after a send operation for batching additional messages in a single operation. Messages are sent earlier if the buffer of the underlying transport becomes full. Sending additional messages does not reset the delay period.
Maximum number of channels that the listener can have waiting to be accepted.
There is an interval of time between a channel completing an accept and the next channel beginning to wait to be accepted. Increasing this collection size can prevent clients that connect during this interval from being dropped.
Maximum size in bytes of a received message, including headers, before the transport will raise an exception.
Maximum time to wait for a connection to be established before the transport will raise an exception.
Maximum time to wait for a read operation to complete before the transport will raise an exception.
Maximum time to wait for a write operation to complete before the transport will raise an exception.
The transport quotas MaxInboundConnections and MaxOutboundConnectionsPerEndpoint are combined into a single transport quota called MaxConnections when set through the binding or configuration. Only the binding element allows setting these quota values individually. The MaxConnections transport quota has the same minimum and default values.
Transport quotas are set through the transport binding element, the transport binding, application configuration, or host policy. This document doesn’t cover setting transports through host policy. You will need to consult the documentation for the underlying transport to discover the settings for host policy quotas. The Microsoft Knowledge Base describes quota settings for the Http.sys driver and for TCP/IP networking.
Other types of quotas apply indirectly to transports. The message encoder that the transport uses to transform a message into bytes can have its own quota settings. However, these quotas are independent of the type of transport being used.
Setting transport quotas through the binding element offers the greatest flexibility in controlling the behavior of the transport. The default timeouts for Close, Open, Receive, and Send operations are taken from the binding when a channel is built.
Setting transport quotas through the binding offers a simplified set of quotas to choose from while still giving access to the most common quota values.
1. The MaxBufferSize transport quota is only available on the BasicHttp binding. The WSHttp bindings are for scenarios that do not support streamed transport modes.
2. The transport quotas MaxInboundConnections and MaxOutboundConnectionsPerEndpoint are combined into a single transport quota called MaxConnections.
Application configuration can set the same transport quotas as directly accessing properties on a binding. In configuration files, the name of a transport quota always starts with a lowercase letter. For example, the CloseTimeout property on a binding corresponds to the closeTimeout setting in configuration and the MaxConnections property on a binding corresponds to the maxConnections setting in configuration.
Next time: What Goes In... (IInputChannel)