Aracılığıyla paylaş

Büyük Veriler ve Akış Yapma

  • Makale

Windows Communication Foundation (WCF), XML tabanlı bir iletişim altyapısıdır. XML verileri genellikle XML 1.0 belirtiminde tanımlanan standart metin biçiminde kodlandığından, bağlı sistem geliştiricileri ve mimarları genellikle ağ üzerinden gönderilen iletilerin kablo ayak izi (veya boyutu) konusunda kaygılanır ve XML'nin metin tabanlı kodlaması ikili verilerin verimli aktarımı için özel zorluklar doğurmaktadır.

Temel Dikkat Edilmesi Gerekenler

WCF için aşağıdaki bilgiler hakkında arka plan bilgileri sağlamak amacıyla, bu bölümde bağlı sistem altyapıları için genel olarak geçerli olan kodlamalar, ikili veriler ve akışla ilgili bazı genel endişeler ve önemli noktalar vurgulanır.

Kodlama Verileri: Metin ve İkili

Yaygın olarak ifade edilen geliştirici endişeleri, başlangıç etiketlerinin ve bitiş etiketlerinin yinelenen doğası nedeniyle ikili biçimlerle karşılaştırıldığında XML'nin önemli ek yüke sahip olduğu, sayısal değerlerin kodlamasının metin değerlerinde ifade edildiği için önemli ölçüde büyük olarak kabul edildiği ve bir metin biçimine eklemek için özel olarak kodlanması gerektiğinden ikili verilerin verimli bir şekilde ifade edilemeyeceği algısını içerir.

Bu ve benzer konuların çoğu geçerli olsa da, BIR XML Web hizmetleri ortamındaKI XML metniyle kodlanmış iletiler ile eski bir uzak yordam çağrısı (RPC) ortamındaki ikili kodlanmış iletiler arasındaki gerçek fark genellikle ilk dikkate alınması gerekenden çok daha azdır.

XML metni kodlanmış iletiler saydam ve "insan tarafından okunabilir" olsa da, ikili iletilerin karşılaştırması genellikle oldukça belirsizdir ve araçlar olmadan kod çözmesi zordur. Okunaklılıktaki bu fark, ikili iletilerin genellikle yükte satır içi meta verileri de taşıdığını göz ardı eder ve bu da XML metin iletilerinde olduğu gibi ek yük getirir. Bu, gevşek bağlama ve dinamik çağırma özellikleri sağlamayı hedefleyen ikili biçimler için özel olarak geçerlidir.

Ancak, ikili biçimler genellikle bu tür açıklayıcı meta veri bilgilerini aşağıdaki veri kayıtları için veri düzenini de bildiren bir "üst bilgi" içinde taşır. Daha sonra yük, en az ek yükle bu ortak meta veri bloğu bildirimini izler. Buna karşılık, XML her veri öğesini bir öğe veya öznitelik içine alır, böylece kapsayan meta veriler her serileştirilmiş yük nesnesi için tekrar tekrar eklenir. Sonuç olarak, her ikisi için de açıklayıcı meta verilerin ifade edilmesi gerektiğinden, metni ikili gösterimlerle karşılaştırırken tek bir serileştirilmiş yük nesnesinin boyutu benzerdir, ancak ikili biçim, genel yükün daha düşük olması nedeniyle aktarılan her ek yük nesnesiyle paylaşılan meta veri açıklamasından yararlanır.

Yine de sayılar gibi belirli veri türlerinde, düz metin gösterimi birkaç bayt daha küçük olabileceğinden düz metin yerine 128 bit ondalık türü gibi sabit boyutlu, ikili sayısal gösterimler kullanmanın dezavantajı olabilir. Metin verilerinin boyutu genellikle daha esnek XML metin kodlama seçeneklerinden de yararlanabilirken, bazı ikili biçimler varsayılan olarak 16 bit, hatta .NET İkili XML Biçimi için geçerli olmayan 32 bit Unicode olabilir.

Sonuç olarak, metin veya ikili arasında karar vermek, ikili iletilerin her zaman XML metin iletilerinden daha küçük olduğunu varsayma kadar kolay değildir.

XML metin iletilerinin net bir avantajı, standartlara dayalı olmaları ve en geniş birlikte çalışabilirlik seçenekleri ve platform desteği seçenekleri sunmalarıdır. Daha fazla bilgi için bu konunun devamında yer alan "Kodlamalar" bölümüne bakın.

İkili İçerik

İkili kodlamaların, sonuçta elde edilen ileti boyutu açısından metin tabanlı kodlamalardan üstün olduğu alanlardan biri, resimler, videolar, ses klipleri veya hizmetlerle tüketicileri arasında değişimi gereken başka bir opak, ikili veri biçimi gibi büyük ikili veri öğeleridir. Bu tür verileri XML metnine sığdırmak için yaygın yaklaşım, bunları Base64 kodlamasını kullanarak kodlamaktır.

Base64 ile kodlanmış bir dizede, her karakter özgün 8 bit verilerin 6 bitlerini temsil eder ve bu da kural tarafından yaygın olarak eklenen ek biçimlendirme karakterlerini (satır başı/satır beslemesi) saymayarak Base64 için 4:3 kodlama-ek yük oranıyla sonuçlanır. XML ile ikili kodlamalar arasındaki farkların önemi genellikle senaryoya bağlı olsa da, 500 MB'lık yük iletirken %33'ten fazla boyut kazancı genellikle kabul edilemez.

Bu kodlama ek yükünü önlemek için İleti İletim İyileştirme Mekanizması (MTOM) standardı, bir iletide yer alan büyük veri öğelerini dışlaştırmaya ve bunları özel kodlama olmadan iletiyle ikili veri olarak taşımaya olanak tanır. MTOM ile iletiler, ekleri veya eklenmiş içeriği (resimler ve diğer ekli içerik) olan Basit Posta Aktarım Protokolü (SMTP) e-posta iletilerine benzer şekilde değiştirilir; MTOM iletileri, kök bölümü gerçek SOAP iletisi olan çok parçalı/ilişkili MIME dizileri olarak paketlenir.

MTOM SOAP iletisi, kodlanmamış sürümünden değiştirildiğinden, ilgili MIME bölümlerine başvuran özel öğe etiketleri, ikili veri içeren iletideki özgün öğelerin yerini alır. Sonuç olarak SOAP iletisi, kendisiyle gönderilen MIME bölümlerine işaret ederek ikili içeriğe başvurur, ancak aksi takdirde yalnızca XML metin verilerini taşır. Bu model, iyi oluşturulmuş SMTP modeliyle yakından uyumlu olduğundan, MTOM iletilerini birçok platformda kodlamak ve kodunu çözmek için geniş bir araç desteği vardır ve bu da onu son derece birlikte çalışılabilir bir seçenek haline getirir.

Yine de Base64'de olduğu gibi MTOM, MIME biçimi için gerekli bazı ek yüklerle birlikte gelir, böylece MTOM kullanmanın avantajları yalnızca ikili veri öğesinin boyutu yaklaşık 1 KB'ı aştığında görülür. Ek yük nedeniyle, ikili yük bu eşiğin altında kalırsa MTOM ile kodlanmış iletiler, ikili veriler için Base64 kodlaması kullanan iletilerden daha büyük olabilir. Daha fazla bilgi için bu konunun devamında yer alan "Kodlamalar" bölümüne bakın.

Büyük Veri İçeriği

Kablo ayak izi bir yana, daha önce bahsedilen 500 MB'lık yük de hizmet ve müşteri için büyük bir yerel zorluk oluşturur. WCF varsayılan olarak iletileri arabelleğe alınan modda işler. Bu, iletinin tüm içeriğinin gönderilmeden önce veya alındıktan sonra bellekte bulunduğu anlamına gelir. Bu, çoğu senaryo için iyi bir strateji olsa da ve dijital imzalar ve güvenilir teslim gibi mesajlaşma özellikleri için gerekli olsa da, büyük iletiler sistemin kaynaklarını tüketebilir.

Büyük yüklerle başa çıkma stratejisi akıştır. İletiler, özellikle DE XML ile ifade edilenler genellikle nispeten küçük veri paketleri olarak düşünülse de, ileti birden çok gigabayt boyutunda olabilir ve bir veri paketinden daha fazla sürekli veri akışına benzeyebilir. Veriler arabelleğe alınan mod yerine akış modunda aktarıldığında, gönderen ileti gövdesinin içeriğini bir akış biçiminde alıcıya sağlar ve ileti altyapısı, kullanılabilir hale geldikçe verileri gönderenden alıcıya sürekli olarak iletir.

Bu tür büyük veri içerik aktarımlarının gerçekleştiği en yaygın senaryo, aşağıdaki ikili veri nesnelerinin aktarımlarıdır:

  • bir ileti dizisine kolayca bölünemez.

  • Zamanında teslim edilmelidir.

  • Aktarım başlatıldığında tamamen kullanılamaz.

Bu kısıtlamalara sahip olmayan veriler için genellikle bir oturum kapsamındaki iletilerin dizilerini göndermek, büyük bir iletiden daha iyidir. Daha fazla bilgi için bu konunun devamında yer alan "Akış Verileri" bölümüne bakın.

Büyük miktarda veri gönderirken IIS ayarını (daha fazla bilgi için bkz. IIS İstek Sınırlarını Yapılandırma) ve maxReceivedMessageSize bağlama ayarını (örneğin System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize veya MaxReceivedMessageSize) ayarlamanız maxAllowedContentLength gerekir. maxAllowedContentLength Özellik varsayılan olarak 28,6 MB ve maxReceivedMessageSize özellik varsayılan olarak 64 KB'tır.

Kodlamalar

Kodlama, iletilerin kabloda nasıl sunlanacağına ilişkin bir dizi kuralı tanımlar. Kodlayıcı böyle bir kodlama uygular ve gönderen tarafında, bir bellek Message içini ağ üzerinden gönderilebilen bir bayt akışına veya bayt arabelleğine dönüştürmeden sorumludur. Alıcı tarafında, kodlayıcı bir bayt dizisini bellek içi iletiye dönüştürür.

WCF üç kodlayıcı içerir ve gerekirse kendi kodlayıcılarınızı yazmanızı ve takmanızı sağlar.

Standart bağlamaların her biri önceden yapılandırılmış bir kodlayıcı içerir; bu nedenle Net* ön ekini içeren bağlamalar ikili kodlayıcıyı (sınıfı dahil ederek BinaryMessageEncodingBindingElement ) BasicHttpBindingWSHttpBinding ve sınıfları ise metin iletisi kodlayıcısını (sınıf aracılığıyla TextMessageEncodingBindingElement ) varsayılan olarak kullanır.

Kodlayıcı bağlama öğesi Açıklama
TextMessageEncodingBindingElement Metin iletisi kodlayıcısı, tüm HTTP tabanlı bağlamalar için varsayılan kodlayıcıdır ve birlikte çalışabilirliğin en yüksek sorun olduğu tüm özel bağlamalar için uygun seçenektir. Bu kodlayıcı, ikili veriler için özel bir işleme olmadan standart SOAP 1.1/SOAP 1.2 metin iletilerini okur ve yazar. bir iletinin System.ServiceModel.Channels.MessageVersion özelliği olarak MessageVersion.Noneayarlanırsa, SOAP zarf sarmalayıcısı çıkıştan atlanır ve yalnızca ileti gövdesi içeriği serileştirilir.
MtomMessageEncodingBindingElement MTOM ileti kodlayıcı, ikili veriler için özel işleme uygulayan bir metin kodlayıcıdır ve standart bağlamaların hiçbirinde varsayılan olarak kullanılmaz çünkü bu kesinlikle büyük/küçük harf iyileştirme yardımcı programıdır. İleti, MTOM kodlamasının avantaj sağladığı eşiği aşan ikili veriler içeriyorsa, veriler ileti zarfının ardından bir MIME bölümünde dışlanır. Bu bölümün devamında MTOM'i etkinleştirme bölümüne bakın.
BinaryMessageEncodingBindingElement İkili ileti kodlayıcı, Net* bağlamaları için varsayılan kodlayıcıdır ve her iki iletişim kuran taraf da WCF'yi temel alırsa uygun seçimdir. İkili ileti kodlayıcı, genellikle eşdeğer XML 1.0 gösteriminden daha küçük bir ayak izi veren ve ikili verileri bayt akışı olarak kodlayan XML Bilgi Kümeleri (Infosets) için Microsoft'a özgü bir ikili gösterim olan .NET İkili XML Biçimini kullanır.

Metin iletisi kodlaması genellikle birlikte çalışabilirlik gerektiren herhangi bir iletişim yolu için en iyi seçimdir, ikili ileti kodlama ise diğer iletişim yolları için en iyi seçenektir. İkili ileti kodlaması genellikle tek bir ileti için metne kıyasla daha küçük ileti boyutları ve iletişim oturumu süresi boyunca daha da küçük ileti boyutları verir. Metin kodlamadan farklı olarak, ikili kodlamanın base64 gibi ikili veriler için özel işleme kullanması gerekmez, ancak baytları bayt olarak temsil eder.

Çözümünüz birlikte çalışabilirlik gerektirmez, ancak yine de HTTP aktarımını kullanmak istiyorsanız, öğesini aktarım için sınıfını HttpTransportBindingElement kullanan özel bir bağlamaya oluşturabilirsinizBinaryMessageEncodingBindingElement. Hizmetinizdeki bir dizi istemci birlikte çalışabilirlik gerektiriyorsa, her birinin ilgili istemciler için uygun aktarım ve kodlama seçeneklerinin etkinleştirildiği paralel uç noktaları kullanıma sunmanız önerilir.

MTOM'i etkinleştirme

Birlikte çalışabilirlik bir gereksinim olduğunda ve büyük ikili verilerin gönderilmesi gerektiğinde, MTOM ileti kodlaması, ilgili MessageEncoding özelliği olarak ayarlayarak veya içine oluşturarak MtomMessageEncodingBindingElementCustomBindingstandart BasicHttpBinding veya WSHttpBinding bağlamalarda etkinleştirebileceğiniz alternatif kodlama stratejisidirMtom. MTOM Kodlama örneğinden ayıklanan aşağıdaki örnek kod, MTOM'un yapılandırmada nasıl etkinleştirileceği gösterir.

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

Daha önce belirtildiği gibi, MTOM kodlamasını kullanma kararı gönderdiğiniz veri hacmine bağlıdır. Ayrıca, MTOM bağlama düzeyinde etkinleştirildiğinden, MTOM'in etkinleştirilmesi belirli bir uç noktadaki tüm işlemleri etkiler.

MTOM kodlayıcı, ikili verilerin dışlaştırılıp dışlaştırılmadığından bağımsız olarak her zaman MTOM ile kodlanmış bir MIME/çok parçalı ileti yaydığından, MTOM'i genellikle yalnızca 1 KB'tan fazla ikili veri içeren ileti alışverişinde bulunan uç noktalar için etkinleştirmeniz gerekir. Ayrıca, MTOM özellikli uç noktalarla kullanılmak üzere tasarlanan hizmet sözleşmeleri, mümkün olduğunda bu tür veri aktarım işlemlerini belirtmek için kısıtlanmalıdır. İlgili denetim işlevselliği ayrı bir sözleşmede bulunmalıdır. Bu "yalnızca MTOM" kuralı yalnızca MTOM özellikli uç nokta üzerinden gönderilen iletiler için geçerlidir; MTOM kodlayıcı, MTOM olmayan gelen iletileri de kodlayabilir ve ayrıştırabilir.

MTOM kodlayıcısını kullanmak diğer tüm WCF özellikleriyle uyumlu olur. Oturum desteğinin gerekli olduğu durumlar gibi her durumda bu kuralı gözlemlemeyebileceğini unutmayın.

Programlama Modeli

Uygulamanızda hangi üç yerleşik kodlayıcıyı kullandığınızdan bağımsız olarak, programlama deneyimi ikili verilerin aktarılmasıyla aynıdır. Fark, WCF'nin verileri kendi veri türlerine göre işleme şeklidir.

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

MTOM kullanılırken, önceki veri sözleşmesi aşağıdaki kurallara göre serileştirilir:

  • null Değilse binaryBuffer ve tek tek, Base64 kodlamasıyla karşılaştırıldığında MTOM dışlaştırma ek yükünü (MIME üst bilgileri vb.) haklı çıkarmak için yeterli veri içeriyorsa, veriler dışlaştırılır ve iletiyle birlikte ikili MIME bölümü olarak taşınır. Eşik aşılmazsa veriler Base64 olarak kodlanır.

  • Dize (ve ikili olmayan diğer tüm türler) boyutu ne olursa olsun ileti gövdesinde her zaman bir dize olarak temsil edilir.

Yukarıdaki örnekte gösterildiği gibi açık bir veri sözleşmesi kullanmanız, bir işlemde parametre listesi kullanmanız, iç içe veri anlaşmaları olması veya bir veri sözleşmesi nesnesini bir koleksiyon içinde aktarmanız fark etmeksizin MTOM kodlaması üzerindeki etkisi aynıdır. Bayt dizileri her zaman iyileştirme adayıdır ve iyileştirme eşikleri karşılanıyorsa iyileştirilir.

Not

Veri anlaşmaları içinde türetilmiş türler kullanmamalısınız System.IO.Stream . Akış verileri, aşağıdaki "Akış Verileri" bölümünde açıklanan akış modeli kullanılarak iletilmelidir.

Akış Verileri

Aktarabileceğiniz çok fazla veri olduğunda, WCF'deki akış aktarım modu, iletileri bellekte tamamen arabelleğe alma ve işlemenin varsayılan davranışına uygun bir alternatiftir.

Daha önce de belirtildiği gibi, veriler bölümlenemediğinde, iletinin zamanında teslim edilmesi gerekiyorsa veya aktarım başlatıldığında veriler henüz tam olarak kullanılamıyorsa, yalnızca büyük iletiler (metin veya ikili içerikle) için akışı etkinleştirin.

Kısıtlamalar

Akış etkinleştirildiğinde önemli sayıda WCF özelliği kullanamazsınız:

  • İleti gövdesi için dijital imzalar, ileti içeriğinin tamamı üzerinde bir karma hesaplama gerektirdiğinden gerçekleştirilemiyor. Akışla, ileti üst bilgileri oluşturulup gönderildiğinde içerik tam olarak kullanılamaz ve bu nedenle dijital imza hesaplanamaz.

  • Şifreleme, verilerin doğru şekilde yeniden yapılandırıldığını doğrulamak için dijital imzalara bağlıdır.

  • Güvenilir oturumlar, aktarım sırasında bir ileti kaybolursa yeniden teslim için istemcide gönderilen iletileri arabelleğe almalıdır ve iletilerin sıra dışı alınması durumunda ileti sırasını korumak için iletileri hizmet uygulamasına teslim etmeden önce hizmette tutması gerekir.

Bu işlevsel kısıtlamalar nedeniyle, akış için yalnızca aktarım düzeyi güvenlik seçeneklerini kullanabilirsiniz ve güvenilir oturumları açamazsınız. Akış yalnızca aşağıdaki sistem tanımlı bağlamalarla kullanılabilir:

temel alınan ve NetNamedPipeBinding aktarımları, HTTP'nin NetTcpBinding aksine, doğal güvenilir teslim ve bağlantı tabanlı oturum desteğine sahip olduğundan, bu iki bağlama pratikte bu kısıtlamalardan yalnızca en az düzeyde etkilenir.

Akış Message Queuing (MSMQ) aktarımıyla kullanılamaz ve bu nedenle veya MsmqIntegrationBinding sınıfıyla NetMsmqBinding kullanılamaz. Message Queuing aktarımı yalnızca kısıtlanmış ileti boyutuna sahip arabelleğe alınan veri aktarımlarını desteklerken, diğer tüm aktarımlarda senaryoların büyük çoğunluğu için herhangi bir pratik ileti boyutu sınırı yoktur.

Akış, Eş Kanal aktarımı kullanılırken de kullanılamaz, bu nedenle ile NetPeerTcpBindingkullanılamaz.

Akış ve Oturumlar

Oturum tabanlı bağlama ile çağrı akışı yaparken beklenmeyen davranışlarla karşılaşabilirsiniz. Tüm akış çağrıları, kullanılan bağlama oturumları kullanacak şekilde yapılandırılmış olsa bile oturumları desteklemeyen tek bir kanal (veri birimi kanalı) üzerinden yapılır. Birden çok istemci oturum tabanlı bağlama üzerinden aynı hizmet nesnesine akış çağrıları yaparsa ve hizmet nesnesinin eşzamanlılık modu tek olarak ayarlanırsa ve örnek bağlam modu PerSession olarak ayarlanırsa, tüm çağrıların veri birimi kanalından geçmesi gerekir ve bu nedenle tek seferde yalnızca bir çağrı işlenir. Bundan sonra bir veya daha fazla istemci zaman aşımına uğradı. Hizmet nesnesinin Örnek Bağlam Modu'nu PerCall veya Eşzamanlılık'ı Birden Çok olarak ayarlayarak bu sorunu geçici olarak çözebilirsiniz.

Not

Yalnızca bir "oturum" olduğundan MaxConcurrentSessions bu durumda hiçbir etkiye sahip değildir.

Akış Etkinleştirme

Akışı aşağıdaki yollarla etkinleştirebilirsiniz:

  • İstekleri akış modunda gönderip kabul edin ve arabelleğe alınan modda (StreamedRequest ) yanıtları kabul edin ve döndürin.

  • İstekleri arabelleğe alınan modda gönderip kabul edin ve akışlı modda (StreamedResponse ) yanıtları kabul edin ve döndürin.

  • Akış modunda her iki yönde de istek ve yanıt gönderip alın. (Streamed).

Aktarım modunu Bufferedtüm bağlamalarda varsayılan ayar olan olarak ayarlayarak akışı devre dışı bırakabilirsiniz. Aşağıdaki kod, yapılandırmada aktarım modunun nasıl ayarlandığını gösterir.

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

Kodda bağlamanızın örneğini oluştururken bağlamanın ilgili TransferMode özelliğini (veya özel bağlama oluşturuyorsanız aktarım bağlama öğesini) daha önce bahsedilen değerlerden birine ayarlamanız gerekir.

İstekler ve yanıtlar için veya her iki yön için akışı, işlevselliği etkilemeden iletişim eden tarafların her iki tarafında bağımsız olarak açabilirsiniz. Ancak, aktarılan veri boyutunun, bir iletişim bağlantısının her iki uç noktasında da akışı etkinleştirmenin iki yana yaslanması için her zaman önemli olduğunu varsaymalısınız. Uç noktalardan birinin WCF ile uygulanmadığı platformlar arası iletişim için, akışın kullanılabilmesi platformun akış özelliklerine bağlıdır. Bir diğer nadir özel durum, bir istemcinin veya hizmetin çalışma kümesini en aza indirmesi gereken ve yalnızca küçük arabellek boyutlarını karşılayabildiği bellek tüketimi temelli bir senaryo olabilir.

Zaman Uyumsuz Akışı Etkinleştirme

Zaman uyumsuz akışı etkinleştirmek için hizmet konağına DispatcherSynchronizationBehavior uç nokta davranışını ekleyin ve özelliğini olarak trueayarlayınAsynchronousSendEnabled. Gönderme tarafına gerçek zaman uyumsuz akış özelliğini de ekledik. Bu, ağ tıkanıklığı nedeniyle veya hiç okumadığı için bazılarında okuması yavaş olan birden çok istemciye ileti akışı yaptığı senaryolarda hizmetin ölçeklenebilirliğini artırır. Bu senaryolarda artık istemci başına hizmetteki tek tek iş parçacıklarını engellemeyiz. Bu, hizmetin daha fazla istemci işleyebilmesini ve böylece hizmetin ölçeklenebilirliğini geliştirmesini sağlar.

Akışlı Aktarımlar için Programlama Modeli

Akış için programlama modeli basittir. Akışa alınan verileri almak için, tek Stream tür giriş parametresine sahip bir işlem sözleşmesi belirtin. Akış verilerini döndürmek için bir Stream başvuru döndür.

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

Önceki örnekteki işlem Echo bir akış alır ve döndürür ve bu nedenle ile Streamedbir bağlamada kullanılmalıdır. yalnızca bir Streamdöndürdüğünden, işlemi RequestInfoStreamedResponse için en uygun yöntemdir. Tek yönlü işlem için StreamedRequesten uygun yöntemdir.

Aşağıdaki Echo veya ProvideInfo işlemlere ikinci bir parametre eklenmesinin hizmet modelinin arabelleğe alınan bir stratejiye geri dönmesine ve akışın çalışma zamanı serileştirme gösterimini kullanmasına neden olduğunu unutmayın. Yalnızca tek bir giriş akışı parametresine sahip işlemler uçtan uca istek akışıyla uyumludur.

Bu kural, ileti sözleşmeleri için de benzer şekilde geçerlidir. Aşağıdaki ileti sözleşmesinde gösterildiği gibi, ileti sözleşmenizde akış olan yalnızca tek bir gövde üyeniz olabilir. Akışla ek bilgi iletmek istiyorsanız, bu bilgiler ileti üst bilgilerinde taşınan bir bilgi olmalıdır. İleti gövdesi yalnızca akış içeriği için ayrılmıştır.

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

Akış aktarımları sona erer ve akış dosyanın sonuna (EOF) ulaştığında ileti kapatılır. İleti gönderirken (bir değer döndürürken veya bir işlemi başlatırken), bir geçirebilirsiniz FileStream ve WCF altyapısı daha sonra akış tamamen okunup EOF'ye ulaşana kadar bu akıştaki tüm verileri çeker. Önceden oluşturulmuş Stream böyle bir türetilmiş sınıfın mevcut olmadığı kaynağa yönelik akış verilerini aktarmak için, böyle bir sınıf oluşturup bu sınıfı akış kaynağınız üzerine yerleştirin ve bunu bağımsız değişken veya dönüş değeri olarak kullanın.

bir ileti alınırken, WCF Base64 ile kodlanmış ileti gövdesi içeriği (veya MTOM kullanılıyorsa ilgili MIME bölümü) üzerinden bir akış oluşturur ve içerik okunduğunda akış EOF'ye ulaşır.

Aktarım düzeyi akış, başka herhangi bir ileti sözleşmesi türüyle de (parametre listeleri, veri sözleşmesi bağımsız değişkenleri ve açık ileti sözleşmesi) çalışır, ancak bu tür tür iletilerin seri hale getirilmesi ve seri durumdan çıkarılması seri hale getirici tarafından arabelleğe almayı gerektirdiğinden, bu tür sözleşme çeşitlemelerinin kullanılması önerilmez.

Büyük Veriler için Özel Güvenlik Konuları

Tüm bağlamalar, hizmet reddi saldırılarını önlemek için gelen iletilerin boyutunu kısıtlamanıza olanak sağlar. BasicHttpBindingörneğin, gelen iletinin boyutunu sınırlayan bir System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize özelliğini kullanıma sunar ve bu nedenle ileti işlenirken erişilen en fazla bellek miktarını sınırlar. Bu birim, varsayılan değeri 65.536 bayt olan bayt cinsinden ayarlanır.

Büyük veri akışı senaryosuna özgü bir güvenlik tehdidi, alıcı akışa alınmasını beklediğinde verilerin arabelleğe alınmasına neden olarak hizmet reddini tetikler. Örneğin, WCF her zaman bir iletinin SOAP üst bilgilerini arabelleğe alır ve böylece bir saldırgan verilerin arabelleğe alınmasına zorlamak için tamamen üst bilgilerden oluşan büyük bir kötü amaçlı ileti oluşturur. Akış etkinleştirildiğinde, MaxReceivedMessageSize alıcı hiçbir zaman iletinin tamamının aynı anda bellekte arabelleğe alınmasını beklemediğinden son derece büyük bir değere ayarlanabilir. WCF, iletiyi arabelleğe almak zorunda kalırsa bellek taşması oluşur.

Bu nedenle, en fazla gelen ileti boyutunu kısıtlamak bu durumda yeterli değildir. MaxBufferSize özelliği, WCF'nin arabelleğe alan belleği kısıtlamak için gereklidir. Akış sırasında bunu güvenli bir değere ayarlamak (veya varsayılan değerde tutmak) önemlidir. Örneğin, hizmetinizin boyutu 4 GB'a kadar olan dosyaları alması ve yerel diskte depolaması gerektiğini varsayalım. Ayrıca belleğinizin aynı anda yalnızca 64 KB veriyi arabelleğe alabilmeniz için kısıtlandığını varsayalım. Ardından değerini MaxReceivedMessageSize 4 GB ve MaxBufferSize 64 KB olarak ayarlayabilirsiniz. Ayrıca, hizmet uygulamanızda yalnızca 64 KB öbekler halinde gelen akıştan okumanız ve öncekinin diske yazıp bellekten atılmasından önce sonraki öbeği okumadığınızdan emin olmanız gerekir.

Bu kotanın yalnızca WCF tarafından yapılan arabelleğe almayı sınırladığını ve sizi kendi hizmetinizde veya istemci uygulamanızda yaptığınız herhangi bir arabelleğe karşı koruyamayacağını anlamak da önemlidir. Güvenlikle ilgili ek konular hakkında daha fazla bilgi için bkz . Veriler için GüvenlikLe İlgili Önemli Noktalar.

Not

Arabelleğe alınan veya akışlı aktarımları kullanma kararı, uç noktanın yerel bir kararıdır. HTTP aktarımları için aktarım modu bir bağlantı veya ara sunuculara ve diğer aracılara yayılmaz. Aktarım modunun ayarlanması hizmet arabiriminin açıklamasına yansıtılmaz. Bir hizmete WCF istemcisi oluşturduktan sonra, modu ayarlamak üzere akış aktarımlarıyla kullanılması amaçlanan hizmetler için yapılandırma dosyasını düzenlemeniz gerekir. TCP ve adlandırılmış kanal aktarımları için aktarım modu bir ilke onayı olarak yayılır.

Ayrıca bkz.