2013-07-29 41 views
1

我正在研究可靠的UDP網絡,我必須知道一些事情。我認爲UDP可靠算法就是這樣工作的(IDK,我想);可靠的UDP算法?

  • 服務器發送:(標題:6)ABCDEF
  • 客戶端接收:(標題:6)ABDF,發送回 「我有4個數據,它們是ABDF」
  • 服務器發送:(標題:2 )ce
  • 客戶端收到:(header:2)ce,好的,我將把它們結合起來!

現在是可靠的UDP這是真的呢?

編輯(回答後,也許這可以爲別人有用)我goint使用TCP可靠,因爲UDP是不處理我操作的好方法。我會發送像不重要的時間變量的位置。也許如果我爲可靠的UDP創建一個算法,這個可靠的過程將花費3-4個UDP send-recv,這意味着我可以在這個時候發送3-4個其他不可靠的位置數據,並且我發送的數據量可以更高比可靠的UDP。

+0

作爲一個說明,在大多數操作系統實現UDP不會給你一個部分數據包。你要麼收到它的所有部分,要麼沒有。請注意,單個數據包的順序不能保證,甚至根本不會收到數據包。 –

+0

@DaveS數據可能完全丟失!謝謝。 – MonoLightGS

+2

如果你想要的是一個可靠的面向數據報的協議,請考慮[SCTP](http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)。 –

回答

2

的「正確的方法」獲得可靠的UDP是使用TCP。

如果您仍希望通過UDP來完成此操作,您可以通過發送帶校驗和的消息來驗證消息的完整性,然後重新計算另一端的校驗和以查看它是否與您發送的校驗和相匹配。

如果不匹配,請再次請求數據包。請注意,這基本上是重新創建TCP。

+0

您還需要一種機制來處理丟失,而不僅僅是損壞的數據包。 –

+0

頭+校驗和(如crc)可以是有用的,我認爲。我現在嗎? – MonoLightGS

+3

UDP帶有一個校驗和,添加一個不會使其可靠性下降(這種情況自然會伴隨着網絡擁塞)。 –

0

你的問題聽起來就像是量身訂做的Data Distribution Service

我會送樣未重要,時間變量

事實上,位置座標是許多廠商的最典型的例子位置。 RTI has a demonstration which goes well with your use case

呀,當他們聽到「IDL」很多人的呻吟,但我建議你給它一個公平待遇。 DDS不像很多流行的pub-sub/distribution/etc協議,因爲它不是一個簡單的封裝/管道。

我覺得很酷的事情是,經常有很多邏輯和設計元素的進入的問題,「我怎麼反應的底層網絡或我同行(S)胡作非爲(S)?」 DDS提供服務質量協商,並在您的代碼不符合QoS條款時響應您的代碼。

我建議不要輕易做出這個決定,它比TCP,UDP,AMQP等複雜得多。但是如果你能承受複雜性並且可以在足夠大的系統上分攤它 - 它可以支付真實分紅。

最後,DDS確實提供了UDP「可靠」的消息。它旨在支持許多不同的傳輸和QoS的許多不同維度。當您看到此服務考慮的QoS的所有不同維度時,確實令人目不暇接。

+0

感謝您的支持!我會看看是否需要這樣的實現。 – MonoLightGS

1

好,即使有:

- Client receive: (header:6)abdf, sends back "I got 4 data, they are abdf" 
- Server send: (header:2)ce 

什麼,如果服務器將不會收到您的回覆(可能在UDP發生)?因此,如果您不關心連接速度,切換到TCP是更好的選擇。