Partilhar via

Grandes volumes de dados e streaming

  • Artigo

Windows Communication Foundation (WCF) é uma infraestrutura de comunicações baseada em XML. Como os dados XML são normalmente 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 a pegada de fio (ou tamanho) das mensagens enviadas pela rede, e a codificação baseada em texto de XML representa desafios especiais para a transferência eficiente de dados binários.

Considerações básicas

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

Dados de codificação: texto vs. binário

As preocupações dos desenvolvedores comumente expressas incluem a perceção de que o XML tem uma sobrecarga significativa quando comparado aos formatos binários devido à natureza repetitiva das tags de início e 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 de forma eficiente porque devem ser especialmente codificados para incorporação em um formato de texto.

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

Enquanto as mensagens codificadas em texto XML são transparentes e "legíveis por humanos", as mensagens binárias são muitas vezes 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 costumam carregar metadados embutidos na carga útil, o que adiciona sobrecarga assim como as mensagens de texto XML. Isso é especificamente verdadeiro para formatos binários que visam fornecer acoplamento flexível e recursos de invocação dinâmica.

No entanto, os 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, a carga útil segue essa declaração de bloco de metadados comum com o mínimo de sobrecarga adicional. Por outro lado, o XML inclui cada item de dados em um elemento ou atributo para que os metadados incluídos sejam repetidamente incluídos para cada objeto de carga serializada. Como resultado, o tamanho de um único objeto de carga útil 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 certos 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, já que a representação de texto sem formatação pode ser vários bytes menor. Os dados de texto também podem ter benefícios de tamanho das opções de codificação de texto XML normalmente mais flexíveis, enquanto alguns formatos binários podem usar como padrão Unicode de 16 bits ou até mesmo de 32 bits, o que não se aplica ao Formato XML Binário do .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 do 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 mais ampla escolha de opções de interoperabilidade e suporte a plataformas. 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 os serviços e seus consumidores. Para ajustar esses tipos de dados em texto XML, a abordagem comum é codificá-los usando a codificação Base64.

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

Para evitar essa sobrecarga de codificação, o padrão MTOM (Message Transmission Optimization Mechanism) permite externalizar grandes elementos de dados contidos em uma mensagem e transportá-los com a mensagem como dados binários sem qualquer codificação especial. Com o MTOM, as mensagens são trocadas de forma semelhante às mensagens de e-mail SMTP (Simple Mail Transfer Protocol) com anexos ou conteúdo incorporado (imagens e outros conteúdos incorporados); As mensagens MTOM são empacotadas como sequências MIME com várias partes/relacionadas, com a parte raiz sendo a mensagem SOAP real.

Uma mensagem MTOM SOAP é modificada a partir de sua versão não codificada para que marcas de elementos especiais que se referem às respetivas partes MIME substituam os 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 ele, mas, caso contrário, apenas carrega dados de texto XML. Como esse modelo está estreitamente alinhado com o modelo SMTP bem estabelecido, há amplo suporte a ferramentas para codificar e decodificar mensagens MTOM em muitas plataformas, o que o torna uma escolha extremamente interoperável.

Ainda assim, tal como acontece com Base64, MTOM também vem com alguma sobrecarga necessária para o formato MIME, de modo que as vantagens de usar 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 a carga útil binária 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

Pegada de fio à parte, a carga útil de 500 MB mencionada anteriormente também representa um grande desafio local para o serviço e para o cliente. Por padrão, o WCF processa mensagens no modo de buffer. Isto 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 úteis é 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 mais a um fluxo de dados contínuo do que a 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 recetor à medida que ficam disponíveis.

O cenário mais comum em que essas grandes transferências de conteúdo de dados 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 na 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 "Streaming de dados" 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 vinculação (por exemplo , System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize ou MaxReceivedMessageSize). O maxAllowedContentLength padrão da propriedade é 28,6 MB e a maxReceivedMessageSize propriedade é 64KB.

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 um in-memory Message em um fluxo de bytes ou buffer de bytes que pode ser enviado através da rede. No lado do recetor, o codificador transforma uma sequência de bytes em uma mensagem na memória.

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

Cada uma das ligações padrão inclui um codificador pré-configurado, em que as ligações com o prefixo Net* usam o codificador binário (incluindo a BinaryMessageEncodingBindingElement classe) enquanto as BasicHttpBinding classes e WSHttpBinding usam o codificador de mensagem de texto (por meio da TextMessageEncodingBindingElement classe) por padrão.

Elemento de ligação do codificador Description
TextMessageEncodingBindingElement O codificador de mensagem de texto é o codificador padrão para todas as ligações baseadas em HTTP e a escolha apropriada para todas as ligações personalizadas onde a interoperabilidade é a maior preocupação. Este codificador lê e escreve mensagens de texto padrão SOAP 1.1/SOAP 1.2 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 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 excedam um limite em que a codificação MTOM produz um benefício, os dados serão externalizados em uma parte MIME após o envelope da mensagem. Consulte Ativando MTOM mais adiante nesta seção.
BinaryMessageEncodingBindingElement O codificador de mensagem binária é o codificador padrão para as ligações Net* e a escolha apropriada sempre que ambas as partes comunicantes são baseadas no WCF. O codificador de mensagem binária usa o .NET Binary XML Format, uma representação binária específica da Microsoft para conjuntos de informações XML (Infosets) que geralmente produz uma pegada menor do que a representação equivalente do XML 1.0 e codifica dados binários como um fluxo de bytes.

A codificação de mensagens de texto é normalmente a melhor escolha para qualquer caminho de comunicação que exija interoperabilidade, enquanto a codificação de mensagens binárias é a melhor escolha 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 progressivamente tamanhos de mensagem 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 usar Base64, mas representa bytes como bytes.

Se sua solução não requer interoperabilidade, mas você ainda deseja usar o transporte HTTP, você pode compor o BinaryMessageEncodingBindingElement em 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 tenham as opções de transporte e codificação apropriadas para os respetivos clientes habilitados.

Ativando MTOM

Quando a interoperabilidade é um requisito e grandes dados binários devem ser enviados, a codificação de mensagens MTOM é a estratégia de codificação alternativa que você pode habilitar no padrão BasicHttpBinding ou em ligações definindo a respetiva MessageEncoding propriedade para Mtom ou compondo o MtomMessageEncodingBindingElement em um CustomBindingWSHttpBinding . O código de exemplo a seguir, extraído do exemplo de codificação MTOM demonstra como habilitar MTOM na configuração.

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

Como 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 vinculação, habilitar o MTOM afeta todas as operações em um determinado ponto de extremidade.

Como o codificador MTOM sempre emite uma mensagem MIME/multiparte codificada em MTOM, independentemente de os dados binários acabarem sendo externalizados, geralmente você 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ços concebidos para utilização com terminais compatíveis com MTOM devem, sempre que possível, limitar-se a especificar essas operações de transferência de dados. A funcionalidade de controlo relacionada deve residir num contrato separado. Esta regra "apenas MTOM" aplica-se apenas a mensagens enviadas através de um ponto de extremidade habilitado para MTOM; o codificador MTOM também pode decodificar e analisar mensagens não MTOM recebidas.

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

Modelo de Programação

Independentemente de qual dos três codificadores internos você usa em seu aplicativo, a experiência de programação é idêntica no que diz respeito à transferência de dados binários. A diferença está em 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 MTOM, o contrato de dados anterior é serializado de acordo com as seguintes regras:

  • Se binaryBuffer não null for e individualmente contiver dados suficientes para justificar a sobrecarga de externalização MTOM (cabeçalhos MIME e assim por diante) quando comparado à codificação Base64, os dados serão externalizados e transportados 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, como 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. As matrizes de bytes são sempre candidatas à otimização e são otimizadas se os limites de otimização estiverem sendo atingidos.

Nota

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.

Streaming de dados

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

Como mencionado anteriormente, habilite o streaming apenas para mensagens grandes (com texto ou conteúdo binário) se os dados não puderem ser segmentados, se a mensagem tiver que 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

Não é possível 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 das mensagens são construídos e enviados e, portanto, uma assinatura digital não pode ser calculada.

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

  • As sessões confiáveis devem armazenar em buffer as mensagens enviadas no cliente para reentrega se uma mensagem se perder na transferência e devem manter as mensagens no serviço antes de entregá-las à implementação do serviço para preservar a ordem das mensagens no caso de as mensagens serem recebidas fora de sequência.

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

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

O streaming não está disponível com o transporte MSMQ (Enfileiramento de Mensagens) e, portanto, não pode ser usado com a classe ou com a NetMsmqBindingMsmqIntegrationBinding classe. O transporte do serviço de enfileiramento de mensagens suporta apenas 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 ponto a ponto, portanto, não está disponível com o NetPeerTcpBinding.

Streaming e Sessões

Você pode ter um comportamento inesperado ao transmitir chamadas com uma associação baseada em sessão. Todas as chamadas de streaming são feitas através de um único canal (o canal de datagrama) que não suporta 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 por meio de 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 estiver definido como PerSession, todas as chamadas deverão passar pelo canal de datagrama e, portanto, apenas uma chamada será processada de cada vez. Um ou mais clientes podem então atingir o tempo limite. Você pode contornar esse problema definindo o modo de contexto de instância do objeto de serviço para PerCall ou simultaneidade para múltiplo.

Nota

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

Ativando o streaming

Você pode habilitar o streaming das seguintes maneiras:

  • Envie e aceite solicitações no modo de streaming e aceite e retorne respostas no modo em buffer (StreamedRequest).

  • Envie e aceite solicitações no modo buffered e aceite e retorne respostas no modo transmitido (StreamedResponse).

  • Envie e receba solicitações e respostas em modo streaming em ambas as direções. (Streamed).

Você pode desativar 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 respetiva TransferMode propriedade da associação (ou o elemento de vinculação de transporte, se estiver compondo uma associação personalizada) para 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 a habilitação do streaming é justificada em ambos os pontos finais de um link de comunicação. Para comunicação entre plataformas em que um dos pontos de extremidade não é implementado com o WCF, a capacidade de usar streaming depende dos recursos de streaming da plataforma. Outra exceção rara pode ser um cenário orientado ao consumo de memória em que um cliente ou serviço deve minimizar seu conjunto de trabalho e só pode pagar pequenos tamanhos de buffer.

Habilitando o streaming assíncrono

Para habilitar o streaming assíncrono, adicione o comportamento do DispatcherSynchronizationBehavior ponto de extremidade ao host de serviço e defina sua AsynchronousSendEnabled propriedade como true. Também adicionamos a capacidade de streaming assíncrono verdadeiro no lado do 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 da 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 seja capaz de processar muito mais clientes, melhorando assim a escalabilidade do serviço.

Modelo de programação para transferências transmitidas em fluxo

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 digitado. 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 ligação com Streamed. Para a operação RequestInfo, StreamedResponse é mais adequado, porque só retorna um Streamarquivo . A operação unidirecional é mais adequada para StreamedRequest.

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

Esta regra aplica-se igualmente aos contratos de mensagens. Conforme mostrado no contrato de mensagem a seguir, você pode ter apenas um único membro do 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 transportadas nos cabeçalhos das mensagens. O corpo da mensagem é exclusivamente reservado para o conteúdo do fluxo.

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

As transferências transmitidas terminam e a mensagem é fechada quando o fluxo atinge o final do arquivo (EOF). Ao enviar uma mensagem (retornando um valor ou invocando uma operação), você pode passar um FileStream e a infraestrutura WCF subsequentemente extrai todos os dados desse fluxo até que o fluxo tenha sido completamente lido e alcançado EOF. Para transferir dados transmitidos para a fonte que não existe essa classe derivada pré-criada Stream , construa essa classe, sobreponha essa classe à sua fonte de fluxo e use-a como argumento ou 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 respetiva parte MIME se estiver usando MTOM) e o fluxo atinge EOF quando o conteúdo foi lido.

O streaming no 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ícito), mas como a serialização e desserialização de tais mensagens digitadas requer armazenamento em buffer pelo serializador, o uso dessas variantes de contrato não é aconselhável.

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

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

Uma ameaça à segurança específica do cenário de streaming de dados grandes provoca uma negação de serviço, fazendo com que os dados sejam armazenados em buffer quando o recetor espera que eles 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 o streaming está ativado, o MaxReceivedMessageSize pode ser definido para um valor extremamente grande, porque o recetor nunca espera que toda a mensagem seja armazenada em buffer na memória de uma só vez. 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 recebida não é suficiente neste 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 e armazená-los no disco local. Suponha também que sua memória está restrita de tal forma que você só pode armazenar em buffer 64 KB de dados de cada vez. Em seguida, você definiria o MaxReceivedMessageSize para 4 GB e MaxBufferSize para 64 KB. Além disso, em sua implementação de serviço, você deve garantir que você leia somente do fluxo de entrada em blocos de 64 KB e não leia o próximo bloco antes que o anterior tenha sido gravado no disco e descartado da memória.

Também é importante entender que essa cota limita apenas o buffering feito pelo WCF e não pode protegê-lo contra qualquer buffering que você faz 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.

Nota

A decisão de usar transferências em buffer ou transmitidas em fluxo é 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 configuraçã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 TCP e transportes de pipe nomeado, o modo de transferência é propagado como uma declaração de política.

Consulte também