Netty應用程序設計爲大量的小型轉移

Question

我想要決定如何設計一個Netty應用程序與我認爲是一些不尋常的要求。基本上有一個客戶端發起請求。該請求翻譯成英文爲「Go遞歸地在目錄/ whatever /下遞歸獲取一些小文件，我可以告訴你的關於這些文件的是他們的名字介於AAAAAAA.bin和CCCCCCC.bin之間」。

因此，服務器需要採取請求，並開始掃描服務器端的一些目錄，並開始快速流式傳輸所有這些小文件。性能至關重要，但確保我已收到AAAAAAA.bin和CCCCCCC.bin之間的所有文件。

因此，如果客戶端和服務器基本上是異步的，它會是一個好的設計嗎？換句話說，客戶端啓動對話，發送請求並簡單地接收確認UUID令牌或其他內容，然後服務器開始收集文件（可能每個線程一個），聯繫客戶端，並沿着一個文件傳遞一個文件與UUID？我在想，客戶端可以定期詢問服務器「你是否完成了匹配UUID令牌/ sometoken /？的請求？

我不太確定如何配置它，因爲客戶端和服務器都會是開始對話。或者，也許別人有更好的設計理念？再次，性能（從請求發起總時間的所有文件傳輸完成）是至關重要的。

謝謝！

Answer 1

假設你參與協議的完全控制（即你不限於HTTP），那麼可能類似於

1. 客戶端連接到服務器併發送目錄請求。如果客戶端正在重新啓動，則中止傳輸是發送帶有來自2
2. 的令牌的請求。服務器使用此傳輸的唯一令牌進行響應。如果正在重新啓動傳輸，它將使用來自1的令牌進行響應。服務器標識此傳輸的所有文件，爲每個文件指定一個唯一的ID，並將該文件集與來自2的標記相關聯（可能需要先確定文件生成令牌）
3. 對於每個文件，服務器都會發送一個包含文件長度，唯一文件ID，文件（以及任何其他信息，如文件名）的消息。服務器儘快發送每個文件並且不等待來自5的確認。
4. 客戶端使用唯一文件ID確認接收的每個文件。
5. 發送最後一個文件後，服​​務器發送「傳輸完成」消息。

上述所有通信都發生在單個通道上。重要的一點是，您正在流式傳輸文件並異步接收確認，從而減輕網絡延遲。

如果你有很多文件，我不會使用每個文件的線程。也許每個要發送文件的線程池都被添加到作業隊列中，或者每個唯一目錄可能被添加到作業隊列中，並且一個線程一次處理一個目錄。您可能需要將呼叫同步到channel.write（..）。我還假設客戶端無法接收文件是可以的。

其實，我最初只會用一個線程來讀取文件。一旦它可靠工作，看看是否有多個線程使您可以通過保持網絡繁忙（即不等待讀取下一個文件）來提高性能。

寫入通道時，我可能會寫入包含文件詳細信息的對象（唯一標識符，足夠小的文件數據，文件名如果需要），然後使用可將對象轉換爲通道緩衝區/從通道緩衝區轉換爲對象的編解碼器。

根據您的具體情況客戶端可以打開多個連接到服務器，你可以分配到一個特定的文件讀取線程，從而避免任何通道同步問題的連接。你可能會得到一些性能增加的方式，但最有可能的，你只看到連接之間共享的可用帶寬。