Stora data och direktuppspelning

Windows Communication Foundation (WCF) är en XML-baserad kommunikationsinfrastruktur. Eftersom XML-data ofta kodas i standardtextformatet som definieras i XML 1.0-specifikationen är anslutna systemutvecklare och arkitekter vanligtvis bekymrade över trådfotavtrycket (eller storleken) för meddelanden som skickas över nätverket, och den textbaserade kodningen av XML innebär särskilda utmaningar för effektiv överföring av binära data.

Grundläggande överväganden

För att ge bakgrundsinformation om följande information för WCF belyser det här avsnittet några allmänna problem och överväganden för kodningar, binära data och strömning som vanligtvis gäller för anslutna systeminfrastrukturer.

Kodningsdata: Text jämfört med binär

Vanliga problem med utvecklare är uppfattningen att XML har betydande omkostnader jämfört med binära format på grund av den repetitiva karaktären hos starttaggar och sluttaggar, att kodningen av numeriska värden anses vara betydligt större eftersom de uttrycks i textvärden och att binära data inte kan uttryckas effektivt eftersom de måste kodas särskilt för inbäddning i ett textformat.

Även om många av dessa och liknande problem är giltiga är den faktiska skillnaden mellan XML-textkodade meddelanden i en XML-webbtjänstmiljö och binärkodade meddelanden i en äldre RPC-miljö (remote procedure call) ofta mycket mindre betydande än vad det första övervägandet kan antyda.

Medan XML-textkodade meddelanden är transparenta och "läsbara för människor", är binära meddelanden ofta ganska obskyra i jämförelse och svåra att avkoda utan verktyg. Den här skillnaden i läsbarhet leder till att man bortser från att binära meddelanden också ofta har infogade metadata i nyttolasten, vilket lägger till omkostnader precis som med XML-textmeddelanden. Detta gäller särskilt för binära format som syftar till att tillhandahålla funktioner för lös koppling och dynamisk anrop.

Binära format innehåller dock ofta sådan beskrivande metadatainformation i ett "huvud", som också deklarerar datalayouten för följande dataposter. Nyttolasten följer sedan den här vanliga blockdeklarationen för metadata med minimal ytterligare omkostnader. Xml omsluter däremot varje dataobjekt i ett element eller attribut så att omslutande metadata upprepas för varje serialiserat nyttolastobjekt. Därför liknar storleken på ett enda serialiserat nyttolastobjekt när text jämförs med binära representationer eftersom vissa beskrivande metadata måste uttryckas för båda, men det binära formatet drar nytta av beskrivningen av delade metadata med varje ytterligare nyttolastobjekt som överförs på grund av lägre övergripande omkostnader.

Men för vissa datatyper, till exempel tal, kan det finnas en nackdel med att använda binära numeriska representationer med fast storlek, till exempel en decimaltyp på 128 bitar i stället för oformaterad text, eftersom representationen av oformaterad text kan vara flera byte mindre. Textdata kan också ha storleksfördelar med de vanligtvis mer flexibla XML-textkodningsalternativen, medan vissa binära format kan vara 16-bitars eller till och med 32-bitars Unicode, vilket inte gäller för .NET Binary XML-format.

Därför är det inte lika enkelt att välja mellan text eller binärt som att anta att binära meddelanden alltid är mindre än XML-textmeddelanden.

En klar fördel med XML-textmeddelanden är att de är standardbaserade och erbjuder det bredaste valet av samverkansalternativ och plattformsstöd. Mer information finns i avsnittet "Kodningar" senare i det här avsnittet.

Binärt innehåll

Ett område där binära kodningar är överlägsna textbaserade kodningar när det gäller den resulterande meddelandestorleken är stora binära dataobjekt som bilder, videor, ljudklipp eller någon annan form av ogenomskinliga binära data som måste utbytas mellan tjänster och deras konsumenter. För att anpassa dessa typer av data till XML-text är den vanliga metoden att koda dem med hjälp av Base64-kodningen.

I en Base64-kodad sträng representerar varje tecken 6 bitar av de ursprungliga 8-bitarsdata, vilket resulterar i ett 4:3-kodnings-overhead-förhållande för Base64, utan att räkna extra formateringstecken (vagnretur/radmatning) som ofta läggs till av konventionen. Även om betydelsen av skillnaderna mellan XML och binära kodningar vanligtvis beror på scenariot, är en storleksvinst på mer än 33 % vid överföring av en nyttolast på 500 MB vanligtvis inte acceptabel.

För att undvika den här kodningsbelastningen kan MTOM-standarden (Message Transmission Optimization Mechanism) externalisera stora dataelement som finns i ett meddelande och bära dem med meddelandet som binära data utan någon särskild kodning. Med MTOM utbyts meddelanden på ett liknande sätt som SMTP-e-postmeddelanden (Simple Mail Transfer Protocol) med bifogade filer eller inbäddat innehåll (bilder och annat inbäddat innehåll); MTOM-meddelanden paketeras som flerdels-/relaterade MIME-sekvenser där rotdelen är det faktiska SOAP-meddelandet.

Ett MTOM SOAP-meddelande ändras från dess okodade version så att särskilda elementtaggar som refererar till respektive MIME-delar tar plats för de ursprungliga elementen i meddelandet som innehöll binära data. Därför refererar SOAP-meddelandet till binärt innehåll genom att peka på MIME-delarna som skickas med det, men annars bara innehåller XML-textdata. Eftersom den här modellen är nära anpassad till den väletablerade SMTP-modellen finns det ett brett verktygsstöd för att koda och avkoda MTOM-meddelanden på många plattformar, vilket gör den till ett mycket driftskompatibelt val.

Men precis som med Base64 medför MTOM även en del nödvändiga omkostnader för MIME-formatet, så att fördelarna med att använda MTOM bara visas när storleken på ett binärt dataelement överskrider cirka 1 KB. På grund av omkostnaderna kan MTOM-kodade meddelanden vara större än meddelanden som använder Base64-kodning för binära data, om den binära nyttolasten förblir under det tröskelvärdet. Mer information finns i avsnittet "Kodningar" senare i det här avsnittet.

Stort datainnehåll

Förutom trådavtryck utgör den tidigare nämnda nyttolasten på 500 MB också en stor lokal utmaning för tjänsten och klienten. Som standard bearbetar WCF meddelanden i buffrat läge. Det innebär att hela innehållet i ett meddelande finns i minnet innan det skickas eller efter att det har tagits emot. Även om det är en bra strategi för de flesta scenarier och är nödvändig för meddelandefunktioner som digitala signaturer och tillförlitlig leverans, kan stora meddelanden uttömma ett systems resurser.

Strategin för att hantera stora nyttolaster är strömning. Även om meddelanden, särskilt de som uttrycks i XML, ofta anses vara relativt kompakta datapaket, kan ett meddelande vara flera gigabyte i storlek och likna en kontinuerlig dataström som är mer än ett datapaket. När data överförs i strömningsläge i stället för buffrat läge gör avsändaren innehållet i meddelandetexten tillgängligt för mottagaren i form av en ström och meddelandeinfrastrukturen vidarebefordrar kontinuerligt data från avsändaren till mottagaren när de blir tillgängliga.

Det vanligaste scenariot där sådana stora datainnehållsöverföringar sker är överföringar av binära dataobjekt som:

• Det går inte att enkelt dela upp i en meddelandesekvens.

• Måste levereras i tid.

• Är inte tillgängliga i sin helhet när överföringen initieras.

För data som inte har dessa begränsningar är det vanligtvis bättre att skicka sekvenser av meddelanden inom omfånget för en session än ett stort meddelande. Mer information finns i avsnittet "Strömmande data" senare i det här avsnittet.

När du skickar stora mängder data måste du ange maxAllowedContentLength IIS-inställningen (mer information finns i Konfigurera IIS-begärandegränser) och bindningsinställningen maxReceivedMessageSize (till exempel System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize eller MaxReceivedMessageSize). Egenskapen maxAllowedContentLength är som standard 28,6 MB och maxReceivedMessageSize egenskapen är som standard 64 KB.

Kodningar

En kodning definierar en uppsättning regler för hur meddelanden ska visas på tråden. En kodare implementerar en sådan kodning och ansvarar på avsändarsidan för att omvandla ett minnesinternt till Message en byteström eller bytebuffert som kan skickas över nätverket. På mottagarsidan omvandlar kodaren en sekvens med byte till ett minnesinternt meddelande.

WCF innehåller tre kodare och gör att du kan skriva och koppla in dina egna kodare om det behövs.

Var och en av standardbindningarna innehåller en förkonfigurerad kodare, där bindningarna med Net*-prefixet använder den binära kodaren (genom att inkludera BinaryMessageEncodingBindingElement klassen) medan BasicHttpBinding klasserna och WSHttpBinding använder textmeddelandekodaren (med hjälp av TextMessageEncodingBindingElement klassen) som standard.

Bindningselement för kodare	beskrivning
TextMessageEncodingBindingElement	Textmeddelandekodaren är standardkodaren för alla HTTP-baserade bindningar och lämpligt val för alla anpassade bindningar där samverkan är det största problemet. Den här kodaren läser och skriver standard-SOAP 1.1/SOAP 1.2-textmeddelanden utan särskild hantering av binära data. System.ServiceModel.Channels.MessageVersion Om egenskapen för ett meddelande är inställd på MessageVersion.Noneutelämnas SOAP-kuvertomslutningen från utdata och endast innehållet i meddelandetexten serialiseras.
MtomMessageEncodingBindingElement	MTOM-meddelandekodaren är en textkodare som implementerar särskild hantering av binära data och som standard inte används i någon av standardbindningarna eftersom det är ett optimeringsverktyg från fall till fall. Om meddelandet innehåller binära data som överskrider ett tröskelvärde där MTOM-kodning ger en fördel, externaliseras data till en MIME-del som följer meddelandekuvertet. Se Aktivera MTOM senare i det här avsnittet.
BinaryMessageEncodingBindingElement	Den binära meddelandekodaren är standardkodaren för Net*-bindningar och lämpligt val när båda de kommunicerande parterna baseras på WCF. Den binära meddelandekodaren använder .NET Binary XML-format, en Microsoft-specifik binär representation för XML Information Sets (Infosets) som vanligtvis ger ett mindre fotavtryck än motsvarande XML 1.0-representation och kodar binära data som en byteström.

Kodning av textmeddelanden är vanligtvis det bästa valet för alla kommunikationsvägar som kräver samverkan, medan binär meddelandekodning är det bästa valet för andra kommunikationsvägar. Binär meddelandekodning ger vanligtvis mindre meddelandestorlekar jämfört med text för ett enda meddelande och gradvis ännu mindre meddelandestorlekar under en kommunikationssession. Till skillnad från textkodning behöver binär kodning inte använda särskild hantering för binära data, till exempel att använda Base64, utan representerar byte som byte.

Om lösningen inte kräver samverkan, men du fortfarande vill använda HTTP-transport, kan du skapa BinaryMessageEncodingBindingElement till en anpassad bindning som använder HttpTransportBindingElement klassen för transporten. Om ett antal klienter i tjänsten kräver samverkan rekommenderar vi att du exponerar parallella slutpunkter som var och en har lämpliga transport- och kodningsalternativ för respektive klienter aktiverade.

Aktivera MTOM

När samverkan är ett krav och stora binära data måste skickas, är MTOM-meddelandekodning den alternativa kodningsstrategi som du kan aktivera på standarden BasicHttpBinding eller bindningarna genom att ange respektive MessageEncoding egenskap till eller genom att MtomMtomMessageEncodingBindingElement skapa till en CustomBindingWSHttpBinding . Följande exempelkod, som extraherats från MTOM-kodningsexemplet , visar hur du aktiverar MTOM i konfigurationen.

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

Som tidigare nämnts beror beslutet att använda MTOM-kodning på den datavolym som du skickar. Eftersom MTOM är aktiverat på bindningsnivå påverkar aktivering av MTOM alla åtgärder på en viss slutpunkt.

Eftersom MTOM-kodaren alltid genererar ett MTOM-kodat MIME-/flerdelsmeddelande oavsett om binära data kommer att externaliseras, bör du vanligtvis bara aktivera MTOM för slutpunkter som utbyter meddelanden med mer än 1 KB binära data. Dessutom bör de tjänstkontrakt som är utformade för användning med MTOM-aktiverade slutpunkter när det är möjligt begränsas till att ange sådana dataöverföringsåtgärder. Relaterade kontrollfunktioner bör finnas på ett separat kontrakt. Den här regeln "endast MTOM" gäller endast för meddelanden som skickas via en MTOM-aktiverad slutpunkt. MTOM-kodaren kan också avkoda och parsa inkommande icke-MTOM-meddelanden.

Användning av MTOM-kodaren överensstämmer med alla andra WCF-funktioner. Observera att det kanske inte går att observera den här regeln i alla fall, till exempel när sessionsstöd krävs.

Programmeringsmodell

Oavsett vilken av de tre inbyggda kodarna du använder i ditt program är programmeringsupplevelsen identisk med överföring av binära data. Skillnaden är hur WCF hanterar data baserat på deras datatyper.

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

När du använder MTOM serialiseras det föregående datakontraktet enligt följande regler:

• Om binaryBuffer inte null och individuellt innehåller tillräckligt med data för att motivera MTOM externalization overhead (MIME-huvuden och så vidare) jämfört med Base64-kodning, externaliseras data och transporteras med meddelandet som en binär MIME-del. Om tröskelvärdet inte överskrids kodas data som Base64.

• Strängen (och alla andra typer som inte är binära) representeras alltid som en sträng i meddelandetexten, oavsett storlek.

Effekten på MTOM-kodningen är densamma oavsett om du använder ett explicit datakontrakt, som du ser i föregående exempel, använder en parameterlista i en åtgärd, har kapslade datakontrakt eller överför ett datakontraktsobjekt i en samling. Bytematriser är alltid kandidater för optimering och optimeras om tröskelvärdena för optimering uppfylls.

Kommentar

Du bör inte använda System.IO.Stream härledda typer i datakontrakt. Dataströmdata ska kommuniceras med hjälp av strömningsmodellen, vilket förklaras i följande avsnitt "Strömmande data".

Strömmande data

När du har en stor mängd data att överföra är strömningsöverföringsläget i WCF ett möjligt alternativ till standardbeteendet för buffring och bearbetning av meddelanden i minnet i sin helhet.

Som tidigare nämnts aktiverar du endast strömning för stora meddelanden (med text eller binärt innehåll) om data inte kan segmenteras, om meddelandet måste levereras i tid eller om data ännu inte är helt tillgängliga när överföringen initieras.

Begränsningar

Du kan inte använda ett stort antal WCF-funktioner när strömning är aktiverat:

• Digitala signaturer för meddelandetexten kan inte utföras eftersom de kräver databehandling av en hash över hela meddelandeinnehållet. Med direktuppspelning är innehållet inte helt tillgängligt när meddelanderubrikerna konstrueras och skickas och därför inte kan en digital signatur beräknas.

• Kryptering är beroende av digitala signaturer för att verifiera att data har rekonstruerats korrekt.

• Tillförlitliga sessioner måste buffrar skickade meddelanden på klienten för omleverans om ett meddelande går förlorat i överföringen och måste lagra meddelanden på tjänsten innan de skickas till tjänstimplementeringen för att bevara meddelandeordningen om meddelanden tas emot utan sekvens.

På grund av dessa funktionella begränsningar kan du endast använda säkerhetsalternativ på transportnivå för strömning och du kan inte aktivera tillförlitliga sessioner. Direktuppspelning är endast tillgängligt med följande systemdefinierade bindningar:

• BasicHttpBinding

• NetTcpBinding

• NetNamedPipeBinding

• WebHttpBinding

Eftersom de underliggande transporterna av NetTcpBinding och NetNamedPipeBinding har inbyggd tillförlitlig leverans- och anslutningsbaserad sessionssupport, till skillnad från HTTP, påverkas dessa två bindningar endast minimalt av dessa begränsningar i praktiken.

Direktuppspelning är inte tillgängligt med MSMQ-transporten (Message Queuing) och kan därför inte användas med NetMsmqBinding klassen eller MsmqIntegrationBinding . Message Queuing-transporten stöder endast buffrade dataöverföringar med en begränsad meddelandestorlek, medan alla andra transporter inte har någon praktisk storleksgräns för meddelanden för de allra flesta scenarier.

Direktuppspelning är inte heller tillgängligt när du använder Peer Channel-transporten, så det är inte tillgängligt med NetPeerTcpBinding.

Direktuppspelning och sessioner

Du kan få ett oväntat beteende när du strömmar anrop med en sessionsbaserad bindning. Alla strömningsanrop görs via en enda kanal (datagramkanalen) som inte stöder sessioner även om bindningen som används är konfigurerad för att använda sessioner. Om flera klienter gör strömningsanrop till samma tjänstobjekt via en sessionsbaserad bindning och tjänstobjektets samtidighetsläge är inställt på enkel och dess instanskontextläge är inställt på PerSession, måste alla anrop gå via datagramkanalen och därför bearbetas bara ett anrop i taget. En eller flera klienter kan sedan överskrida tidsgränsen. Du kan kringgå det här problemet genom att antingen ange tjänstobjektets kontextläge för instans till PerCall eller Samtidighet till Flera.

Kommentar

MaxConcurrentSessions har ingen effekt i det här fallet eftersom det bara finns en "session" tillgänglig.

Aktivera direktuppspelning

Du kan aktivera direktuppspelning på följande sätt:

• Skicka och acceptera begäranden i strömningsläge och acceptera och returnera svar i buffrat läge (StreamedRequest).

• Skicka och acceptera begäranden i buffrat läge och acceptera och returnera svar i strömmat läge (StreamedResponse).

• Skicka och ta emot begäranden och svar i strömmat läge i båda riktningarna. (Streamed).

Du kan inaktivera direktuppspelning genom att ange överföringsläget till Buffered, vilket är standardinställningen för alla bindningar. Följande kod visar hur du ställer in överföringsläget i konfigurationen.

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

När du instansierar bindningen i kod måste du ange respektive TransferMode egenskap för bindningen (eller transportbindningselementet om du skapar en anpassad bindning) till ett av de tidigare nämnda värdena.

Du kan aktivera direktuppspelning för begäranden och svar eller för båda riktningarna oberoende av varandra på båda sidor av de kommunicerande parterna utan att påverka funktionaliteten. Du bör dock alltid anta att den överförda datastorleken är så betydande att aktivering av strömning motiveras på båda slutpunkterna för en kommunikationslänk. För plattformsoberoende kommunikation där en av slutpunkterna inte implementeras med WCF beror möjligheten att använda strömning på plattformens strömningsfunktioner. Ett annat sällsynt undantag kan vara ett minnesförbrukningsdrivet scenario där en klient eller tjänst måste minimera sin arbetsuppsättning och bara har råd med små buffertstorlekar.

Aktivera asynkron direktuppspelning

Om du vill aktivera asynkron direktuppspelning lägger du till DispatcherSynchronizationBehavior slutpunktsbeteendet till tjänstvärden och anger dess AsynchronousSendEnabled egenskap till true. Vi har också lagt till funktionen för sann asynkron strömning på sändningssidan. Detta förbättrar skalbarheten för tjänsten i scenarier där den strömmar meddelanden till flera klienter, av vilka vissa är långsamma i läsningen, eventuellt på grund av nätverksbelastning eller inte läser alls. I dessa scenarier blockerar vi nu inte enskilda trådar på tjänsten per klient. Detta säkerställer att tjänsten kan bearbeta många fler klienter och därmed förbättra tjänstens skalbarhet.

Programmeringsmodell för strömmade överföringar

Programmeringsmodellen för strömning är enkel. För att ta emot strömmade data anger du ett åtgärdskontrakt som har en enda Stream typad indataparameter. Returnera en Stream referens för att returnera strömmade data.

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

Åtgärden Echo i föregående exempel tar emot och returnerar en ström och bör därför användas på en bindning med Streamed. För åtgärden RequestInfoStreamedResponse , passar bäst eftersom den bara returnerar en Stream. Enkelriktad åtgärd passar bäst för StreamedRequest.

Observera att om du lägger till en andra parameter i följande Echo åtgärder eller ProvideInfo åtgärder återgår tjänstmodellen till en buffrad strategi och använder run-time-serialiseringsrepresentationen av dataströmmen. Endast åtgärder med en enda indataströmsparameter är kompatibla med direktuppspelning från slutpunkt till slutpunkt.

Den här regeln gäller på samma sätt för meddelandekontrakt. Som du ser i följande meddelandekontrakt kan du bara ha en enda brödtextmedlem i ditt meddelandekontrakt som är en ström. Om du vill kommunicera ytterligare information med dataströmmen måste den här informationen vara en i meddelanderubriker. Meddelandetexten är exklusivt reserverad för dataströminnehållet.

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

Strömmade överföringar avslutas och meddelandet stängs när strömmen når slutet av filen (EOF). När du skickar ett meddelande (returnerar ett värde eller anropar en åtgärd) kan du skicka en FileStream och WCF-infrastrukturen hämtar därefter alla data från dataströmmen tills strömmen har lästs helt och nått EOF. Om du vill överföra strömmade data för källan att det inte finns någon sådan fördefinierad Stream härledd klass skapar du en sådan klass, lägger över den klassen över dataströmkällan och använder den som argument- eller returvärde.

När du tar emot ett meddelande skapar WCF en ström över det Base64-kodade brödtextinnehållet (eller respektive MIME-del om du använder MTOM) och strömmen når EOF när innehållet har lästs.

Strömning på transportnivå fungerar också med andra typer av meddelandekontrakt (parameterlistor, datakontraktsargument och explicit meddelandekontrakt), men eftersom serialisering och deserialisering av sådana typerade meddelanden kräver buffring av serialiseraren är det inte lämpligt att använda sådana kontraktsvarianter.

Särskilda säkerhetsöverväganden för stora data

Med alla bindningar kan du begränsa storleken på inkommande meddelanden för att förhindra överbelastningsattacker. , BasicHttpBindingtill exempel, exponerar en System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize-egenskap som begränsar storleken på det inkommande meddelandet, och begränsar därför även den maximala mängd minne som nås när meddelandet bearbetas. Den här enheten anges i byte med ett standardvärde på 65 536 byte.

Ett säkerhetshot som är specifikt för scenariot för stor dataströmning provocerar fram en överbelastningsåtgärd genom att göra så att data buffrads när mottagaren förväntar sig att den ska strömmas. Till exempel buffrar WCF alltid SOAP-huvudena i ett meddelande, så en angripare kan konstruera ett stort skadligt meddelande som helt består av rubriker för att tvinga data att bufferas. När strömning är aktiverat MaxReceivedMessageSize kan ställas in på ett extremt stort värde, eftersom mottagaren aldrig förväntar sig att hela meddelandet ska buffrats i minnet på en gång. Om WCF tvingas buffa meddelandet uppstår ett minnesspill.

Därför räcker det inte att begränsa den maximala storleken på inkommande meddelanden i det här fallet. Egenskapen MaxBufferSize krävs för att begränsa det minne som WCF buffrar. Det är viktigt att ställa in detta på ett säkert värde (eller behålla det som standardvärde) vid direktuppspelning. Anta till exempel att tjänsten måste ta emot filer med en storlek på upp till 4 GB och lagra dem på den lokala disken. Anta också att minnet är begränsat på ett sådant sätt att du bara kan buffera 64 KB data åt gången. Sedan skulle du ange MaxReceivedMessageSize till 4 GB och MaxBufferSize till 64 KB. I tjänstimplementeringen måste du också se till att du endast läser från den inkommande strömmen i 64 KB-segment och inte läser nästa segment innan det föregående har skrivits till disken och tagits bort från minnet.

Det är också viktigt att förstå att den här kvoten endast begränsar buffring som utförs av WCF och inte kan skydda dig mot buffring som du gör i din egen tjänst eller klientimplementering. Mer information om ytterligare säkerhetsöverväganden finns i Säkerhetsöverväganden för data.

Kommentar

Beslutet att använda buffrade eller strömmade överföringar är ett lokalt beslut för slutpunkten. För HTTP-transporter sprids inte överföringsläget över en anslutning eller till proxyservrar och andra mellanhänder. Att ange överföringsläget återspeglas inte i beskrivningen av tjänstgränssnittet. När du har genererat en WCF-klient till en tjänst måste du redigera konfigurationsfilen för tjänster som ska användas med strömmade överföringar för att ange läget. För TCP och namngivna rörtransporter sprids överföringsläget som en principkontroll.

Se även

• Gör så här: Aktivera direktuppspelning