對於UDP async_receive的boost :: asio錯誤

我遇到了來自boost :: asio的奇怪錯誤的問題。我正在實現一半的TFTP服務器（僅限服務器 - >客戶端）。我在第一個套接字上的端口69上獲得第一個RRQ數據包，然後創建另一個套接字來執行DATA，ACK交換。我在該套接字上啓動一個async_receive（），然後執行第一個數據包的send（）。然後我得到接收器的處理函數回調函數（我假設ACK進來了），它給出錯誤「沒有連接，因爲目標機器主動拒絕它」，我從這裏的另一個線程理解意味着ERROR_PORT_UNREACHABLE。對於UDP async_receive的boost :: asio錯誤

我真的不明白接收電話會如何導致UNREACHABLE錯誤，因爲我沒有接觸到任何東西，我正在接收。我檢查了send（）的結果，那裏沒有錯誤。

我檢查了套接字中的本地和遠程端點（錯誤之前和之後），並且它們都具有正確的IP地址和端口。

任何想法？我一直在搜索，並找不到其他人有這個問題。大多數結果讓我轉向了stackoverflow，所以我在這裏問。

編輯 - 我的問題是，我正在使用調試器。在我發送第一個數據包時，當客戶端在大約一秒鐘內發送了十幾個請求後，客戶端超時並放棄，我的數據太晚了。當我運行沒有斷點時，它工作正常。感謝大家的建議。它正在觀察Wireshark中的數據包給我提供了線索。

來源

2012-10-12 user1739763

請不要在解決問題時編輯您的問題。添加的材料更適合作爲您接受的答案的評論。 –

發送成功的原因是因爲發送只是表明數據包已被提供給操作系統。具體來說，操作系統然後將該數據包發送到目的地，並用IP數據包作出響應，指示該主機未在監聽。您的操作系統接收到它，並在您的套接字上設置一個標誌，導致下一次讀取失敗。由於您已經在執行異步接收，因此會導致接收返回錯誤。

如果可能，我強烈建議使用wireshark或類似的東西來觀察UDP交換，並查看是否可以識別任何其他問題。我不熟悉TFTP協議，並且不能在那裏提供很多輸入。

來源

2012-10-12 01:42:29

感謝您的回覆。當你說「它迴應一個IP數據包，表明主機沒有在監聽」這聽起來很像你描述的是TCP而不是UDP。我不認爲將UDP數據包發送到另一個地址會導致該機器的任何響應。我認爲，如果這個數據包沒有被這樣的事情攝入，那麼它就會落在地板上。但是，謝謝關於wireshark的提示。我會嘗試的。 – user1739763

@ user1739763指示「主機未在監聽」的協議是ICMP。你可以得到TCP或UDP無法訪問的ICMP端口，我期望它能夠響應你發送的數據包，期待沒有任何事情發生。 – janm

@ user1739763：更具體地說，TCP和UDP都會發送ICMP端口不可達數據包。對於未連接的UDP套接字（通過'connect'調用），您的操作系統不會通知您。但是，如果您發出了「連接」呼叫，則會按照我所述將失敗傳遞給您。 –

對於UDP async_receive的boost :: asio錯誤

回答

相關問題