System.ServiceModel 4.0.0.0 System.Enum

indigo1 transports support two modes of transferring messages in each direction:

Buffered transfers hold the entire message in a memory buffer until the transfer is complete.

Streamed transfers only buffer the message headers and expose the message body as a stream, from which smaller portions can be read at a time.

Setting the transfer mode to enables streaming communication in both directions. Setting the transfer mode to or enables streaming communication only in the indicated direction.

Streamed transfers can improve the scalability of a service by eliminating the need for large memory buffers. Whether changing the transfer mode actually improves scalability in practice depends on the size of the messages being transferred. Improvements in scalability should be most evident when large messages use streamed instead of buffered transfers.

By default, the HTTP, TCP/IP and named pipe transports use buffered message transfers. You can set the values of on the , , system-provided bindings using the transfer mode properties exposed on them. The mode can be set on the , for example, by using the property. It can also be set in the configuration section for the binding.

For bindings that do not expose the transfer mode property, the transfer mode can be set on the binding element of the transport and this element can then be added to a custom binding. For example, create an and use the property to set the transfer mode when creating a custom binding. The transfer mode can also be set in the configuration section for the custom binding.

The decision to use either buffered or streamed transfers is a local decision of the endpoint for HTTP transports. For HTTP transports, the transfer mode does not propagate across a connection, or to proxy servers or other intermediaries. Setting the transfer mode is not reflected in the description of the service contract. After generating a proxy to a service, you can (it is allowed but not required) edit the configuration file for services intended to be used with streamed transfers to set the transfer mode. For TCP and named pipe transports, the transfer mode is propagated as a policy assertion.

Using the transfer mode causes the indigo2 runtime to enforce some restrictions.

Operations that occur across a streamed transport can have a contract with at most one input and/or one output parameter at the programming model layer. That parameter corresponds to the entire body of the message and must be a , be a subtype of , or implement the interface. Having a return value for an operation is equivalent to having an output parameter.

Some indigo2 features such as Reliable Messaging and SOAP message-level security rely on buffering messages for transmissions. Using these features may reduce or eliminate the performance benefits gained by using streaming. To secure a streamed transport, use transport level security only or use mixed-mode security, which combines WS-Security claims with transport security.

SOAP headers are always buffered, even when the transfer mode is set to . The headers for a message must not exceed the size of the MaxBufferSize transport quota which is exposed on the various bindings and binding elements.

Changing the transfer mode from to also changes the native channel shape of the TCP and named pipe transports. For buffered transfers, the native channel shape is . For streamed transfers, the native channels are and . A consequence of this is that sessionful service contracts cannot be used with transport streaming.

Indicates whether a channel uses streamed or buffered modes for the transfer of request and response messages.

- Field
  4.0.0.0
  System.ServiceModel.TransferMode

  The request and response messages are both buffered.

- Field
  4.0.0.0
  System.ServiceModel.TransferMode

  The request and response messages are both streamed.

- Field
  4.0.0.0
  System.ServiceModel.TransferMode

  The request message is streamed and the response message is buffered.

- Field
  4.0.0.0
  System.ServiceModel.TransferMode

  The request message is buffered and the response message is streamed.