2016-10-28 73 views
0

我在localhost上測試我的程序,當我想從客戶端發送到服務器文件時,例如jpg,我想用我的頭將數據拆分爲100byte片段在我的548片段之後出現這樣的錯誤。服務器打印接收的內容。Java UDP服務器 - 客戶端通信 - 發送片段(片段發送失敗)

RECEIVED: 43749 | 1 | 546 | 1176 | jpg 
RECEIVED: 60251 | 1 | 547 | 1176 | jpg 
RECEIVED: 53346 | 1 | 548 | 1176 | jpg 
RECEIVED: 55018 | 1 | 737 | 1176 | jpg 

第一個是校驗和第二個消息第三個分片第四個分片的最大個數和最後一個文件類型。到這一點,一切都正確sening正在較小的文件。什麼可能是錯誤的任何想法嗎?

回答

1

我假設你指的是消息的「無效」順序(737在548之後)?

這實際上是完全正常的,因爲UDP不保證該信息(數據報)順序:

沒有下令 - 如果兩個消息被髮送到同一收件人,在他們到達的 順序不能預料到的。

只需使用TCP代替,或者實現一個應用程序級別的算法來緩衝和重新組合您的數據。

另外,還要注意什麼UDP RFC(https://tools.ietf.org/html/rfc768)說:

協議是面向事務,並交付和重複 保護不能保證。 應用程序需要有序可靠 交付數據應該使用

例如,你可能也將面臨丟失傳輸控制協議(TCP)或重複的數據(雖然這是比較罕見的,除非你有一些網絡問題)的流

+0

是的,但它不能發生在本地主機上 – user3396072

+1

實際上,它可以,規範沒有說任何關於「本地主機」的額外保證,所以根據你的OS網絡堆棧的實現以及你所使用的機器類型運行(例如多核或多CPU),你仍然可能不按順序獲取數據報。 請參閱http://stackoverflow.com/questions/2533873/why-do-i-get-udp-datagrams-out-of-order-even-with-processes-runnning-locally 甚至可以放鬆其中的一些 http://stackoverflow.com/questions/3034680/reliability-of-udp-on-localhost – zeppelin

+1

注意這並不意味着你的問題是在網絡堆棧,它可能是一個應用程序級別的編程錯誤,沒有提供足夠的細節來說明這一點。 但問題是,你不能依賴UDP數據報以特定的順序傳送,或者根本無法傳送。 – zeppelin

相關問題