印IdUDPClient.sendbuffer - 在假數據接收使用Indy的IdUDPClient組分緩衝

林發送UDP數據包：印IdUDPClient.sendbuffer - 在假數據接收使用Indy的IdUDPClient組分緩衝

FIdUDPclient.sendbuffer(AIP, APort, FIdUDPBuffer); 
Frecl := FIdUDPclient.receivebuffer(FIdRecBuff, FreceiveTimeout);

權後，我得到了答案。

在調試代碼時使用wireshark顯示有時receivebuffer FIdRecBuff包含意外的數據。

例如，接收到的字節使用Wireshark讀：
45 02 57 00
但是在調試FIdRecBuff：
45 02 57 02

上面的代碼是在工作線程運行具有一個專用IdUDPClient實例。我只發送相同的3個字節，並獲得4個字節作爲來自三個IP設備的答案。

我認爲這個問題是，即時發送三個不同IP設備的UDP數據包沒有延遲，所以從IP回答不正確。 ~~但indy的sendbuffer（）方法阻塞直到收到，所以我不明白。~~

有人可以解釋什麼情況/條件會導致此行爲？

來源

2017-06-22 grinner

這也發生在indy tcp上，你需要知道事先要讀取多少字節。通常用indy修復的方法是事先發送字節數，然後讀取接收端的字節數。這個問題通常是爲什麼indy程序在閱讀時也會掛起。 –

還有發送/接收邏輯的問題。你做一個發送，然後2接收..首先獲得緩衝區長度，然後緩衝本身。這是一個尷尬的方法，需要習慣它。 –

@TuncayGöncüoğlu我不知道它是如何收到兩次。 Frecl只是一個返回receivebuffer方法的整數。 – grinner

當以串行方式使用TIdUDPClient將數據包發送到不同主機時 - 使用通信方法im使用時，來自不同主機的接收數據包可能會「相互干擾」。 UDP是無連接協議，因此沒有任何機制可以保證接收數據包（不同步於發送數據包）或接收遠程主機的正確順序。

爲了通過遠程主機分離所接收的分組，可能的解決方案是（感謝雷米勒博）：

檢查的遠程IP這就是對應於所述發送的數據包接收到的分組。
將IdUDPClient連接到遠程IP。（IdUDPClient.binding然後IdUDPClient.Connect）
使用IdUDPServer發送數據包，閱讀事件處理程序OnUDPRead中的答案。

（然而，從相同的遠程主機收到的數據包的正確順序不能保證，但現在這不是我的目標）。

來源

2017-06-30 10:39:02 grinner

這不保證收到的數據包的順序。在UDP中，根據每個數據包所採用的網絡路由，數據包可能無法按照它們發送的相同順序到達。本地局域網上的流量比互聯網上的流量更有可能保持順序。如果訂購很重要，發送方必須在分組數據中提供遞增的序列號，以便接收方根據需要重新排列接收的分組。這也有助於接收機檢測並忽略重複數據包。由於UDP沒有缺陷，因此接收方應確認收到的每個數據包，以便發送方可以重新發送缺少的數據包。 –

@RemyLebeau是的，我的回答是完全錯誤的。我的意思是不是同一個遠程主機的數據包順序，我很快就會編輯我的答案。感謝您的更正。 – grinner

印IdUDPClient.sendbuffer - 在假數據接收使用Indy的IdUDPClient組分緩衝

回答

相關問題