如何在兩臺計算機之間傳遞大量數據

將大量數據從一臺計算機傳輸到另一臺計算機的可能選項不在同一局域網中。數據量大約是100Mb解壓縮和2Mb壓縮？另一個要求是，當我爲此創建一個服務器時（使用C＃），Java客戶端應該能夠使用它。如何在兩臺計算機之間傳遞大量數據

WCF是否支持這樣的事情？但是如果Java客戶端無法使用它，我不感興趣。
這裏有什麼其他策略？

來源

2010-08-25 Sergej Andrejev

互聯網管道應該做的工作 – 2010-08-25 08:03:34

我只是使用一些常見的HTTP或FTP，因爲會有很多現有的庫來做到這一點，你幾乎保證沒有兼容性問題。對於這些協議，2MB並不是不合理的大量數據。

來源

2010-08-25 07:51:36

HTTP是否支持gziped請求？ – 2010-08-25 07:52:50

當然，您可以在將數據包含在請求正文中之前對它們進行gzip壓縮。（但我不認爲你可以在請求中使用Content-Encoding標頭。） – 2010-08-25 16:52:02

在C＃中，您可以將對象序列化爲XML並傳輸，另一方面，您可以將XML反序列化爲對象。

就文件大小而言，您可以傳輸爲壓縮或7z ..並在解析xml之前在客戶端解壓縮。

來源

2010-08-25 07:46:59 ace

WCF支持SOAP幷包含用於XHTTP的可選JSON序列化。還有其他機制，但他們是以MS爲導向的。您將可以輕鬆地使用您創建的服務。但是，您將不得不考慮如何對數據進行編碼，因爲它會以非二進制數據友好的方式（XML/JSON）觸及導線。

您可能希望改爲創建一個簡單的http處理程序，它可以使用適當的MIME頭文件等直接以zip形式返回數據。您應該可以使用Java客戶端直接打開該數據庫。

來源

2010-08-25 07:53:00 Ashley

XMPP是另一種選擇。您需要另一臺服務器，但這可能是一個優點：客戶端不需要知道服務器IP地址，服務器和客戶端只需連接到XMPP服務器即可交換消息和文件。

相關鏈接（用於Java）：

來源

2010-08-25 08:02:35

你沒有提到你想送什麼類型的數據。所以爲了保持簡單，我會假設你有可以轉換爲字節數組的數據流。流的內容必須採用C＃和Java都可以理解的格式！

最好的選擇是用GZip流壓縮你的數據流。 Java應該支持Gzip。比你可以發送流轉換爲字節數組作爲您的WCF服務操作的響應。您可以使用默認的文本編碼將字節數組轉換爲Base64編碼的字符串。如果您的Java客戶端支持MTOM（它是Java支持的標準），那麼您可以使用使用較小消息的MTOM編碼。

如果您沒有具有衆所周知的內容格式的流，則可以使用某種自定義數據。對於自定義數據，您必須使用XML的可互操作傳輸格式。使用XML將進一步增加數據的大小。在這種情況下，您應該考慮將您的數據傳輸分成幾個呼叫。您還可以嘗試在IIS 7.x中承載您的WCF服務，並利用其內置功能 - 動態內容壓縮。如果您的Java客戶端使用HTTP Accept-Encoding標頭設置爲compress進行調用，則gzip會自動壓縮響應。請注意，只有.NET 4.0 WCF客戶端才能使用此類服務。

來源

2010-08-25 08:27:41

這是一個有趣的問題。這個問題很容易回答。但有趣的是，這類問題是新的，它們之前並不存在。讓我解釋一下，但首先我會回答你的問題：

你應該使用舊時尚TCP流創建服務器和客戶端。爲了不佔用帶寬，你需要以某種方式壓縮流，這裏使用你能找到的最常見的壓縮算法之一（任何人都說Zip？）。現在你有一個獨立於語言的協議。任何語言的客戶都會工作，完成任務。另外爲了保持它的跨平臺，不要選擇最好的壓縮方式，選擇最常見的壓縮方法（這將足夠好）。

現在爲什麼這類問題很有趣，他們展示了一些關於面向對象的大規模問題。人們理解和使用巨大的框架，並詢問這個或那個框架是否可以爲他們執行這個或那個簡單的任務。在這裏，我們失去了根基，我們失去了事物的內在運作，它不是用錘子而是用核導彈擊中釘子。它超出了目標，並且會產生巨大的應用程序，佔用空間大，性能往往不佳。

我相信這個問題在OOP被完全採用後有所增加。這就像新程序員只想學習這些新的大框架，並且框架模糊了世界的觀點。大框架絕對沒有錯，它們很棒，但我認爲在掌握基本知識之前開始使用它們是錯誤的。這就像學習使用NASA航天飛機而不是學校版的塞斯納私人飛機。

來源

2010-08-25 12:14:47 UnixShadow

如何在兩臺計算機之間傳遞大量數據

回答

相關問題