Objemná data a vysílání datových proudů
Windows Communication Foundation (WCF) je komunikační infrastruktura založená na jazyce XML. Vzhledem k tomu, že data XML se běžně kódují ve standardním textovém formátu definovaném ve specifikaci XML 1.0, vývojáři a architekti připojených systémů se obvykle zajímají o drátové stopy (nebo velikost) zpráv odesílaných přes síť a kódování XML založené na textu představuje zvláštní výzvy pro efektivní přenos binárních dat.
Základní aspekty
Pokud chcete poskytnout základní informace o následujících informacích pro WCF, v této části jsou uvedeny některé obecné obavy a důležité informace o kódování, binárních datech a streamování, které se obecně vztahují na infrastrukturu připojených systémů.
Kódování dat: Text vs. Binární
Běžně vyjádřené obavy vývojářů zahrnují vnímání, že XML má významnou režii v porovnání s binárními formáty z důvodu opakované povahy počátečních značek a koncových značek, že kódování číselných hodnot je považováno za výrazně větší, protože jsou vyjádřeny v textových hodnotách, a že binární data nelze efektivně vyjádřit, protože musí být speciálně kódována pro vložení do textového formátu.
I když jsou mnohé z těchto a podobných obav platné, skutečný rozdíl mezi zprávami kódovanými v xml textovém kódu v prostředí webových služeb XML a binárními kódovanými zprávami v prostředí vzdáleného volání procedur (RPC) je často mnohem méně významný, než by mohlo naznačovat počáteční aspekty.
I když jsou zprávy kódované ve formátu XML transparentní a "čitelné", binární zprávy jsou často poměrně nejasné při porovnání a obtížně dekódují bez nástrojů. Tento rozdíl v čitelnosti vede k tomu, že binární zprávy také často obsahují vložená metadata v datové části, což zvyšuje režii stejně jako u textových zpráv XML. To platí konkrétně pro binární formáty, které mají za cíl poskytovat volné párování a dynamické možnosti vyvolání.
Binární formáty ale obvykle obsahují takové popisné informace metadat v "hlavičce", která také deklaruje rozložení dat pro následující datové záznamy. Datová část se pak řídí touto běžnou deklarací bloku metadat s minimální další režií. Naproti tomu XML uzavře každou datovou položku do elementu nebo atributu tak, aby uzavřená metadata byla opakovaně zahrnuta pro každý serializovaný objekt datové části. V důsledku toho je velikost jednoho serializovaného objektu datové části podobná při porovnávání textu s binární reprezentací, protože některá popisná metadata musí být vyjádřena pro oba, ale binární formát má výhody z popisu sdílených metadat s každým dalším objektem datové části, který je přenesen z důvodu nižší celkové režie.
U některých datových typů, například čísel, může být nevýhodou použití binárních číselných reprezentací s pevnou velikostí, například 128bitového desítkového typu místo prostého textu, protože reprezentace prostého textu může být menší několik bajtů. Textová data také můžou mít výhody z obvykle flexibilnějších možností kódování textu XML, zatímco některé binární formáty můžou mít výchozí 16bitovou nebo dokonce 32bitovou sadu Unicode, která se nevztahuje na binární formát XML .NET.
V důsledku toho není rozhodování mezi textem nebo binárním souborem tak snadné, protože za předpokladu, že binární zprávy jsou vždy menší než textové zprávy XML.
Jasnou výhodou textových zpráv XML je, že jsou založené na standardech a nabízejí nejširší volbu možností interoperability a podpory platformy. Další informace najdete v části Kódování dále v tomto tématu.
Binární obsah
Jedna oblast, ve které jsou binární kódování vynikající pro kódování založené na textu z hlediska výsledné velikosti zprávy, jsou velké binární datové položky, jako jsou obrázky, videa, zvukové klipy nebo jakákoli jiná forma neprůhlhlých binárních dat, která se musí vyměňovat mezi službami a jejich spotřebiteli. Pro přizpůsobení těchto typů dat do textu XML je běžným přístupem jejich kódování pomocí kódování Base64.
V řetězci s kódováním Base64 představuje každý znak 6 bitů původních 8bitových dat, což vede k poměru režijních nákladů kódování 4:3 pro Base64, nepočítá se nadbytečné znaky formátování (návratový/spojnicový kanál řádku), které se běžně přidávají konvencí. Význam rozdílů mezi kódováním XML a binárním kódováním obvykle závisí na scénáři, ale získání velikosti větší než 33 % při přenosu datové části o velikosti 500 MB obvykle není přijatelné.
Aby se zabránilo této režii kódování, standard MTOM (Message Transmission Optimization Mechanism) umožňuje externalizovat velké datové prvky obsažené ve zprávě a přenášet je se zprávou jako binární data bez jakéhokoli speciálního kódování. S MTOM se zprávy vyměňují podobným způsobem jako e-mailové zprávy SMTP (Simple Mail Transfer Protocol) s přílohami nebo vloženým obsahem (obrázky a další vložený obsah); Zprávy MTOM se zabalí jako vícedílné nebo související sekvence MIME s kořenovou částí, která je skutečnou zprávou SOAP.
Zpráva MTOM SOAP je změněna z jeho nekódované verze tak, aby speciální značky elementů odkazující na příslušné části MIME místo původních prvků ve zprávě, která obsahovala binární data. Výsledkem je, že zpráva SOAP odkazuje na binární obsah tím, že odkazuje na části MIME odeslané s ním, ale jinak pouze přenáší textová data XML. Vzhledem k tomu, že tento model je úzce v souladu s dobře zavedeným modelem SMTP, existuje široká podpora nástrojů pro kódování a dekódování zpráv MTOM na mnoha platformách, což z něj dělá extrémně interoperabilní volbu.
Stejně jako u Base64 má MTOM také určitou potřebnou režii pro formát MIME, takže výhody použití MTOM jsou vidět pouze v případě, že velikost binárního datového prvku přesahuje přibližně 1 kB. Vzhledem k režijním nákladům mohou být zprávy kódované MTOM větší než zprávy, které používají kódování Base64 pro binární data, pokud binární datová část zůstává pod danou prahovou hodnotou. Další informace najdete v části Kódování dále v tomto tématu.
Obsah velkých objemů dat
Převodní stopy, dříve zmíněná datová část 500 MB představuje také velkou místní výzvu pro službu a klienta. Wcf ve výchozím nastavení zpracovává zprávy v režimu vyrovnávací paměti. To znamená, že celý obsah zprávy se nachází v paměti před odesláním nebo po přijetí zprávy. I když je to dobrá strategie pro většinu scénářů a nezbytná pro funkce zasílání zpráv, jako jsou digitální podpisy a spolehlivé doručování, můžou velké zprávy vyčerpat prostředky systému.
Strategie pro zpracování velkých datových částí je streamování. Zprávy, zejména ty, které jsou vyjádřeny v JAZYCE XML, se často považují za relativně kompaktní datové balíčky, ale zpráva může mít velikost více gigabajtů a podobat se nepřetržitému datovému proudu více než datovému balíčku. Když se data přenesou v režimu streamování místo režimu vyrovnávací paměti, odesílatel zpřístupní obsah textu zprávy příjemci ve formě datového proudu a infrastruktura zpráv průběžně předává data od odesílatele do příjemce, jakmile bude k dispozici.
Nejběžnějším scénářem, ve kterém k takovým přenosům velkého datového obsahu dochází, jsou přenosy binárních datových objektů, které:
Nelze snadno rozdělit do sekvence zpráv.
Musí být doručena včas.
Nejsou k dispozici v plném rozsahu při zahájení převodu.
U dat, která tato omezení nemají, je obvykle lepší odesílat sekvence zpráv v rámci relace než jednu velkou zprávu. Další informace najdete v části Streamování dat dále v tomto tématu.
Při odesílání velkých objemů dat budete muset nastavit maxAllowedContentLength nastavení služby IIS (další informace najdete v tématu Konfigurace limitů požadavků služby IIS) a maxReceivedMessageSize nastavení vazby (například System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize nebo MaxReceivedMessageSize). Výchozí maxAllowedContentLength hodnota vlastnosti je 28,6 MB a vlastnost maxReceivedMessageSize má výchozí hodnotu 64 kB.
Kódování
Kódování definuje sadu pravidel o tom, jak prezentovat zprávy na drátě. Kodér implementuje takové kódování a zodpovídá za to, že na straně odesílatele převede paměť Message na bajtový datový proud nebo vyrovnávací paměť bajtů, která se dá odeslat přes síť. Na straně příjemce kodér změní posloupnost bajtů na zprávu v paměti.
WCF obsahuje tři kodéry a v případě potřeby umožňuje psát a připojovat vlastní kodéry.
Každá ze standardních vazeb zahrnuje předkonfigurovaný kodér, kdy vazby s předponou Net* používají binární kodér (včetně BinaryMessageEncodingBindingElement třídy), zatímco BasicHttpBinding ve WSHttpBinding výchozím nastavení používají kodér textových zpráv (prostřednictvím TextMessageEncodingBindingElement třídy).
| Element vazby kodéru | Popis |
|---|---|
| TextMessageEncodingBindingElement | Kodér textových zpráv je výchozím kodérem pro všechny vazby založené na protokolu HTTP a vhodnou volbou pro všechny vlastní vazby, u kterých je interoperabilita největší obavou. Tento kodér čte a zapisuje standardní textové zprávy SOAP 1.1/SOAP 1.2 bez speciálního zpracování binárních dat. System.ServiceModel.Channels.MessageVersion Pokud je vlastnost zprávy nastavena MessageVersion.Nonena , obálka obálky SOAP je vynechána z výstupu a pouze základní obsah zprávy je serializován. |
| MtomMessageEncodingBindingElement | Kodér zpráv MTOM je textový kodér, který implementuje speciální zpracování binárních dat a ve výchozím nastavení se nepoužívá v žádném ze standardních vazeb, protože se jedná o nástroj pro optimalizaci velkých a malých písmen. Pokud zpráva obsahuje binární data, která překračují prahovou hodnotu, kde kódování MTOM přináší výhodu, data se externalizují do části MIME za obálkou zprávy. Viz Povolení MTOM dále v této části. |
| BinaryMessageEncodingBindingElement | Binární kodér zpráv je výchozím kodérem pro vazby Net* a vhodnou volbou vždy, když obě komunikující strany jsou založené na WCF. Binární kodér zpráv používá binární formát XML .NET, což je binární reprezentace specifická pro XML Information Sets (Infosets), která obecně poskytuje menší nároky než ekvivalentní reprezentace XML 1.0 a kóduje binární data jako bajtový stream. |
Kódování textových zpráv je obvykle nejlepší volbou pro jakoukoli komunikační cestu, která vyžaduje interoperabilitu, zatímco kódování binárních zpráv je nejlepší volbou pro jakoukoli jinou komunikační cestu. Binární kódování zpráv obvykle přináší menší velikosti zpráv v porovnání s textem pro jednu zprávu a postupně i menší velikosti zpráv v průběhu komunikační relace. Na rozdíl od kódování textu nemusí binární kódování používat speciální zpracování binárních dat, například použití Base64, ale představuje bajty jako bajty.
Pokud vaše řešení nevyžaduje interoperabilitu, ale přesto chcete použít přenos HTTP, můžete BinaryMessageEncodingBindingElement vytvořit vlastní vazbu, která používá HttpTransportBindingElement třídu pro přenos. Pokud řada klientů ve vaší službě vyžaduje interoperabilitu, doporučujeme zveřejnit paralelní koncové body, které mají pro příslušné klienty povolené odpovídající možnosti přenosu a kódování.
Povolení MTOM
Pokud je požadavek na interoperabilitu a musí být odeslána velká binární data, pak kódování zpráv MTOM je alternativní strategie kódování, kterou můžete povolit u standardních BasicHttpBinding nebo WSHttpBinding vazeb nastavením příslušné MessageEncoding vlastnosti na Mtom nebo vytvořením MtomMessageEncodingBindingElement do CustomBinding. Následující ukázkový kód extrahovaný z ukázky kódování MTOM ukazuje, jak povolit MTOM v konfiguraci.
<system.serviceModel>
…
<bindings>
<wsHttpBinding>
<binding name="ExampleBinding" messageEncoding="Mtom"/>
</wsHttpBinding>
</bindings>
…
</system.serviceModel>
Jak už bylo zmíněno dříve, rozhodnutí o použití kódování MTOM závisí na datovém svazku, který odesíláte. Vzhledem k tomu, že MTOM je povolený na úrovni vazby, má povolení MTOM vliv na všechny operace v daném koncovém bodu.
Vzhledem k tomu, že kodér MTOM vždy generuje zprávu MIME/vícedílné kódování MTOM bez ohledu na to, jestli binární data končí externím, měli byste obecně povolit MTOM pouze pro koncové body, které vyměňují zprávy s více než 1 kB binárních dat. Kontrakty služeb navržené pro použití s koncovými body s povoleným MTOM by měly být v případě, že je to možné, omezené na určení takových operací přenosu dat. Související funkce řízení by se měly nacházet v samostatném kontraktu. Toto pravidlo "MTOM-only" se vztahuje pouze na zprávy odeslané prostřednictvím koncového bodu s podporou MTOM; Kodér MTOM může dekódovat a parsovat i příchozí zprávy, které nejsou MTOM.
Použití kodéru MTOM odpovídá všem ostatním funkcím WCF. Mějte na paměti, že toto pravidlo nemusí být možné sledovat ve všech případech, například v případě, že je vyžadována podpora relace.
Programovací model
Bez ohledu na to, které ze tří integrovaných kodérů používáte ve své aplikaci, je programovací prostředí shodné s ohledem na přenos binárních dat. Rozdíl spočívá v tom, jak WCF zpracovává data na základě jejich datových typů.
[DataContract]
class MyData
{
[DataMember]
byte[] binaryBuffer;
[DataMember]
string someStringData;
}
Při použití MTOM se předchozí kontrakt dat serializuje podle následujících pravidel:
Pokud
binaryBuffernenínulla jednotlivě obsahuje dostatek dat k odůvodnění režie externalizace MTOM (hlavičky MIME atd.) v porovnání s kódováním Base64, data se externalizují a přenášejí se zprávou jako binární část MIME. Pokud prahová hodnota není překročena, data se zakódují jako Base64.Řetězec (a všechny ostatní typy, které nejsou binární), je vždy reprezentován jako řetězec uvnitř textu zprávy bez ohledu na velikost.
Vliv na kódování MTOM je stejný, jestli používáte explicitní kontrakt dat, jak je znázorněno v předchozím příkladu, použijte seznam parametrů v operaci, vnořené datové kontrakty nebo přenos objektu kontraktu dat uvnitř kolekce. Pole bajtů jsou vždy kandidáty na optimalizaci a jsou optimalizovaná, pokud jsou splněny prahové hodnoty optimalizace.
Poznámka:
V kontraktech dat byste neměli používat System.IO.Stream odvozené typy. Data streamu by se měla sdělit pomocí modelu streamování, který je vysvětlený v následující části Streamovaná data.
Streamování dat
Pokud máte velké množství dat k přenosu, je režim přenosu streamování ve WCF vhodná alternativa k výchozímu chování ukládání do vyrovnávací paměti a zpracování zpráv v celé paměti.
Jak už bylo zmíněno dříve, povolte streamování pouze u velkých zpráv (s textovým nebo binárním obsahem), pokud data nelze segmentovat, pokud je nutné zprávu doručit včas, nebo pokud data ještě nejsou při zahájení přenosu plně dostupná.
Omezení
Pokud je povolené streamování, nemůžete použít velký počet funkcí WCF:
Digitální podpisy textu zprávy nelze provést, protože vyžadují výpočet hodnoty hash nad celým obsahem zprávy. Při streamování není obsah při vytváření a odesílání hlaviček zpráv plně dostupný, a proto nelze vypočítat digitální podpis.
Šifrování závisí na digitálních podpisech, aby ověřilo, že data byla správně rekonstruována.
Spolehlivé relace musí ukládat zprávy odeslané do vyrovnávací paměti v klientovi, aby bylo možné znovu doručit zprávy, pokud dojde ke ztrátě zprávy při přenosu, a musí před předáním zpráv do implementace služby zachovat pořadí zpráv v případě, že zprávy budou přijaty mimo pořadí.
Z těchto funkčních omezení můžete pro streamování použít pouze možnosti zabezpečení na úrovni přenosu a nemůžete zapnout spolehlivé relace. Streamování je k dispozici pouze s následujícími systémově definovanými vazbami:
Vzhledem k tomu, že základní přenosy NetTcpBindingNetNamedPipeBinding a mají vlastní spolehlivou podporu doručování a relací založených na připojení, na rozdíl od protokolu HTTP jsou tyto dvě vazby v praxi ovlivněny pouze minimálními omezeními.
Streamování není k dispozici s přenosem služby Řízení front zpráv (MSMQ), a proto není možné ho NetMsmqBindingMsmqIntegrationBinding použít s třídou. Přenos služby Řízení front zpráv podporuje pouze přenosy dat ve vyrovnávací paměti s omezenou velikostí zprávy, zatímco všechny ostatní přenosy nemají pro velkou většinu scénářů žádný praktický limit velikosti zpráv.
Streamování není také k dispozici při použití přenosu peer channel, takže není k dispozici s NetPeerTcpBinding.
Streamování a relace
Při streamování volání pomocí vazby založené na relaci se může zobrazit neočekávané chování. Všechna streamovaná volání se provádějí prostřednictvím jednoho kanálu (kanálu datagramu), který nepodporuje relace, i když je použitá vazba nakonfigurovaná tak, aby používala relace. Pokud více klientů provádí volání streamování do stejného objektu služby přes vazbu založenou na relaci a režim souběžnosti objektu služby je nastavený na jeden a jeho kontextový režim instance je nastaven na perSession, musí všechna volání procházet kanálem datagramu, takže se zpracovává vždy jen jedno volání. Jeden nebo více klientů pak může vypršel časový limit. Tento problém můžete vyřešit nastavením režimu kontextu instance objektu služby na Hodnotu PerCall nebo Souběžnost na Více.
Poznámka:
MaxConcurrentSessions v tomto případě nemá žádný vliv, protože je k dispozici pouze jedna relace.
Povolení streamování
Streamování můžete povolit následujícími způsoby:
Odesílat a přijímat požadavky v režimu streamování a přijímat a vracet odpovědi v režimu vyrovnávací paměti (StreamedRequest).
Odesílat a přijímat požadavky v režimu vyrovnávací paměti a přijímat a vracet odpovědi v streamovaného režimu (StreamedResponse).
Odesílání a příjem požadavků a odpovědí v streamovaném režimu v obou směrech (Streamed).
Streamování můžete zakázat nastavením režimu přenosu na Bufferedvýchozí nastavení pro všechny vazby. Následující kód ukazuje, jak nastavit režim přenosu v konfiguraci.
<system.serviceModel>
…
<bindings>
<basicHttpBinding>
<binding name="ExampleBinding" transferMode="Streamed"/>
</basicHttpBinding>
</bindings>
…
</system.serviceModel>
Při vytváření instance vazby v kódu je nutné nastavit odpovídající TransferMode vlastnost vazby (nebo transport binding element, pokud vytváříte vlastní vazbu) na jednu z dříve uvedených hodnot.
Streamování můžete zapnout pro žádosti a odpovědi nebo pro oba směry nezávisle na obou stranách komunikace, aniž by to mělo vliv na funkčnost. Měli byste ale vždy předpokládat, že přenosová velikost dat je tak významná, že povolení streamování je odůvodněné na obou koncových bodech komunikačního propojení. U komunikace mezi platformami, kde se jeden z koncových bodů neimplementuje se službou WCF, závisí možnost používat streamování na možnostech streamování platformy. Další výjimkou může být scénář řízený spotřebou paměti, kdy klient nebo služba musí minimalizovat pracovní sadu a může si dovolit pouze malé velikosti vyrovnávací paměti.
Povolení asynchronního streamování
Pokud chcete povolit asynchronní streamování, přidejte DispatcherSynchronizationBehavior do hostitele služby chování koncového bodu a nastavte jeho AsynchronousSendEnabled vlastnost na true. Přidali jsme také možnost skutečného asynchronního streamování na straně odesílání. To zlepšuje škálovatelnost služby ve scénářích, kdy streamuje zprávy více klientům, z nichž některé jsou pomalé čtení, pravděpodobně kvůli zahlcení sítě nebo vůbec nečtou. V těchto scénářích teď neblokujeme jednotlivá vlákna v jednotlivých klientech. Tím se zajistí, že služba dokáže zpracovat mnohem více klientů a tím zlepšit škálovatelnost služby.
Programovací model pro streamované přenosy
Programovací model pro streamování je jednoduchý. Pro příjem streamovaných dat zadejte kontrakt operace, který má jeden Stream vstupní parametr typu. Pro vrácení streamovaných dat vraťte Stream odkaz.
[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);
}
Operace Echo v předchozím příkladu přijímá a vrací datový proud, a proto by měla být použita u vazby s Streamed. Pro operaci RequestInfoje StreamedResponse nejvhodnější, protože vrací Streampouze . Jednosměrná operace je nejvhodnější pro StreamedRequest.
Všimněte si, že přidání druhého parametru do následujících Echo operací ProvideInfo způsobí, že se model služby vrátí zpět ke strategii vyrovnávací paměti a použije reprezentaci serializace datového proudu za běhu. Streamování koncových požadavků je kompatibilní pouze s jedním parametrem vstupního streamu.
Toto pravidlo se podobně vztahuje na kontrakty zpráv. Jak je znázorněno v následujícím kontraktu zprávy, můžete mít v kontraktu zprávy pouze jednoho člena těla, který je datový proud. Pokud chcete s datovým proudem sdělit další informace, musí se tyto informace přenášet do záhlaví zpráv. Text zprávy je vyhrazen výhradně pro obsah streamu.
[MessageContract]
public class UploadStreamMessage
{
[MessageHeader]
public string appRef;
[MessageBodyMember]
public Stream data;
}
Streamované přenosy končí a zpráva se zavře, když stream dosáhne konce souboru (EOF). Při odesílání zprávy (vrácení hodnoty nebo vyvolání operace) můžete předat FileStream infrastrukturu WCF a následně vyžádat všechna data z daného datového proudu, dokud nebude stream zcela přečtený a nedosáhl EOF. Pokud chcete přenést streamovaná data pro zdroj, který neexistuje, neexistuje žádná předdefinovaná Stream odvozená třída, vytvořte takovou třídu, překryjte tuto třídu nad zdrojem streamu a použijte ji jako argument nebo návratovou hodnotu.
Při příjmu zprávy wcf vytvoří datový proud přes základní obsah textu zprávy s kódováním Base64 (nebo odpovídající část MIME, pokud používá MTOM) a datový proud dosáhne EOF při čtení obsahu.
Streamování na úrovni přenosu funguje také s jakýmkoli jiným typem kontraktu zpráv (seznamy parametrů, argumenty kontraktu dat a explicitní kontrakt zpráv), ale protože serializace a deserializace takových typových zpráv vyžaduje ukládání do vyrovnávací paměti serializátorem, použití takových variant kontraktů není vhodné.
Zvláštní aspekty zabezpečení pro velká data
Všechny vazby umožňují omezit velikost příchozích zpráv, aby se zabránilo útokům na dostupnost služby. Například BasicHttpBindingzveřejňuje System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize vlastnost, která ohraničuje velikost příchozí zprávy, a tak také ohraničuje maximální množství paměti, ke které se přistupuje při zpracování zprávy. Tato jednotka je nastavená v bajtech s výchozí hodnotou 65 536 bajtů.
Bezpečnostní hrozba specifická pro scénář streamování velkých dat vyvolává odepření služby tím, že způsobí uložení dat do vyrovnávací paměti, když příjemce očekává, že se streamují. WCF například vždy uloží hlavičky PROTOKOLU SOAP zprávy do vyrovnávací paměti, takže útočník může vytvořit velkou škodlivou zprávu, která se skládá výhradně z hlaviček, aby vynutila ukládání dat do vyrovnávací paměti. Pokud je povolené streamování, MaxReceivedMessageSize může být nastavena na extrémně velkou hodnotu, protože příjemce nikdy neočekává, že celá zpráva bude uložena do vyrovnávací paměti najednou. Pokud je WCF nucena ukládat zprávu do vyrovnávací paměti, dojde k přetečení paměti.
Omezení maximální velikosti příchozích zpráv proto v tomto případě nestačí. Vlastnost MaxBufferSize je nutná k omezení paměti, kterou WCF vyrovnávací paměti. Při streamování je důležité ji nastavit na bezpečnou hodnotu (nebo ji ponechat na výchozí hodnotě). Předpokládejme například, že vaše služba musí přijímat soubory o velikosti až 4 GB a ukládat je na místní disk. Předpokládejme také, že paměť je omezená takovým způsobem, že najednou můžete ukládat do vyrovnávací paměti pouze 64 kB dat. Pak byste nastavili MaxReceivedMessageSize na 4 GB a MaxBufferSize na 64 kB. Také v implementaci služby musíte zajistit, abyste četli pouze z příchozího datového proudu v blocích 64 kB a nečetli další blok dat před tím, než byl předchozí blok zapsán na disk a zahozen z paměti.
Je také důležité vědět, že tato kvóta omezuje pouze ukládání do vyrovnávací paměti provedené WCF a nemůže vás chránit před jakýmkoli ukládáním do vyrovnávací paměti, které provádíte ve vlastní službě nebo implementaci klienta. Další informace odalšíchch
Poznámka:
Rozhodnutí o použití přenosů ve vyrovnávací paměti nebo streamovaných přenosech je místní rozhodnutí koncového bodu. Pro přenosy HTTP se režim přenosu nerozšířit mezi připojení ani na proxy servery a další zprostředkovatele. Nastavení režimu přenosu se neprojeví v popisu rozhraní služby. Po vygenerování klienta WCF do služby je nutné upravit konfigurační soubor pro služby určené k použití se streamovanými přenosy pro nastavení režimu. U přenosů TCP a pojmenovaných kanálu se režim přenosu rozšíří jako kontrolní výraz zásad.