Dados grandes e streaming

O WCF (Windows Communication Foundation) é uma infraestrutura de comunicação baseada em XML. Como os dados XML geralmente são codificados no formato de texto padrão definido na especificação XML 1.0, os desenvolvedores e arquitetos de sistemas conectados normalmente estão preocupados com o volume de fio (ou tamanho) das mensagens enviadas pela rede e a codificação baseada em texto do XML apresenta desafios especiais para a transferência eficiente de dados binários.

Considerações básicas

Para fornecer informações em segundo plano sobre as informações a seguir para o WCF, esta seção destaca algumas preocupações gerais e considerações sobre codificações, dados binários e streaming que geralmente se aplicam a infraestruturas de sistemas conectados.

Codificação de dados: texto versus binário

As preocupações do desenvolvedor comumente expressas incluem a percepção de que XML tem sobrecarga significativa quando comparada a formatos binários devido à natureza repetitiva de marcas de início e marcas de fim, que a codificação de valores numéricos é considerada significativamente maior porque eles são expressos em valores de texto, e que os dados binários não podem ser expressos com eficiência porque devem ser especialmente codificados para inserção em um formato de texto.

Embora muitas dessas e preocupações semelhantes sejam válidas, a diferença real entre mensagens codificadas em texto XML em um ambiente de serviços Web XML e mensagens codificadas em binário em um ambiente de RPC (chamada de procedimento remoto) herdado é muitas vezes muito menos significativa do que a consideração inicial pode sugerir.

Embora as mensagens codificadas em texto XML sejam transparentes e "legíveis por humanos", as mensagens binárias geralmente são bastante obscuras em comparação e difíceis de decodificar sem ferramentas. Essa diferença na legibilidade leva a ignorar que as mensagens binárias também geralmente carregam metadados embutidos na carga, o que adiciona sobrecarga assim como acontece com mensagens de texto XML. Isso é especificamente verdadeiro para formatos binários que visam fornecer recursos de acoplamento flexível e invocação dinâmica.

No entanto, formatos binários geralmente carregam essas informações de metadados descritivos em um "cabeçalho", que também declara o layout de dados para os seguintes registros de dados. Em seguida, o conteúdo segue essa declaração de bloco de metadados comum com sobrecarga mínima adicional. Por outro lado, o XML inclui cada item de dados em um elemento ou atributo para que os metadados delimitados sejam incluídos repetidamente para cada objeto de conteúdo serializado. Como resultado, o tamanho de um único objeto de conteúdo serializado é semelhante ao comparar texto com representações binárias, pois alguns metadados descritivos devem ser expressos para ambos, mas o formato binário se beneficia da descrição de metadados compartilhados com cada objeto de carga adicional que é transferido devido à menor sobrecarga geral.

Ainda assim, para determinados tipos de dados, como números, pode haver uma desvantagem em usar representações numéricas binárias de tamanho fixo, como um tipo decimal de 128 bits em vez de texto sem formatação, pois a representação de texto sem formatação pode ser várias bytes menores. Os dados de texto também podem ter benefícios de tamanho com as opções geralmente mais flexíveis de codificação de texto XML, enquanto alguns formatos binários podem ter seu padrão definido como Unicode de 16 bits ou mesmo de 32 bits, o que não se aplica ao formato XML binário .NET.

Como resultado, decidir entre texto ou binário não é tão fácil quanto assumir que as mensagens binárias são sempre menores que as mensagens de texto XML.

Uma clara vantagem das mensagens de texto XML é que elas são baseadas em padrões e oferecem a opção mais ampla de opções de interoperabilidade e suporte à plataforma. Para obter mais informações, consulte a seção "Codificações" mais adiante neste tópico.

Conteúdo Binário

Uma área em que as codificações binárias são superiores às codificações baseadas em texto em termos do tamanho da mensagem resultante são grandes itens de dados binários, como imagens, vídeos, clipes de som ou qualquer outra forma de dados binários opacos que devem ser trocados entre serviços e seus consumidores. Para ajustar esses tipos de dados ao texto XML, a abordagem comum é codificá-los usando a codificação Base64.

Em uma cadeia de caracteres codificados em Base64, cada caractere representa 6 bits dos dados originais de 8 bits, o que resulta em uma taxa de sobrecarga de codificação de 4:3 para Base64, sem contar os caracteres adicionais de formatação (retorno de carro/alimentação de linha) que normalmente são adicionados por convenção. Embora a significância das diferenças entre XML e codificações binárias normalmente dependa do cenário, um ganho de tamanho de mais de 33% quando a transmissão de uma carga de 500 MB geralmente não é aceitável.

Para evitar essa sobrecarga de codificação, o padrão MTOM (Mecanismo de Otimização de Transmissão de Mensagens) permite externalizar elementos de dados grandes contidos em uma mensagem e transportá-los com a mensagem como dados binários sem nenhuma codificação especial. Com o MTOM, as mensagens são trocadas de maneira semelhante às mensagens de email SMTP (Simple Mail Transfer Protocol) com anexos ou conteúdo inserido (imagens e outro conteúdo inserido); As mensagens MTOM são empacotadas como sequências MIME de várias partes/relacionadas com a parte raiz sendo a mensagem SOAP real.

Uma mensagem SOAP MTOM é modificada de sua versão não codificada para que marcas de elementos especiais que se referem às respectivas partes MIME assumam o lugar dos elementos originais na mensagem que continha dados binários. Como resultado, a mensagem SOAP refere-se ao conteúdo binário apontando para as partes MIME enviadas com ela, mas, caso contrário, apenas carrega dados de texto XML. Como esse modelo está intimamente alinhado com o modelo SMTP bem estabelecido, há amplo suporte de ferramentas para codificar e decodificar mensagens MTOM em muitas plataformas, o que o torna uma opção extremamente interoperável.

Ainda assim, como no Base64, o MTOM também vem com alguma sobrecarga necessária para o formato MIME, de modo que as vantagens de usar o MTOM só são vistas quando o tamanho de um elemento de dados binário excede cerca de 1 KB. Devido à sobrecarga, as mensagens codificadas em MTOM podem ser maiores do que as mensagens que usam a codificação Base64 para dados binários, se o conteúdo binário permanecer abaixo desse limite. Para obter mais informações, consulte a seção "Codificações" mais adiante neste tópico.

Conteúdo de Dados Grandes

Deixando a superfície eletrônica de lado, a carga de 500 MB mencionada anteriormente também representa um grande desafio local para o serviço e o cliente. Por padrão, o WCF processa mensagens no modo em buffer. Isso significa que todo o conteúdo de uma mensagem está presente na memória antes de ser enviada ou depois de ser recebida. Embora essa seja uma boa estratégia para a maioria dos cenários e necessária para recursos de mensagens, como assinaturas digitais e entrega confiável, mensagens grandes podem esgotar os recursos de um sistema.

A estratégia para lidar com grandes cargas é o streaming. Embora as mensagens, especialmente aquelas expressas em XML, sejam comumente consideradas como pacotes de dados relativamente compactos, uma mensagem pode ter vários gigabytes de tamanho e se assemelhar a um fluxo de dados contínuo mais do que um pacote de dados. Quando os dados são transferidos no modo de streaming em vez do modo em buffer, o remetente disponibiliza o conteúdo do corpo da mensagem para o destinatário na forma de um fluxo e a infraestrutura de mensagem encaminha continuamente os dados do remetente para o receptor à medida que ficam disponíveis.

O cenário mais comum no qual essas transferências de conteúdo de dados grandes ocorrem são transferências de objetos de dados binários que:

• Não pode ser facilmente dividido em uma sequência de mensagens.

• Deve ser entregue em tempo hábil.

• Não estão disponíveis em sua totalidade quando a transferência é iniciada.

Para dados que não têm essas restrições, normalmente é melhor enviar sequências de mensagens dentro do escopo de uma sessão do que uma mensagem grande. Para obter mais informações, consulte a seção "Dados em Streaming" mais adiante neste tópico.

Ao enviar grandes quantidades de dados, você precisará definir a configuração do maxAllowedContentLength IIS (para obter mais informações, consulte Configurando limites de solicitação do IIS) e a maxReceivedMessageSize configuração de associação (por exemplo , System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize ou MaxReceivedMessageSize). A maxAllowedContentLength propriedade usa como padrão 28,6 MB e a maxReceivedMessageSize propriedade usa como padrão 64 KB.

Codificações

Uma codificação define um conjunto de regras sobre como apresentar mensagens no fio. Um codificador implementa essa codificação e é responsável, no lado do remetente, por transformar uma mensagem na memória Message em um fluxo de bytes ou em um buffer de bytes, que pode ser enviado pela rede. No lado do receptor, o codificador transforma uma sequência de bytes em uma mensagem na memória.

O WCF inclui três codificadores e permite que você escreva e conecte seus próprios codificadores, se necessário.

Cada um dos vínculos padrão inclui um codificador pré-configurado, pelo qual os vínculos com o prefixo Net* usam o codificador binário (incluindo a classe BinaryMessageEncodingBindingElement) enquanto as classes BasicHttpBinding e WSHttpBinding usam o codificador de mensagens de texto (por meio da classe TextMessageEncodingBindingElement) por padrão.

Elemento de associação do codificador	Descrição
TextMessageEncodingBindingElement	O codificador de mensagem de texto é o codificador padrão para todas as associações baseadas em HTTP e a opção apropriada para todas as associações personalizadas em que a interoperabilidade é a maior preocupação. Esse codificador lê e grava mensagens de texto SOAP 1.1/SOAP 1.2 padrão sem tratamento especial para dados binários. Se a System.ServiceModel.Channels.MessageVersion propriedade de uma mensagem estiver definida como MessageVersion.None, o wrapper de envelope SOAP será omitido da saída e somente o conteúdo do corpo da mensagem será serializado.
MtomMessageEncodingBindingElement	O codificador de mensagens MTOM é um codificador de texto que implementa o tratamento especial para dados binários e não é usado por padrão em nenhuma das associações padrão porque é estritamente um utilitário de otimização caso a caso. Se a mensagem contiver dados binários que excedem um limite em que a codificação MTOM gera um benefício, os dados são externalizados em uma parte MIME após o envelope da mensagem. Consulte Habilitar o MTOM mais adiante nesta seção.
BinaryMessageEncodingBindingElement	O codificador de mensagens binárias é o codificador padrão para as associações net* e a escolha apropriada sempre que ambas as partes comunicantes se baseiam no WCF. O codificador de mensagens binárias usa o Formato XML Binário do .NET, uma representação binária específica da Microsoft para Conjuntos de Informações XML (Infosets) que geralmente produz um volume menor do que a representação XML 1.0 equivalente e codifica dados binários como um fluxo de bytes.

A codificação de mensagem de texto normalmente é a melhor opção para qualquer caminho de comunicação que exija interoperabilidade, enquanto a codificação de mensagens binárias é a melhor opção para qualquer outro caminho de comunicação. A codificação de mensagens binárias normalmente produz tamanhos de mensagem menores em comparação com o texto de uma única mensagem e tamanhos de mensagem progressivamente ainda menores ao longo da duração de uma sessão de comunicação. Ao contrário da codificação de texto, a codificação binária não precisa usar tratamento especial para dados binários, como o uso da Base64, mas representa bytes como bytes.

Se sua solução não exigir interoperabilidade, mas você ainda quiser usar o transporte HTTP, você poderá compor em BinaryMessageEncodingBindingElement uma associação personalizada que usa a HttpTransportBindingElement classe para o transporte. Se vários clientes em seu serviço exigirem interoperabilidade, é recomendável que você exponha pontos de extremidade paralelos que cada um tenha as opções de transporte e codificação apropriadas para os respectivos clientes habilitados.

Habilitando o MTOM

Quando a interoperabilidade é um requisito e dados binários grandes devem ser enviados, então a codificação de mensagens MTOM é a estratégia alternativa de codificação que pode ser habilitada nas vinculações padrão BasicHttpBinding ou WSHttpBinding ao definir a respectiva propriedade MessageEncoding para Mtom ou ao compor o MtomMessageEncodingBindingElement em um CustomBinding. O código de exemplo a seguir, extraído do exemplo de codificação MTOM , demonstra como habilitar o MTOM na configuração.

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

Conforme mencionado anteriormente, a decisão de usar a codificação MTOM depende do volume de dados que você está enviando. Além disso, como o MTOM está habilitado no nível de associação, habilitar o MTOM afeta todas as operações em um determinado ponto de extremidade.

Como o codificador MTOM sempre emite uma mensagem MIME/várias partes codificada em MTOM, independentemente de os dados binários acabarem sendo externalizados, você geralmente só deve habilitar o MTOM para pontos de extremidade que trocam mensagens com mais de 1 KB de dados binários. Além disso, os contratos de serviço criados para uso com pontos de extremidade habilitados para MTOM devem, quando possível, ser restringidos para especificar essas operações de transferência de dados. A funcionalidade de controle relacionada deve residir em um contrato separado. Essa regra "somente MTOM" aplica-se somente a mensagens enviadas por meio de um ponto de extremidade habilitado para MTOM; O codificador MTOM também pode decodificar e analisar mensagens não MTOM de entrada.

O uso do codificador MTOM está em conformidade com todos os outros recursos do WCF. Observe que talvez não seja possível observar essa regra em todos os casos, como quando o suporte à sessão é necessário.

Modelo de programação

Independentemente de quais dos três codificadores internos você usa em seu aplicativo, a experiência de programação é idêntica em relação à transferência de dados binários. A diferença está na forma como o WCF lida com os dados com base em seus tipos de dados.

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

Ao usar o MTOM, o contrato de dados anterior é serializado de acordo com as seguintes regras:

• Se binaryBuffer não for null e contiver individualmente dados suficientes para justificar a sobrecarga de externalização do MTOM (cabeçalhos MIME e assim por diante) quando comparado à codificação Base64, os dados serão externalizados e carregados com a mensagem como uma parte MIME binária. Se o limite não for excedido, os dados serão codificados como Base64.

• A cadeia de caracteres (e todos os outros tipos que não são binários) é sempre representada como uma cadeia de caracteres dentro do corpo da mensagem, independentemente do tamanho.

O efeito na codificação MTOM é o mesmo se você usar um contrato de dados explícito, conforme mostrado no exemplo anterior, usar uma lista de parâmetros em uma operação, ter contratos de dados aninhados ou transferir um objeto de contrato de dados dentro de uma coleção. Matrizes de bytes são sempre candidatas à otimização e são otimizadas se os limites de otimização estiverem sendo atendidos.

Observação

Você não deve usar System.IO.Stream tipos derivados dentro de contratos de dados. Os dados de fluxo devem ser comunicados usando o modelo de streaming, explicado na seção "Dados de Streaming" a seguir.

Dados de streaming

Quando você tem uma grande quantidade de dados para transferir, o modo de transferência de streaming no WCF é uma alternativa viável ao comportamento padrão de buffer e processamento de mensagens na memória em sua totalidade.

Conforme mencionado anteriormente, habilite o streaming somente para mensagens grandes (com texto ou conteúdo binário) se os dados não puderem ser segmentados, se a mensagem precisar ser entregue em tempo hábil ou se os dados ainda não estiverem totalmente disponíveis quando a transferência for iniciada.

Restrições

Você não pode usar um número significativo de recursos do WCF quando o streaming está habilitado:

• As assinaturas digitais para o corpo da mensagem não podem ser executadas porque exigem a computação de um hash sobre todo o conteúdo da mensagem. Com o streaming, o conteúdo não está totalmente disponível quando os cabeçalhos de mensagem são construídos e enviados e, portanto, uma assinatura digital não pode ser computada.

• A criptografia depende de assinaturas digitais para verificar se os dados foram reconstruídos corretamente.

• Sessões confiáveis devem armazenar mensagens enviadas em buffer no cliente para resgate se uma mensagem for perdida na transferência e devem conter mensagens no serviço antes de entregá-las à implementação do serviço para preservar a ordem das mensagens caso as mensagens sejam recebidas fora de sequência.

Devido a essas restrições funcionais, você pode usar apenas opções de segurança em nível de transporte para streaming e não pode ativar sessões confiáveis. O streaming só está disponível com as seguintes associações definidas pelo sistema:

• BasicHttpBinding

• NetTcpBinding

• NetNamedPipeBinding

• WebHttpBinding

Como os transportes subjacentes em NetTcpBinding e NetNamedPipeBinding têm suporte inerente a entrega confiável e a sessões baseadas em conexão, ao contrário do HTTP, na prática, essas duas associações são minimamente afetadas por essas restrições.

O streaming não está disponível com o transporte de MSMQ (enfileiramento de mensagens) e, portanto, não pode ser usado com a classe NetMsmqBinding ou MsmqIntegrationBinding. O transporte de Enfileiramento de Mensagens dá suporte apenas a transferências de dados em buffer com um tamanho de mensagem restrito, enquanto todos os outros transportes não têm nenhum limite prático de tamanho de mensagem para a grande maioria dos cenários.

O streaming também não está disponível ao usar o transporte de Canal de mesmo nível, portanto, não está disponível com NetPeerTcpBinding.

Streaming e sessões

Você pode obter um comportamento inesperado ao transmitir chamadas com uma associação baseada em sessão. Todas as chamadas de streaming são feitas por meio de um único canal (o canal de datagram) que não dá suporte a sessões, mesmo que a associação que está sendo usada esteja configurada para usar sessões. Se vários clientes fizerem chamadas de streaming para o mesmo objeto de serviço em uma associação baseada em sessão e o modo de simultaneidade do objeto de serviço estiver definido como único e seu modo de contexto de instância for definido como PerSession, todas as chamadas deverão passar pelo canal de datagrama e, portanto, apenas uma chamada será processada por vez. Portanto, um ou mais clientes podem atingir o tempo limite. Você pode contornar esse problema definindo o Modo de Contexto da Instância do objeto de serviço como PerCall ou a Simultaneidade como Múltipla.

Observação

MaxConcurrentSessions não tem efeito nesse caso porque há apenas uma "sessão" disponível.

Habilitando o streaming

Você pode habilitar o streaming das seguintes maneiras:

• Enviar e aceitar solicitações no modo de streaming e aceitar e retornar respostas no modo em buffer (StreamedRequest).

• Enviar e aceitar solicitações no modo bufferizado e aceitar e retornar respostas no modo de streaming (StreamedResponse).

• Enviar e receber solicitações e respostas no modo transmitido em ambas as direções. (Streamed).

Você pode desabilitar o streaming definindo o modo de transferência como Buffered, que é a configuração padrão em todas as associações. O código a seguir mostra como definir o modo de transferência na configuração.

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

Ao instanciar sua vinculação no código, você deve definir a respectiva propriedade TransferMode da vinculação (ou o elemento de vinculação de transporte se estiver compondo uma vinculação personalizada) como um dos valores mencionados anteriormente.

Você pode ativar o streaming para solicitações e respostas ou para ambas as direções de forma independente em ambos os lados das partes comunicantes sem afetar a funcionalidade. No entanto, você sempre deve assumir que o tamanho dos dados transferidos é tão significativo que habilitar o streaming é justificado em ambos os pontos de extremidade de um link de comunicação. Para comunicação entre plataformas, onde um dos pontos de extremidade não está implementado com o WCF, a capacidade de usar o streaming depende dos recursos de streaming da plataforma. Outra exceção rara pode ser um cenário controlado por consumo de memória em que um cliente ou serviço deve minimizar seu conjunto de trabalho e só pode oferecer tamanhos de buffer pequenos.

Habilitando o streaming assíncrono

Para habilitar o streaming assíncrono, adicione o comportamento do ponto de extremidade DispatcherSynchronizationBehavior ao host de serviço e defina sua propriedade AsynchronousSendEnabled como true. Também adicionamos a capacidade de streaming assíncrono verdadeiro no lado de envio. Isso melhora a escalabilidade do serviço em cenários em que ele está transmitindo mensagens para vários clientes, alguns dos quais são lentos na leitura possivelmente devido ao congestionamento de rede ou não estão lendo. Nesses cenários, agora não bloqueamos threads individuais no serviço por cliente. Isso garante que o serviço possa processar muito mais clientes, melhorando dessa forma a escalabilidade do serviço.

Modelo de programação para transferências em fluxo contínuo

O modelo de programação para streaming é simples. Para receber dados transmitidos, especifique um contrato de operação que tenha um único Stream parâmetro de entrada tipado. Para retornar dados transmitidos, retorne uma Stream referência.

[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);
}

A operação Echo no exemplo anterior recebe e retorna um fluxo e, portanto, deve ser usada em uma associação com Streamed. Para a operação RequestInfo, StreamedResponse é mais adequado, pois retorna apenas um Stream. A operação unidirecional é mais adequada para StreamedRequest.

Observe que adicionar um segundo parâmetro ao seguinte Echo ou ProvideInfo operação faz com que o modelo de serviço reverta para uma estratégia em buffer e use a representação de serialização de tempo de execução do fluxo. Somente as operações com um único parâmetro de fluxo de entrada são compatíveis com o streaming de solicitação de ponta a ponta.

Essa regra também se aplica a contratos de mensagens. Conforme mostrado no contrato de mensagem a seguir, você pode ter apenas um único membro de corpo em seu contrato de mensagem que seja um fluxo. Se você quiser comunicar informações adicionais com o fluxo, essas informações devem ser incluídas nos cabeçalhos de mensagem. O corpo da mensagem é reservado exclusivamente para o conteúdo do fluxo.

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

As transferências em fluxo terminam e a mensagem é fechada quando o fluxo atinge o fim do arquivo (EOF). Para enviar uma mensagem (retornando um valor ou invocando uma operação), você pode passar um FileStream, e, subsequentemente, a infraestrutura do WCF efetuará pull de todos os dados desse fluxo até que o fluxo tenha sido totalmente lido e o EOF tenha sido atingido. Para transferir dados em streaming para uma origem onde não existe nenhuma classe derivada Stream pré-criada, construa essa classe, sobreponha-a sobre a origem do fluxo e use como o argumento ou o valor de retorno.

Ao receber uma mensagem, o WCF constrói um fluxo sobre o conteúdo do corpo da mensagem codificado em Base64 (ou a respectiva parte MIME se estiver usando MTOM) e o fluxo atingirá o EOF quando o conteúdo tiver sido lido.

O streaming em nível de transporte também funciona com qualquer outro tipo de contrato de mensagem (listas de parâmetros, argumentos de contrato de dados e contrato de mensagem explícita), mas como a serialização e desserialização dessas mensagens tipadas exigem que o serializador faça um buffer, não é recomendável utilizar essas variantes de contrato.

Considerações especiais de segurança para dados grandes

Todas as associações permitem restringir o tamanho das mensagens de entrada para evitar ataques de negação de serviço. A BasicHttpBindingpropriedade , por exemplo, expõe uma propriedade System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize que vincula o tamanho da mensagem de entrada e, portanto, também vincula a quantidade máxima de memória que é acessada ao processar a mensagem. Essa unidade é definida em bytes com um valor padrão de 65.536 bytes.

Uma ameaça de segurança específica ao cenário de streaming de dados grande provoca uma negação de serviço fazendo com que os dados sejam armazenados em buffer quando o receptor espera que sejam transmitidos. Por exemplo, o WCF sempre armazena em buffer os cabeçalhos SOAP de uma mensagem e, portanto, um invasor pode construir uma grande mensagem mal-intencionada que consiste inteiramente em cabeçalhos para forçar os dados a serem armazenados em buffer. Quando a transmissão contínua está habilitada, MaxReceivedMessageSize pode ser definido como um valor extremamente grande, porque o receptor nunca espera que toda a mensagem seja armazenada na memória ao mesmo tempo. Se o WCF for forçado a armazenar a mensagem em buffer, ocorrerá um estouro de memória.

Portanto, restringir o tamanho máximo da mensagem de entrada não é suficiente nesse caso. A MaxBufferSize propriedade é necessária para restringir a memória que o WCF armazena em buffer. É importante definir isso como um valor seguro (ou mantê-lo no valor padrão) ao transmitir. Por exemplo, suponha que seu serviço deve receber arquivos de até 4 GB de tamanho e armazená-los no disco local. Suponha também que sua memória seja restrita de forma que você só possa armazenar em buffer 64 KB de dados por vez. Em seguida, você definiria como MaxReceivedMessageSize 4 GB e MaxBufferSize 64 KB. Além disso, na implementação do serviço, você deve garantir que você leia somente do fluxo de entrada em partes de 64 KB e não leia a próxima parte antes que a anterior tenha sido gravada em disco e descartada da memória.

Também é importante entender que essa cota limita apenas o buffer feito pelo WCF e não pode protegê-lo contra nenhum buffer que você faça em seu próprio serviço ou implementação de cliente. Para obter mais informações sobre considerações adicionais de segurança, consulte Considerações de segurança para dados.

Observação

A decisão de usar transferência em buffer ou em streaming é uma decisão local do ponto de extremidade. Para transportes HTTP, o modo de transferência não se propaga através de uma conexão ou para servidores proxy e outros intermediários. A definição do modo de transferência não é refletida na descrição da interface de serviço. Depois de gerar um cliente WCF para um serviço, você deve editar o arquivo de configuração para serviços destinados a serem usados com transferências transmitidas para definir o modo. Para transportes TCP e pipe nomeado, o modo de transferência é propagado como uma declaração de política.

Consulte também

• Como: habilitar a transmissão