通過WCF發送大型Xml字符串的最有效的解決方案？

我需要發送，並通過WCF接收包含幾個小領域，再加上一個大的XML字符串對象，像這樣：通過WCF發送大型Xml字符串的最有效的解決方案？

[DataContract] 
public class ServiceResponse 
{ 
    [DataMember] 
    public int Id { get; set;} 

    [DataMember] 
    public string Xml {get; set;} 
}

我必須使用一個基於HTTP綁定，但服務是內部的，所以合約dll將被共享。 Xml字符串可能會達到幾MB。該服務允許通過客戶端機器在服務器之間傳輸數據，因此第一次客戶端調用將檢索大量的Xml，將其保存到本地磁盤，然後第二次調用將數據從磁盤傳輸到另一個其他盒子上的另一個服務實例。所以客戶從字面上保存數據並轉發它，根本沒有邏輯或處理。

我需要最有效的機制 - 意味着小負載和快速 - 用於發送這些對象。

一些問題：

什麼是有效載荷發送大塊的XML的最有效的方法是什麼？
在使用BinaryFormatter通過線路發送然後使用Stream類型作爲服務操作中的參數之前，將對象序列化到MemoryStream有任何優勢嗎？
對於幾MB的消息，是否使用Streamed傳輸模式有什麼區別？

我不能使用像Protobuf-net（悲傷）的第三方庫。

欣賞任何意見...

來源

2013-02-25 MalcomTucker

你的陳述

是否有任何優勢，在使用BinaryFormatter的跨網發送，然後使用流類型作爲參數之前序列化對象到一個MemoryStream在服務操作中？

意味着你並不真的需要發送Xml，而是當前序列化爲Xml的對象。

如果是這樣，您將得到最快的序列化和使用Protocol Buffers而不是BinaryFormatter的最佳壓縮。

UPDATE

如果你指的是用BinaryFormatter的序列化ServiceResponse，Protocol Buffers的仍然會提供卓越的性能。

來源

2013-02-25 21:49:13

「幾個小領域，加一個大的Xml字符串「。他並不是說該對象被序列化爲XML，而是該對象包含一個xml字符串。話雖如此，我認爲你的答案仍然是正確的。 – aquinas 2013-02-25 21:51:49

不好意思，說不能用protobuf。在Xml上，不，這不是一個對象的表示，它實際上是Xml數據。所以我建議將Xml轉換爲二進制。 – MalcomTucker 2013-02-25 21:52:55

@MalcomTucker：當BinaryFormatter是一個選項時，爲什麼沒有protobuf？ – 2013-02-25 21:53:51

一開始，我將它作爲XmlNode而不是字符串：

[DataMember] 
public XmlNode Xml {get; set;}

避免了XML標籤的所有編碼。

來源

2013-02-26 08:18:20 Joe

數據傳輸=在服務器上準備時間+傳輸時間+在客戶端上處理的時間。

我猜測傳輸時間相當長。我已經有幸通過序列化XML來解決這個問題，zip-compressing生成的字符串，然後發送一個字節數組或將zip壓縮的字符串序列化爲base64。

它增加了處理時間，但遠不及未壓縮版本的傳輸時間。

的問題緩存上啓動應用程序人大常委會/啓動數據是數兆字節未經壓縮的，在世界各地使用，所以在低質量的連接區域，壓縮是必要的..

來源

2013-02-26 08:28:15

通過WCF發送大型Xml字符串的最有效的解決方案？

回答

相關問題