Datos grandes y streaming

Windows Communication Foundation (WCF) es una infraestructura de comunicaciones basada en XML. Dado que los datos XML normalmente se codifican en el formato de texto estándar definido en la especificación XML 1.0, los desarrolladores y arquitectos de sistemas conectados suelen preocuparse por la superficie de conexión (o el tamaño) de los mensajes enviados a través de la red y la codificación basada en texto de XML plantea desafíos especiales para la transferencia eficaz de datos binarios.

Consideraciones básicas

Para proporcionar información general sobre la siguiente información para WCF, en esta sección se resaltan algunas cuestiones generales y consideraciones sobre las codificaciones, los datos binarios y el streaming que se aplican generalmente a las infraestructuras de sistemas conectados.

Codificación de datos: texto frente a binario

Las preocupaciones del desarrollador expresadas habitualmente incluyen la percepción de que XML tiene una sobrecarga significativa en comparación con los formatos binarios debido a la naturaleza repetitiva de las etiquetas iniciales y las etiquetas finales, que la codificación de valores numéricos se considera significativamente mayor porque se expresan en valores de texto y que los datos binarios no se pueden expresar de forma eficaz porque deben codificarse especialmente para insertar en un formato de texto.

Aunque muchos de estos problemas y similares son válidos, la diferencia real entre los mensajes codificados con texto XML en un entorno de servicios web XML y los mensajes codificados binarios en un entorno heredado de llamada a procedimiento remoto (RPC) suele ser mucho menos significativo que la consideración inicial podría sugerir.

Aunque los mensajes codificados con texto XML son transparentes y "legibles", los mensajes binarios suelen ser bastante oscuros en comparación y difíciles de descodificar sin herramientas. Esta diferencia en la legibilidad lleva a pasar por alto que los mensajes binarios también suelen llevar metadatos insertados en la carga, lo que agrega sobrecarga igual que con los mensajes de texto XML. Esto se aplica específicamente a los formatos binarios que tienen como objetivo proporcionar funcionalidades de invocación dinámica y acoplamiento flexible.

Sin embargo, los formatos binarios suelen llevar dicha información de metadatos descriptiva en un "encabezado", que también declara el diseño de datos para los siguientes registros de datos. A continuación, la carga sigue esta declaración de bloque de metadatos común con una sobrecarga adicional mínima. Por el contrario, XML incluye cada elemento de datos en un elemento o atributo para que los metadatos envolventes se incluyan de forma repetitiva para cada objeto de carga serializada. Como resultado, el tamaño de un único objeto de carga serializada es similar al comparar texto con representaciones binarias, ya que algunos metadatos descriptivos deben expresarse para ambos, pero el formato binario se beneficia de la descripción de metadatos compartidos con cada objeto de carga adicional que se transfiere debido a la menor sobrecarga general.

Aun así, para determinados tipos de datos, como números, podría haber una desventaja de usar representaciones numéricas binarias de tamaño fijo, como un tipo decimal de 128 bits en lugar de texto sin formato, ya que la representación de texto sin formato podría ser varios bytes más pequeños. Los datos de texto también podrían tener ventajas de tamaño por las opciones de codificación de texto XML normalmente más flexibles, mientras que algunos formatos binarios podrían establecerse como valor predeterminado a 16 bits o incluso Unicode de 32 bits, lo cual no se aplica a Binario .NET y Formato XML.

Como resultado, decidir entre texto o binario no es tan fácil como suponer que los mensajes binarios siempre son más pequeños que los mensajes xml-text.

Una ventaja clara de los mensajes de texto XML es que se basan en estándares y ofrecen la opción más amplia de opciones de interoperabilidad y compatibilidad con la plataforma. Para obtener más información, vea la sección "Codificaciones" más adelante en este tema.

Contenido binario

Un área en la que las codificaciones binarias son superiores a las codificaciones basadas en texto en términos del tamaño del mensaje resultante son elementos de datos binarios de gran tamaño, como imágenes, vídeos, clips de sonido o cualquier otra forma de datos binarios opacos que se deben intercambiar entre los servicios y sus consumidores. Para ajustar estos tipos de datos en texto XML, el enfoque común es codificarlos mediante la codificación Base64.

En una cadena codificada con Base64, cada carácter representa 6 bits de los datos originales de 8 bits, que producen una proporción de sobrecarga de codificación de 4:3 para Base64, sin contar caracteres de formato adicionales (retorno de carro/salto de línea) que se agregan normalmente por convención. Aunque la importancia de las diferencias entre codificaciones XML y binarias normalmente depende del escenario, una ganancia de tamaño de más de 33% al transmitir una carga de 500 MB normalmente no es aceptable.

Para evitar esta sobrecarga de codificación, el estándar del Mecanismo de optimización de transmisión de mensajes (MTOM) permite externalizar elementos de datos grandes contenidos en un mensaje y llevarlos con el mensaje como datos binarios sin ninguna codificación especial. Con MTOM, los mensajes se intercambian de forma similar a los mensajes de correo electrónico del Protocolo simple de transferencia de correo (SMTP) con datos adjuntos o contenido incrustado (imágenes y otro contenido incrustado); Los mensajes MTOM se empaquetan como secuencias MIME relacionadas con varias partes y con la parte raíz siendo el mensaje SOAP real.

Un mensaje SOAP MTOM se modifica a partir de su versión sin codificar para que las etiquetas de elemento especiales que hacen referencia a las partes MIME respectivas tienen el lugar de los elementos originales en el mensaje que contenían datos binarios. Como resultado, el mensaje SOAP hace referencia al contenido binario apuntando a las partes MIME enviadas con él, pero de lo contrario simplemente lleva datos de texto XML. Dado que este modelo está estrechamente alineado con el modelo SMTP bien establecido, hay una amplia compatibilidad con herramientas para codificar y descodificar mensajes MTOM en muchas plataformas, lo que hace que sea una opción extremadamente interoperable.

Aun así, al igual que con Base64, MTOM también incluye cierta sobrecarga necesaria para el formato MIME, de modo que las ventajas de usar MTOM solo se ven cuando el tamaño de un elemento de datos binario supera aproximadamente 1 KB. Debido a la sobrecarga, los mensajes codificados con MTOM pueden ser mayores que los mensajes que usan la codificación Base64 para los datos binarios, si la carga binaria permanece por debajo de ese umbral. Para obtener más información, vea la sección "Codificaciones" más adelante en este tema.

Contenido de datos grandes

Superficie de la conexión a parte, la carga útil de 500 MB previamente mencionada también supone un gran desafío local para el servicio y para el cliente. De forma predeterminada, WCF procesa los mensajes en modo almacenado en búfer. Esto significa que todo el contenido de un mensaje está presente en la memoria antes de enviarlo o después de recibirlo. Aunque es una buena estrategia para la mayoría de los escenarios, y es necesario para características de mensajería como firmas digitales y entrega confiable, los mensajes grandes podrían agotar los recursos de un sistema.

La estrategia para tratar con cargas útiles de gran tamaño es usar secuencias. Aunque los mensajes, especialmente los expresados en XML, suelen considerarse paquetes de datos relativamente compactos, un mensaje podría ser de varios gigabytes de tamaño y parecerse a un flujo de datos continuo más que un paquete de datos. Cuando los datos se transfieren en modo de streaming en lugar del modo almacenado en búfer, el remitente hace que el contenido del cuerpo del mensaje esté disponible para el destinatario en forma de secuencia y la infraestructura de mensajes reenvía continuamente los datos del remitente al receptor a medida que esté disponible.

El escenario más común en el que se producen estas transferencias de contenido de datos grandes son las transferencias de objetos de datos binarios que:

• No se puede dividir fácilmente en una secuencia de mensajes.

• Debe entregarse de forma oportuna.

• No están disponibles en su totalidad cuando se inicia la transferencia.

En el caso de los datos que no tienen estas restricciones, normalmente es mejor enviar secuencias de mensajes dentro del ámbito de una sesión que un mensaje grande. Para obtener más información, consulte la sección "Datos de streaming" más adelante en este tema.

Al enviar grandes cantidades de datos, deberá establecer la maxAllowedContentLength configuración de IIS (para obtener más información, vea Configuración de límites de solicitud de IIS) y la maxReceivedMessageSize configuración de enlace (por ejemplo , System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize o MaxReceivedMessageSize). La maxAllowedContentLength propiedad tiene como valor predeterminado 28,6 MB y la maxReceivedMessageSize propiedad tiene como valor predeterminado 64 KB.

Codificaciones

Una codificación define un conjunto de reglas sobre cómo presentar los mensajes en la conexión. Un codificador implementa dicha codificación y es responsable, en el lado del remitente, de convertir un objeto en memoria Message en un flujo de bytes o un búfer de bytes que se puede enviar a través de la red. En el lado receptor, el codificador convierte una secuencia de bytes en un mensaje en memoria.

WCF incluye tres codificadores y le permite escribir y conectar sus propios codificadores, si es necesario.

Cada uno de los enlaces estándar incluye un codificador preconfigurado, en el que los enlaces con el prefijo Net* usan el codificador binario (incluyendo la BinaryMessageEncodingBindingElement clase) mientras que las BasicHttpBinding clases y WSHttpBinding usan el codificador de mensajes de texto (por medio de la TextMessageEncodingBindingElement clase) de forma predeterminada.

Elemento de enlace del codificador	Descripción
TextMessageEncodingBindingElement	El codificador de mensajes de texto es el codificador predeterminado para todos los enlaces basados en HTTP y la elección adecuada para todos los enlaces personalizados en los que la interoperabilidad es la preocupación más alta. Este codificador lee y escribe mensajes de texto SOAP 1.1/SOAP 1.2 estándar sin control especial para los datos binarios. Si la propiedad System.ServiceModel.Channels.MessageVersion de un mensaje se establece en MessageVersion.None, el sobre SOAP se omite de la salida y solo se serializa el contenido del cuerpo del mensaje.
MtomMessageEncodingBindingElement	El codificador de mensajes MTOM es un codificador de texto que gestiona especialmente los datos binarios y no se utiliza de forma predeterminada en ninguno de los enlaces estándar porque es estrictamente una utilidad de optimización caso por caso. Si el mensaje contiene datos binarios que superan un umbral en el que la codificación MTOM produce una ventaja, los datos se externalizan en una parte MIME después del sobre del mensaje. Consulte Habilitación de MTOM más adelante en esta sección.
BinaryMessageEncodingBindingElement	El codificador de mensajes binarios es el codificador predeterminado para los enlaces Net* y la opción adecuada siempre que ambas partes de comunicación se basen en WCF. El codificador de mensajes binarios usa el formato XML binario de .NET, una representación binaria específica de Microsoft para conjuntos de información XML (Infosets) que generalmente produce una superficie menor que la representación XML 1.0 equivalente y codifica los datos binarios como un flujo de bytes.

La codificación de mensajes de texto suele ser la mejor opción para cualquier ruta de comunicación que requiera interoperabilidad, mientras que la codificación de mensajes binarios es la mejor opción para cualquier otra ruta de comunicación. La codificación de mensajes binarios suele producir tamaños de mensaje más pequeños en comparación con el texto de un solo mensaje y tamaños de mensaje progresivamente incluso más pequeños durante la duración de una sesión de comunicación. A diferencia de la codificación de texto, la codificación binaria no tiene que utilizar control especial para los datos binarios, como cuando se utiliza Base64, pero representa los bytes como bytes.

Si la solución no requiere interoperabilidad, pero todavía desea usar el transporte HTTP, puede componer en BinaryMessageEncodingBindingElement un enlace personalizado que use la HttpTransportBindingElement clase para el transporte. Si varios clientes del servicio requieren interoperabilidad, se recomienda exponer puntos de conexión paralelos que cada uno tenga las opciones de transporte y codificación adecuadas para los respectivos clientes habilitados.

Habilitación de MTOM

Cuando la interoperabilidad es un requisito y se deben enviar datos binarios grandes, la codificación de mensajes MTOM es la estrategia de codificación alternativa que se puede habilitar en los enlaces estándar BasicHttpBinding o WSHttpBinding configurando la propiedad respectiva MessageEncoding a Mtom o componiendo MtomMessageEncodingBindingElement en un CustomBinding. En el código de ejemplo siguiente, extraído del ejemplo de codificación MTOM se muestra cómo habilitar MTOM en la configuración.

<system.serviceModel>
     …
    <bindings>
      <wsHttpBinding>
        <binding name="ExampleBinding" messageEncoding="Mtom"/>
      </wsHttpBinding>
    </bindings>
     …
</system.serviceModel>

Como se mencionó anteriormente, la decisión de usar la codificación MTOM depende del volumen de datos que envíe. Además, dado que MTOM está habilitado en el nivel de enlace, habilitar MTOM afecta a todas las operaciones en un punto de conexión determinado.

Dado que el codificador MTOM siempre emite un mensaje MIME/multiparte codificado en MTOM, independientemente de si los datos binarios terminan siendo externalizados, normalmente solo debe habilitar MTOM para los puntos de conexión que intercambian mensajes con más de 1 KB de datos binarios. Además, los contratos de servicio diseñados para su uso con puntos de conexión habilitados para MTOM deben restringirse, siempre que sea posible, a especificar dichas operaciones de transferencia de datos. La funcionalidad de control relacionada debe residir en un contrato independiente. Esta regla "solo MTOM" solo se aplica a los mensajes enviados a través de un punto de conexión habilitado para MTOM; El codificador MTOM también puede descodificar y analizar los mensajes entrantes que no son MTOM.

El uso del codificador MTOM se ajusta a todas las demás características de WCF. Tenga en cuenta que es posible que no sea posible observar esta regla en todos los casos, como cuando se requiere soporte de la sesión.

Modelo de programación

Independientemente de cuál de los tres codificadores integrados que use en la aplicación, la experiencia de programación es idéntica con respecto a la transferencia de datos binarios. La diferencia es la forma en que WCF controla los datos en función de sus tipos de datos.

[DataContract]
class MyData
{
    [DataMember]
    byte[] binaryBuffer;
    [DataMember]
    string someStringData;
}

Al usar MTOM, el contrato de datos anterior se serializa según las reglas siguientes:

• Si binaryBuffer no es null y si individualmente contiene suficientes datos para justificar la sobrecarga de la externalización MTOM (encabezados MIME, etc.) en comparación con la codificación Base64, los datos se externalizan y se envían junto con el mensaje como una parte MIME binaria. Si no se supera el umbral, los datos se codifican como Base64.

• La cadena (y todos los demás tipos que no son binarios) siempre se representan como una cadena dentro del cuerpo del mensaje, independientemente del tamaño.

El efecto en la codificación MTOM es el mismo si usa un contrato de datos explícito, como se muestra en el ejemplo anterior, usa una lista de parámetros en una operación, tiene contratos de datos anidados o transfiere un objeto de contrato de datos dentro de una colección. Las matrices de bytes siempre son candidatas para la optimización y se optimizan si se cumplen los umbrales de optimización.

Nota:

No debería estar utilizando tipos derivados System.IO.Stream dentro de los contratos de datos. Los datos de flujo deben comunicarse mediante el modelo de streaming, que se explica en la siguiente sección "Datos de streaming".

Transmisión por secuencias de datos

Cuando tiene una gran cantidad de datos para transferir, el modo de transferencia de streaming en WCF es una alternativa factible al comportamiento predeterminado de almacenamiento en búfer y procesamiento de mensajes en memoria en su totalidad.

Como se mencionó anteriormente, habilite la transmisión solo para mensajes grandes (con texto o contenido binario) si los datos no se pueden segmentar, si el mensaje debe entregarse de forma oportuna o si los datos aún no están totalmente disponibles cuando se inicia la transferencia.

Restricciones

No se puede usar un número significativo de características de WCF cuando el streaming está habilitado:

• No se pueden realizar firmas digitales para el cuerpo del mensaje porque requieren calcular un hash en todo el contenido del mensaje. Con el streaming, el contenido no está totalmente disponible cuando se construyen y envían los encabezados del mensaje y, por lo tanto, no se puede calcular una firma digital.

• El cifrado depende de las firmas digitales para comprobar que los datos se han reconstruir correctamente.

• Las sesiones confiables deben almacenar en búfer los mensajes enviados en el cliente para volver a entregarlos si se pierde un mensaje en la transferencia y deben contener mensajes en el servicio antes de entregarlos a la implementación del servicio para conservar el orden de los mensajes en caso de que los mensajes se reciban fuera de secuencia.

Debido a estas restricciones funcionales, solo puede usar opciones de seguridad de nivel de transporte para streaming y no puede activar sesiones confiables. El streaming solo está disponible con los siguientes enlaces definidos por el sistema:

• BasicHttpBinding

• NetTcpBinding

• NetNamedPipeBinding

• WebHttpBinding

Dado que los transportes subyacentes de NetTcpBinding y NetNamedPipeBinding tienen soporte inherente para la entrega confiable y sesiones basadas en conexiones, a diferencia de HTTP, en la práctica, estos dos enlaces solo se ven mínimamente afectados por estas restricciones.

El streaming no está disponible con el transporte Message Queuing (MSMQ), por lo que no se puede usar con NetMsmqBinding o la clase MsmqIntegrationBinding. El transporte message Queuing solo admite transferencias de datos almacenadas en búfer con un tamaño de mensaje restringido, mientras que todos los demás transportes no tienen ningún límite práctico de tamaño de mensaje para la gran mayoría de los escenarios.

El streaming tampoco está disponible cuando se usa el transporte Peer Channel, por lo tanto, no está disponible con el NetPeerTcpBinding.

Streaming y sesiones

Es posible que se produzca un comportamiento inesperado al realizar transmisiones de llamadas con un enlace basado en sesión. Todas las llamadas de transmisión se realizan a través de un único canal (el canal de datagrama) que no admite sesiones, aunque el enlace utilizado esté configurado para usarlas. Si varios clientes realizan llamadas de streaming al mismo objeto de servicio a través de un enlace basado en sesión y el modo de simultaneidad del objeto de servicio se establece en único y su modo de contexto de instancia se establece en PerSession, todas las llamadas deben pasar por el canal de datagrama y, por tanto, solo se procesa una llamada a la vez. Uno o más clientes pueden superar el tiempo de espera. Para solucionar este problema, puede establecer el modo de contexto de instancia del objeto de servicio en PerCall o la simultaneidad en Multiple.

Nota:

MaxConcurrentSessions no tiene ningún efecto en este caso porque solo hay una "sesión" disponible.

Habilitación del streaming

Puede habilitar el streaming de las maneras siguientes:

• Enviar y aceptar solicitudes en modo de streaming y aceptar y devolver respuestas en modo almacenado en búfer (StreamedRequest).

• Enviar y aceptar solicitudes en modo almacenado en búfer y aceptar y devolver respuestas en modo transmitido (StreamedResponse).

• Enviar y recibir solicitudes y respuestas en modo transmitido en ambas direcciones. (Streamed).

Puede deshabilitar el streaming estableciendo el modo de transferencia en Buffered, que es la configuración predeterminada en todos los vínculos. En el código siguiente se muestra cómo establecer el modo de transferencia en la configuración.

<system.serviceModel>
     …
    <bindings>
      <basicHttpBinding>
        <binding name="ExampleBinding" transferMode="Streamed"/>
      </basicHttpBinding>
    </bindings>
     …
</system.serviceModel>

Al crear una instancia del enlace en el código, debe establecer la propiedad correspondiente TransferMode del enlace (o el elemento de enlace de transporte si está redactando un enlace personalizado) en uno de los valores mencionados anteriormente.

Puede activar el streaming para solicitudes y respuestas o para ambas direcciones independientemente en cualquier lado de las partes de comunicación sin afectar a la funcionalidad. Sin embargo, siempre debe suponer que el tamaño de los datos transferidos es tan significativo que la habilitación del streaming se justifica en ambos puntos de conexión de un vínculo de comunicación. Para la comunicación multiplataforma en la que uno de los puntos de conexión no se implementa con WCF, la capacidad de usar streaming depende de las funcionalidades de streaming de la plataforma. Otra excepción poco frecuente podría ser un escenario controlado por el consumo de memoria en el que un cliente o servicio debe minimizar su conjunto de trabajo y solo puede permitir tamaños de búfer pequeños.

Habilitar la transmisión de datos asincrónica

Para habilitar el streaming asincrónico, agregue el comportamiento de punto de conexión DispatcherSynchronizationBehavior al host de servicio y establezca la propiedad AsynchronousSendEnabled en true. También hemos agregado la funcionalidad de streaming asincrónico verdadero en el lado de envío. Esto mejora la escalabilidad del servicio en escenarios en los que se transmiten mensajes a varios clientes, algunos de los cuales son lentos en la lectura, posiblemente debido a la congestión de la red o no se leen en absoluto. En estos escenarios, ahora no bloqueamos subprocesos individuales en el servicio por cliente. Esto garantiza que el servicio pueda procesar muchos más clientes, mejorando así la escalabilidad del servicio.

Modelo de programación para transferencias transmitidas por secuencias

El modelo de programación para streaming es sencillo. Para recibir datos transmitidos, especifique un contrato de operación que tenga un único parámetro de entrada tipado. Para devolver datos transmitidos, devuelva una Stream referencia.

[ServiceContract(Namespace="http://Microsoft.ServiceModel.Samples")]
public interface IStreamedService
{
    [OperationContract]
    Stream Echo(Stream data);
    [OperationContract]
    Stream RequestInfo(string query);
    [OperationContract(OneWay=true)]
    void ProvideInfo(Stream data);
}

La operación Echo del ejemplo anterior recibe y devuelve una secuencia y, por tanto, debe usarse en un enlace con Streamed. Para la operación RequestInfo, StreamedResponse es más adecuado, ya que solo devuelve un Stream. La operación unidireccional es más adecuada para StreamedRequest.

Tenga en cuenta que al agregar un segundo parámetro a las siguientes operaciones Echo o ProvideInfo, el modelo de servicio revierte a una estrategia con búfer y utiliza la representación de serialización durante la ejecución de la secuencia. Solo las operaciones con un único parámetro de flujo de entrada son compatibles con el streaming de solicitudes de un extremo a otro.

Esta regla se aplica de forma similar a los contratos de mensajes. Como se muestra en el contrato de mensaje siguiente, puede tener solo un miembro de un único cuerpo en el contrato del mensaje que sea una secuencia. Si desea comunicar la información adicional con la secuencia, esta información debe estar incluida en los encabezados del mensaje. El cuerpo del mensaje está reservado exclusivamente para el contenido del flujo de datos.

[MessageContract]
public class UploadStreamMessage
{
   [MessageHeader]
   public string appRef;
   [MessageBodyMember]
   public Stream data;
}

Las transferencias en streaming finalizan y el mensaje se cierra cuando la transmisión llega al final del archivo (EOF). Cuando se envía un mensaje (devolviendo un valor o invocando una operación), puede pasar FileStream y la infraestructura de WCF extrae como consecuencia todos los datos de esa secuencia hasta que la secuencia se haya leído totalmente y haya alcanzado EOF. Para transferir datos transmitidos desde un origen para el cual no existe ninguna clase derivada preconstruida Stream, construya una clase de este tipo, superponga esa clase sobre su origen de flujo y úsela como argumento o valor devuelto.

Al recibir un mensaje, WCF construye una secuencia sobre el contenido del cuerpo del mensaje codificado en Base64 (o la parte MIME correspondiente si usa MTOM) y la secuencia llega a EOF cuando se ha leído el contenido.

El streaming de nivel de transporte también funciona con cualquier otro tipo de contrato de mensaje (listas de parámetros, argumentos de contrato de datos y contrato de mensaje explícito), pero dado que la serialización y deserialización de dichos mensajes tipados requiere el almacenamiento en búfer por el serializador, no es aconsejable usar dichas variantes de contrato.

Consideraciones de seguridad especiales para datos grandes

Todos los enlaces permiten restringir el tamaño de los mensajes entrantes para evitar ataques por denegación de servicio. Por ejemplo, BasicHttpBinding expone una propiedad System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize que limita el tamaño del mensaje entrante y, por lo tanto, también limita la cantidad máxima de memoria a la que se accede al procesar el mensaje. Esta unidad se establece en bytes con un valor predeterminado de 65 536 bytes.

Una amenaza de seguridad específica del escenario de streaming de datos de gran tamaño provoca una denegación de servicio al provocar que los datos se almacenen en búfer cuando el receptor espera que se transmita. Por ejemplo, WCF siempre almacena en búfer los encabezados SOAP de un mensaje, por lo que un atacante puede construir un mensaje malintencionado grande que consta completamente de encabezados para forzar que los datos se almacenen en búfer. Cuando el streaming está habilitado, MaxReceivedMessageSize puede establecerse en un valor extremadamente grande, ya que el receptor nunca espera que todo el mensaje se almacene en búfer en la memoria a la vez. Si WCF se ve obligado a almacenar en búfer el mensaje, se produce un desbordamiento de memoria.

Por lo tanto, restringir el tamaño máximo del mensaje entrante no es suficiente en este caso. La propiedad MaxBufferSize es necesaria para restringir el búfer de memoria de WCF. Es importante establecerlo en un valor seguro (o mantenerlo en el valor predeterminado) cuando se transmite. Por ejemplo, supongamos que el servicio debe recibir archivos de hasta 4 GB de tamaño y almacenarlos en el disco local. Supongamos también que la memoria está restringida de tal manera que solo puede almacenar en búfer 64 KB de datos a la vez. A continuación, establecería en MaxReceivedMessageSize 4 GB y MaxBufferSize en 64 KB. Asimismo, en su implementación de servicio debe asegurarse de que solo lee de la secuencia entrante en fragmentos de 64 KB y no leer el fragmento siguiente antes de que el anterior se haya escrito en el disco y haya sido descartado de la memoria.

También es importante comprender que esta cuota solo limita el almacenamiento en búfer realizado por WCF y no puede protegerse frente a ningún almacenamiento en búfer que realice en su propio servicio o implementación de cliente. Para obtener más información sobre las consideraciones de seguridad adicionales, consulte Consideraciones de seguridad para datos.

Nota:

La decisión de utilizar transferencias almacenadas en búfer o transmitidas es una decisión local del punto de conexión. En el caso de los transportes HTTP, el modo de transferencia no se propaga a través de una conexión o a servidores proxy y a otros intermediarios. Establecer el modo de transferencia no se refleja en la descripción de la interfaz de servicio. Después de generar un cliente WCF a un servicio, debe editar el archivo de configuración de los servicios pensados para utilizarse con transferencias transmitidas para establecer el modo. En los transportes con canalizaciones con nombre y TCP, el modo de transferencia se propaga como una aserción de directiva.

Consulte también

• Procedimiento para habilitar el streaming