2 回答

TA貢獻1877條經驗 獲得超1個贊
看起來您正在重復使用相同的連接,而發生的情況是您的file_socket
緩沖意味著...您實際上已經recv
從套接字中讀取了更多內容,然后您會通過讀取循環來思考。
即接收器從您的套接字消耗更多數據,并且下次您嘗試readline()
最終讀取前一個文件的其余部分,直到其中包含的新行或下一個長度信息。
這也意味著您最初的問題實際上是您跳過了一段時間。下一個讀取行的效果不是int
您預期的,因此觀察到了失敗。
你可以說:
with sock.makefile('rb', buffering=0) as file_socket:
相反,強制文件訪問不被緩沖?;蛘邔嶋H自行處理傳入字節的接收、緩沖和解析(了解一個文件的結束位置和下一個文件的開始位置)(而不是像包裝器和 那樣的文件)readline
。

TA貢獻2041條經驗 獲得超4個贊
您必須了解套接字通信是基于 TCP/IP 的,無論是同一臺機器(在這種情況下使用環回)還是不同的機器都無關緊要。因此,您已經獲得了一些在其之間建立連接的 IP 地址。更進一步,它涉及訪問您的網絡適配器,即與訪問例如網絡適配器相比需要相對較長的時間。內存。此外,適配器本身管理何時發送特定數據幀(較低的 ISO/OSI 層)。基本上,對于 TCP,需要 ACK,但在標準 PC 上,這通常不是某些工業實時以太網。
因此,在您的代碼中,您有一個while True
沒有任何睡眠的循環,并且您不檢查sock.send
返回的內容。即使特定數據幀出現問題,您也會忽略它并嘗試發送下一個。乍一看,似乎有些內容已被緩存,并且接收者收到了重新建立連接后刷新的內容。
因此,您應該做的第一件事是檢查是否sock.send
確實返回了發送的字節數。如果沒有,我相信應該重新發送該幀。在這種情況下,我強烈建議的另一件事是考慮一些自定義協議(這通常在 OSI/ISO 堆棧的上下文中稱為應用程序層)。例如,您可能有 4 種類型的幀:START、FILESIZE、DATA、END,分配唯一 ID 并以標識符開始每個幀。然后,START 將是空的,FILESIZE 將包含單個 uint16,DATA 將包含 {FILE NUMBER, LINE NUMBER, LINE_LENGTH, LINE},END 將是空的。然后,一旦您在客戶端上獲得了整個框架,您就可以安全地組合收到的信息。
添加回答
舉報