Données volumineuses et diffusion en continu

Windows Communication Foundation (WCF) est une infrastructure de communication BASÉE sur XML. Étant donné que les données XML sont généralement encodées dans le format texte standard défini dans la spécification XML 1.0, les développeurs de systèmes connectés et les architectes s’inquiètent généralement de l’empreinte filaire (ou de la taille) des messages envoyés sur le réseau, et l’encodage basé sur le texte de XML pose des défis spéciaux pour le transfert efficace des données binaires.

Considérations de base

Pour fournir des informations générales sur les informations suivantes pour WCF, cette section met en évidence certaines préoccupations générales et considérations relatives aux encodages, aux données binaires et au streaming qui s’appliquent généralement aux infrastructures de systèmes connectés.

Données d’encodage : texte et binaire

Les préoccupations des développeurs fréquemment exprimées incluent la perception que XML a une surcharge significative par rapport aux formats binaires en raison de la nature répétitive des balises de début et des balises de fin, que l’encodage des valeurs numériques est considéré comme beaucoup plus grand, car ils sont exprimés dans des valeurs de texte et que les données binaires ne peuvent pas être exprimées efficacement, car elles doivent être spécialement encodées pour l’incorporation dans un format de texte.

Bien que la plupart de ces problèmes et des problèmes similaires soient valides, la différence réelle entre les messages codés en texte XML dans un environnement de services Web XML et les messages codés binaires dans un environnement d’appel de procédure distante hérité (RPC) est souvent beaucoup moins importante que la considération initiale peut suggérer.

Bien que les messages codés en texte XML soient transparents et « lisibles par l’homme », les messages binaires sont souvent assez obscurs en comparaison et difficiles à décoder sans outils. Cette différence de lisibilité conduit à ignorer que les messages binaires comportent souvent des métadonnées inline dans la charge utile, ce qui ajoute une surcharge tout comme avec les messages texte XML. Cela est particulièrement vrai pour les formats binaires qui visent à fournir des capacités de couplage lâche et d'invocation dynamique.

Toutefois, les formats binaires contiennent généralement ces informations de métadonnées descriptives dans un « en-tête », qui déclare également la disposition des données pour les enregistrements de données suivants. La charge utile suit ensuite cette déclaration de blocs de métadonnées communes avec une charge mémoire supplémentaire minime. En revanche, XML place chaque élément de données dans un élément ou un attribut afin que les métadonnées englobantes soient incluses de manière répétitive pour chaque objet de charge utile sérialisé. Par conséquent, la taille d’un objet de charge utile sérialisé unique est similaire lors de la comparaison de texte à des représentations binaires, car certaines métadonnées descriptives doivent être exprimées pour les deux, mais le format binaire tire parti de la description des métadonnées partagées avec chaque objet de charge utile supplémentaire transféré en raison de la surcharge globale inférieure.

Toutefois, pour certains types de données, tels que les nombres, il peut y avoir un inconvénient à utiliser des représentations numériques binaires de taille fixe, telles qu’un type décimal 128 bits au lieu de texte brut, car la représentation de texte brut peut être plusieurs octets plus petits. Les données de texte peuvent également bénéficier d'avantages de taille grâce aux choix d'encodage de texte XML, qui sont généralement plus flexibles, tandis que certains formats binaires peuvent être par défaut en Unicode 16 bits ou même 32 bits, ce qui ne s'applique pas au format XML binaire .NET.

Par conséquent, la décision entre le texte ou le fichier binaire n’est pas aussi simple que de supposer que les messages binaires sont toujours plus petits que les messages texte XML.

Un avantage clair des messages TEXTE XML est qu’ils sont basés sur des normes et offrent le plus large choix d’options d’interopérabilité et de prise en charge de la plateforme. Pour plus d’informations, consultez la section « Encodages » plus loin dans cette rubrique.

Contenu binaire

Une zone où les encodages binaires sont supérieurs aux encodages textuels en termes de taille de message résultant sont des éléments de données binaires volumineux tels que des images, des vidéos, des clips sonores ou toute autre forme de données binaires opaques qui doivent être échangées entre les services et leurs consommateurs. Pour adapter ces types de données au texte XML, l’approche courante consiste à les encoder à l’aide de l’encodage Base64.

Dans une chaîne encodée en Base64, chaque caractère représente 6 bits des données 8 bits d’origine, ce qui entraîne un ratio de surcharge d’encodage de 4:3 pour Base64, sans compter les caractères de mise en forme supplémentaires (retour chariot/flux de ligne) couramment ajoutés par convention. Bien que l’importance des différences entre les encodages XML et binaires dépend généralement du scénario, un gain de taille de plus de 33% lors de la transmission d’une charge utile de 500 Mo n’est généralement pas acceptable.

Pour éviter cette surcharge d’encodage, la norme MTOM (Message Transmission Optimization Mechanism) permet de externaliser des éléments de données volumineux contenus dans un message et de les transporter avec le message sous forme de données binaires sans encodage spécial. Avec MTOM, les messages sont échangés de manière similaire aux messages électroniques SMTP (Simple Mail Transfer Protocol) avec des pièces jointes ou du contenu incorporé (images et autres contenus incorporés) ; Les messages MTOM sont empaquetés en tant que séquences MIME multipart/connexes avec la partie racine étant le message SOAP réel.

Un message SOAP MTOM est modifié à partir de sa version non encodée afin que les balises d’élément spéciales qui font référence aux parties MIME respectives prennent la place des éléments d’origine dans le message qui contenaient des données binaires. Par conséquent, le message SOAP fait référence au contenu binaire en pointant vers les parties MIME envoyées avec celui-ci, mais il contient simplement des données de texte XML. Étant donné que ce modèle est étroitement aligné sur le modèle SMTP bien établi, il existe une prise en charge étendue des outils pour encoder et décoder des messages MTOM sur de nombreuses plateformes, ce qui en fait un choix extrêmement interopérable.

Toutefois, comme avec Base64, MTOM est également fourni avec une surcharge nécessaire pour le format MIME, de sorte que les avantages de l’utilisation de MTOM ne sont visibles que lorsque la taille d’un élément de données binaires dépasse environ 1 Ko. En raison de la surcharge, les messages encodés par MTOM peuvent être supérieurs aux messages qui utilisent l’encodage Base64 pour les données binaires, si la charge utile binaire reste inférieure à ce seuil. Pour plus d’informations, consultez la section « Encodages » plus loin dans cette rubrique.

Contenu de données volumineuses

L'encombrement du câble mis de côté, la charge utile de 500 Mo précédemment mentionnée représente également un grand challenge local pour le service et le client. Par défaut, WCF traite les messages en mode mis en mémoire tampon. Cela signifie que tout le contenu d’un message est présent en mémoire avant son envoi ou après sa réception. Bien qu’il s’agit d’une bonne stratégie pour la plupart des scénarios et nécessaire pour les fonctionnalités de messagerie telles que les signatures numériques et la remise fiable, les messages volumineux peuvent épuiser les ressources d’un système.

La stratégie de traitement des charges utiles volumineuses est la diffusion en continu. Bien que les messages, en particulier ceux exprimés en XML, soient généralement considérés comme étant des packages de données relativement compacts, un message peut être de plusieurs gigaoctets de taille et ressembler à un flux de données continu plus qu’un package de données. Lorsque les données sont transférées en mode streaming au lieu du mode mis en mémoire tampon, l’expéditeur met le contenu du corps du message à la disposition du destinataire sous la forme d’un flux et l’infrastructure de messages transfère en permanence les données de l’expéditeur au destinataire au fur et à mesure qu’elle devient disponible.

Le scénario le plus courant dans lequel de tels transferts de contenu de données volumineux se produisent sont des transferts d’objets de données binaires qui :

• Impossible de décomposer facilement une séquence de messages.

• Doit être livré en temps voulu.

• Ne sont pas disponibles dans leur intégralité lorsque le transfert est initié.

Pour les données qui n’ont pas ces contraintes, il est généralement préférable d’envoyer des séquences de messages dans l’étendue d’une session qu’un message volumineux. Pour plus d’informations, consultez la section « Streaming Data » plus loin dans cette rubrique.

Lors de l’envoi de grandes quantités de données, vous devez définir le maxAllowedContentLength paramètre IIS (pour plus d’informations, consultez Configuration des limites de requête IIS) et le maxReceivedMessageSize paramètre de liaison (par exemple , System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize ou MaxReceivedMessageSize). La maxAllowedContentLength propriété a la valeur par défaut 28,6 Mo et la maxReceivedMessageSize propriété a la valeur par défaut 64 Ko.

Encodages

Un encodage définit un ensemble de règles sur la façon de présenter des messages sur le câble. Un encodeur implémente un tel encodage et est responsable, côté expéditeur, de transformer une mémoire mémoire Message en un flux d’octets ou une mémoire tampon d’octets qui peut être envoyée sur le réseau. Côté récepteur, l’encodeur transforme une séquence d’octets en message en mémoire.

WCF inclut trois encodeurs et vous permet d’écrire et de brancher vos propres encodeurs, si nécessaire.

Chacune des liaisons standard inclut un encodeur préconfiguré, par lequel les liaisons avec le préfixe Net* utilisent l’encodeur binaire (y compris la BinaryMessageEncodingBindingElement classe) tandis que les BasicHttpBinding classes WSHttpBinding utilisent l’encodeur de message texte (par le biais de la TextMessageEncodingBindingElement classe) par défaut.

L’encodage de messages texte est généralement le meilleur choix pour tout chemin de communication nécessitant une interopérabilité, tandis que l’encodage de message binaire est le meilleur choix pour tout autre chemin de communication. L’encodage de messages binaires génère généralement des tailles de message plus petites par rapport au texte d’un seul message et des tailles de message encore plus petites au cours de la durée d’une session de communication. Contrairement à l’encodage de texte, l’encodage binaire n’a pas besoin d’utiliser une gestion spéciale pour les données binaires, telles que l’utilisation de Base64, mais représente des octets sous forme d’octets.

Si votre solution ne nécessite pas d’interopérabilité, mais que vous souhaitez toujours utiliser le transport HTTP, vous pouvez composer le BinaryMessageEncodingBindingElement dans une liaison personnalisée qui utilise la HttpTransportBindingElement classe pour le transport. Si un certain nombre de clients sur votre service nécessitent une interopérabilité, il est recommandé d’exposer des points de terminaison parallèles dont chacun dispose des choix de transport et d’encodage appropriés pour les clients respectifs activés.

Activation de MTOM

Lorsque l’interopérabilité est une exigence et que des données binaires volumineuses doivent être envoyées, l’encodage de message MTOM est la stratégie d’encodage alternative que vous pouvez activer sur les BasicHttpBinding liaisons ou WSHttpBinding standard en définissant la propriété respective MessageEncoding sur Mtom ou en composant le MtomMessageEncodingBindingElement dans un CustomBinding. L’exemple de code suivant, extrait de l’exemple d’encodage MTOM montre comment activer MTOM dans la configuration.

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

Comme mentionné précédemment, la décision d’utiliser l’encodage MTOM dépend du volume de données que vous envoyez. En outre, étant donné que MTOM est activé au niveau de la liaison, l’activation de MTOM affecte toutes les opérations sur un point de terminaison donné.

Étant donné que l’encodeur MTOM émet toujours un message MIME/multipart codé MTOM, indépendamment de l'externalisation éventuelle des données binaires, vous devez généralement activer MTOM uniquement pour les points de terminaison qui échangent des messages contenant plus de 1 Ko de données binaires. En outre, les contrats de service conçus pour une utilisation avec des points de terminaison compatibles MTOM doivent, dans la mesure du possible, être contraints de spécifier ces opérations de transfert de données. Les fonctionnalités de contrôle associées doivent résider sur un contrat distinct. Cette règle « MTOM uniquement » s’applique uniquement aux messages envoyés via un point de terminaison compatible MTOM ; L’encodeur MTOM peut également décoder et analyser les messages non MTOM entrants.

L’utilisation de l’encodeur MTOM est conforme à toutes les autres fonctionnalités WCF. Notez qu’il n’est peut-être pas possible d’observer cette règle dans tous les cas, par exemple lorsque la prise en charge de session est requise.

Modèle de programmation

Indépendamment des trois encodeurs intégrés que vous utilisez dans votre application, l’expérience de programmation est identique en ce qui concerne le transfert de données binaires. La différence réside dans la façon dont WCF gère les données en fonction de leurs types de données.

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

Lorsque vous utilisez MTOM, le contrat de données précédent est sérialisé conformément aux règles suivantes :

• Si binaryBuffer ce n’est pas null et contient individuellement suffisamment de données pour justifier la surcharge de externalisation MTOM (en-têtes MIME, et ainsi de suite) par rapport à l’encodage Base64, les données sont externalisées et transmises avec le message en tant que partie MIME binaire. Si le seuil n’est pas dépassé, les données sont encodées en base64.

• La chaîne (et tous les autres types qui ne sont pas binaires) est toujours représentée sous forme de chaîne à l’intérieur du corps du message, quelle que soit la taille.

L’effet sur l’encodage MTOM est identique si vous utilisez un contrat de données explicite, comme indiqué dans l’exemple précédent, utilisez une liste de paramètres dans une opération, avez des contrats de données imbriqués ou transférez un objet de contrat de données à l’intérieur d’une collection. Les tableaux d’octets sont toujours candidats à l’optimisation et sont optimisés si les seuils d’optimisation sont respectés.

Diffusion en continu de données

Lorsque vous avez une grande quantité de données à transférer, le mode de transfert de streaming dans WCF est une alternative possible au comportement par défaut de la mise en mémoire tampon et du traitement des messages en mémoire dans leur intégralité.

Comme mentionné précédemment, activez la diffusion en continu uniquement pour les messages volumineux (avec du texte ou du contenu binaire) si les données ne peuvent pas être segmentées, si le message doit être remis en temps voulu ou si les données ne sont pas encore entièrement disponibles lorsque le transfert est lancé.

Restrictions

Vous ne pouvez pas utiliser un nombre important de fonctionnalités WCF lorsque la diffusion en continu est activée :

• Les signatures numériques pour le texte du message ne peuvent pas être effectuées, car elles nécessitent le calcul d'un hachage sur l'ensemble du contenu du message. Avec la diffusion en continu, le contenu n’est pas entièrement disponible lorsque les en-têtes de message sont construits et envoyés et, par conséquent, une signature numérique ne peut pas être calculée.

• Le chiffrement dépend des signatures numériques pour vérifier que les données ont été reconstruites correctement.

• Les sessions fiables doivent mettre en mémoire tampon les messages envoyés sur le client à des fins de nouvelle livraison si un message se perd lors du transfert et elles doivent conserver les messages sur le service avant de les rendre à l'implémentation du service afin de conserver leur ordre s'ils ne sont pas reçus dans l'ordre.

En raison de ces contraintes fonctionnelles, vous pouvez utiliser uniquement les options de sécurité au niveau du transport pour la diffusion en continu et vous ne pouvez pas activer les sessions fiables. La diffusion en continu est disponible uniquement avec les liaisons définies par le système suivantes :

• BasicHttpBinding

• NetTcpBinding

• NetNamedPipeBinding

• WebHttpBinding

Étant donné que les transports sous-jacents de NetTcpBinding et NetNamedPipeBinding offrent une remise fiable et un support de session basé sur la connexion, contrairement à HTTP, ces deux liaisons ne sont affectées qu'au minimum par ces contraintes, dans la pratique.

La diffusion en continu n'est pas disponible avec le transport Message Queuing (MSMQ) et ne peut donc pas être utilisée avec NetMsmqBinding ou la classe MsmqIntegrationBinding. Le transport Message Queuing prend uniquement en charge les transferts de données mis en mémoire tampon avec une taille de message limitée, tandis que tous les autres transports n’ont pas de limite de taille de message pratique pour la grande majorité des scénarios.

La diffusion en continu n'est pas disponible non plus lors de l'utilisation du transport de canal homologue, elle n'est donc pas disponible avec NetPeerTcpBinding.

Diffusion en continu et sessions

Vous pouvez obtenir un comportement inattendu lors de la diffusion en continu d’appels avec une liaison basée sur une session. Tous les appels en streaming passent par un canal unique (le canal de datagramme) qui ne prend pas en charge les sessions même si la liaison utilisée est configurée pour utiliser des sessions. Si plusieurs clients effectuent des appels de diffusion en continu vers le même objet de service sur une liaison basée sur une session et que le mode d’accès concurrentiel de l’objet de service est défini sur unique et que son mode de contexte d’instance est défini sur PerSession, tous les appels doivent passer par le canal de datagramme et donc un seul appel est traité à la fois. Un ou plusieurs clients peuvent ensuite expirer. Vous pouvez contourner ce problème en définissant le mode contextuel d’instance de l’objet de service sur PerCall ou Concurrency sur Multiple.

Activation de la diffusion en continu

Vous pouvez activer la diffusion en continu de la manière suivante :

• Envoyer et accepter des demandes en mode streaming, accepter et retourner des réponses en mode mis en mémoire tampon (StreamedRequest).

• Envoyer et accepter les demandes en mode mis en mémoire tampon, et accepter et retourner les réponses en mode flux (StreamedResponse).

• Envoyer et recevoir des demandes et des réponses en mode streamé dans les deux sens. (Streamed).

Vous pouvez désactiver la diffusion en continu en définissant le mode Bufferedde transfert sur , qui est le paramètre par défaut sur toutes les liaisons. Le code suivant montre comment définir le mode de transfert dans la configuration.

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

Lorsque vous instanciez votre liaison dans le code, vous devez définir la propriété respective TransferMode de la liaison (ou l’élément de liaison de transport si vous composez une liaison personnalisée) sur l’une des valeurs mentionnées précédemment.

Vous pouvez activer la diffusion en continu pour les demandes et les réponses ou pour les deux directions indépendamment à l’un des deux côtés des parties de communication sans affecter les fonctionnalités. Toutefois, vous devez toujours supposer que la taille des données transférées est si importante que l’activation de la diffusion en continu est justifiée sur les deux points de terminaison d’un lien de communication. Pour la communication multiplateforme où l’un des points de terminaison n’est pas implémenté avec WCF, la possibilité d’utiliser la diffusion en continu dépend des fonctionnalités de diffusion en continu de la plateforme. Une autre exception rare peut être un scénario piloté par la consommation de mémoire où un client ou un service doit réduire son jeu de travail et ne peut se permettre que de petites tailles de mémoire tampon.

Activation de la diffusion en continu asynchrone

Pour activer la diffusion en continu asynchrone, ajoutez le comportement de point de terminaison DispatcherSynchronizationBehavior à l’hôte de service et affectez à sa propriété AsynchronousSendEnabled la valeur true. Nous avons également ajouté la capacité de véritable diffusion en continu asynchrone du côté de l'envoi. Cela améliore l’extensibilité du service dans les scénarios où il diffuse des messages vers plusieurs clients dont certains sont lents à lire éventuellement en raison de la congestion du réseau ou ne lisent pas du tout. Dans ces scénarios, nous ne bloquons pas les threads individuels sur le service pour chaque client. Cela garantit que le service peut gérer beaucoup plus de clients fournissant ainsi l'extensibilité du service.

Modèle de programmation pour les transferts streamés

Le modèle de programmation pour la diffusion en continu est simple. Pour recevoir des données diffusées en continu, spécifiez un contrat d’opération qui a un paramètre d’entrée typé unique Stream . Pour renvoyer des données en continu, renvoyez une référence Stream.

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

L’opération Echo dans l’exemple précédent reçoit et retourne un flux et doit donc être utilisée sur une liaison avec Streamed. Pour l’opération RequestInfo, StreamedResponse est mieux adapté, car il retourne uniquement un Stream. L’opération unidirectionnelle est idéale pour StreamedRequest.

Notez que l’ajout d’un deuxième paramètre aux opérations suivantes Echo ou ProvideInfo fait revenir le modèle de service à une stratégie de mise en mémoire tampon et utilise la représentation de sérialisation d'exécution du flux. Seules les opérations avec un seul paramètre de flux d’entrée sont compatibles avec le streaming des requêtes de bout en bout.

Cette règle s’applique de la même façon aux contrats de message. Comme indiqué dans le contrat de message suivant, votre contrat de message peut uniquement comporter un seul membre de corps qui est un flux. Si vous souhaitez communiquer des informations supplémentaires avec le flux, ces informations doivent être transmises dans les en-têtes de message. Le corps du message est exclusivement réservé au contenu de flux.

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

Les transferts en continu se terminent et le message est fermé lorsque le flux atteint la fin du fichier (EOF). Lors de l’envoi d’un message (renvoi d’une valeur ou appel d’une opération), vous pouvez passer un FileStream et l'infrastructure WCF extrait ensuite toutes les données de ce flux jusqu’à ce que le flux ait été entièrement lu et ait atteint la fin de fichier (EOF). Pour transférer des données diffusées en continu à partir d'une source pour laquelle aucune classe dérivée prédéfinie Stream n'existe, construisez une telle classe, superposez-la à votre source de flux et utilisez-la comme argument ou valeur de retour.

Lors de la réception d’un message, WCF construit un flux sur le contenu du corps du message codé en Base64 (ou la partie MIME correspondante si vous utilisez MTOM) et le flux atteint EOF lorsque le contenu a été lu.

La diffusion en continu au niveau du transport fonctionne également avec n’importe quel autre type de contrat de message (listes de paramètres, arguments de contrat de données et contrat de message explicite), mais parce que la sérialisation et la désérialisation de ces messages typés nécessitent une mise en mémoire tampon par le sérialiseur, l’utilisation de ces variantes de contrat n’est pas conseillée.

Considérations spéciales relatives à la sécurité pour les données volumineuses

Toutes les liaisons vous permettent de contraindre la taille des messages entrants afin d’empêcher des attaques par déni de service. Par BasicHttpBindingexemple, il expose une propriété System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize qui limite la taille du message entrant, et limite également la quantité maximale de mémoire accessible lors du traitement du message. Cette unité est définie en octets avec une valeur par défaut de 65 536 octets.

Une menace de sécurité spécifique au scénario de diffusion en continu de données volumineuse provoque un déni de service en provoquant la mise en mémoire tampon des données lorsque le récepteur s’attend à ce qu’il soit diffusé en continu. Par exemple, WCF met toujours en mémoire tampon les en-têtes SOAP d’un message. Par conséquent, un attaquant peut construire un message malveillant volumineux qui se compose entièrement d’en-têtes pour forcer la mise en mémoire tampon des données. Lorsque la diffusion en continu est activée, elle MaxReceivedMessageSize peut être définie sur une valeur extrêmement importante, car le récepteur ne s’attend jamais à ce que le message entier soit mis en mémoire tampon à la fois. Si WCF est forcé de mettre en mémoire tampon le message, un dépassement de mémoire se produit.

Par conséquent, la restriction de la taille maximale des messages entrants n’est pas suffisante dans ce cas. La propriété MaxBufferSize est nécessaire pour limiter la mémoire que le WCF met en mémoire tampon. Il est important de définir cette valeur sur une valeur sécurisée (ou de la conserver à la valeur par défaut) lors de la diffusion en continu. Par exemple, supposons que votre service doit recevoir des fichiers jusqu’à 4 Go de taille et les stocker sur le disque local. Supposons également que votre mémoire soit limitée de telle sorte que vous ne pouvez mettre en mémoire tampon que 64 Ko de données à la fois. Ensuite, vous définissez la MaxReceivedMessageSize valeur 4 Go et MaxBufferSize 64 Ko. En outre, dans votre implémentation de service, vous devez veiller à lire uniquement à partir du flux entrant par segment de 64 Ko et à ne pas lire le segment suivant avant que le précédent ne soit écrit sur le disque et qu'il soit effacé de la mémoire.

Il est également important de comprendre que ce quota limite uniquement la mise en mémoire tampon effectuée par WCF et ne peut pas vous protéger contre tout mise en mémoire tampon que vous effectuez dans votre propre implémentation de service ou de client. Pour plus d’informations sur les considérations de sécurité supplémentaires, consultez Considérations relatives à la sécurité pour les données.

Voir aussi

• Procédure : activer le streaming