用於低級UDP消息傳遞系統的ByteBuffers的替代方案

Question

我正在為加密的P2P架構開發一個低級UDP消息傳遞層，如果有興趣，可以在github頁面上閱讀更多相關信息。

我已經構建了一個簡潔的序列化框架，將POJO轉換為緊湊的ByteBuffers，以及使用對稱和非對稱加密的各種庫，相當輕松。

我現在正致力於消息傳遞框架，它使用動態代理來實現與GWT的RPC機制類似的功能。

我的問題是早期我決定使用ByteBuffers讀取和寫入序列化機制。 我現在發現這有幾個問題：

• 您需要在序列化對象之前知道最大字節緩沖區大小
• 它們是可變的，這使它們容易出錯
• 它們與DatagramPacket不是特別兼容，而且DatagramChannels令人困惑

任何人都可以建議在此框架中實現序列化的替代方法嗎？

Answer 1

可能值得一看KryoNet - 它可能適合您的需求，或者您也可以看看它們是如何做的。

順便提一下，它們確實使用ByteBuffers進行TCP和UDP連接。 我認為訣竅是從ByteBuffers中抽象出來，這樣任何客戶端代碼都可以與POJO一起使用。 要做到這一點，你顯然需要有一個可以將大對象分解為多個緩沖寫入的邏輯。

我認為你實際上仍然想要ByteBuffers因為它們非常快，支持各種原生加速技巧，因為無論喜歡與否，最終你需要在高吞吐量的IO環境中處理緩沖....

Answer 2

任何人都可以建議在此框架中實現序列化的替代方法嗎？

為什么選擇，我在這里解決您的主要問題：

• 您需要在序列化對象之前知道最大字節緩沖區大小

為什么ByteBuffer的最大尺寸？ 您可以使用緩沖池。 您應該准備將對象拆分為多個數據包。 一個數據包 - 一個對象不適用於較大的對象。 序列化是一個有趣的觀點：通常這就是它變得混亂的地方。 你需要一些不錯的協議層（+ - 重發數據包等）

• 它們是可變的，這使它們容易出錯

出於性能原因，你確實希望它們是可變的。 我從來沒有遇到過他們可變的問題。 您可能也想要直接緩沖區。 謝天謝地，他們變異，因為他們不便宜（de）分配。 直接緩沖區直接映射到OS代碼中（查看sun.nio.ch.DatagramDispatcher）

• 它們與DatagramPacket不是特別兼容，而且DatagramChannels令人困惑。

它們沒問題，您只需將對象拆分為多個數據包即可。 如果你使用緩沖區，堅持緩沖區，它應該沒問題。