我正在嘗試使用網(wǎng)絡(luò)連接進行讀寫。似乎正在發(fā)生的事情是，如果數(shù)據(jù)進入服務(wù)器的速度過快，一些數(shù)據(jù)將被丟棄或丟失?？蛻舳诉B接，協(xié)商連接，然后我讓它快速連續(xù)發(fā)送 3 個命令來更新狀態(tài)頁面。每個通信都是一個 JSON 字符串，它被轉(zhuǎn)換為一個結(jié)構(gòu)并使用存儲的密鑰進行解碼。如果我多次單擊客戶端上的請求（每次生成 3 個以 \n 結(jié)尾的 JSON 有效負(fù)載），服務(wù)器有時會拋出 ERROR: invalid character X after the top-level value。我轉(zhuǎn)儲了客戶端發(fā)送的信息，看起來客戶端上有 3 個格式正確的 JSON 條目；在服務(wù)器端，似乎其中一個 JSON 有效負(fù)載完全丟失，其中一個丟失了前 515 個字符。由于缺少前 515 個字符，因此 JSON 格式不正確，因此封送處理失敗。我的問題是，我能做些什么來防止從連接中讀取的數(shù)據(jù)丟失？我是否遇到某種競爭條件或錯誤處理如何在連接上讀取和發(fā)送？下面基本上是我用于客戶端連接處理程序的內(nèi)容?？蛻舳撕头?wù)器協(xié)商加密連接，因此有多個對模式和 RSA 狀態(tài)的引用，并且在正確設(shè)置密鑰時使用模式 4，以便服務(wù)器和客戶端可以交換命令和結(jié)果。在高層次上，處理程序衍生出一個從連接中讀取并將其發(fā)送到通道的 goroutine。該字符串被讀取并轉(zhuǎn)換為結(jié)構(gòu)。會話的第一部分專門用于“握手”以協(xié)商加密密鑰并保存會話信息；一旦到達第 4 階段，該結(jié)構(gòu)就會攜帶來自客戶端的加密命令并將結(jié)果發(fā)送回，直到連接出錯或關(guān)閉。
1 回答
白板的微信
TA貢獻1883條經(jīng)驗 獲得超3個贊
應(yīng)用程序?qū)?shù)據(jù)發(fā)送到緩沖的讀取器，然后丟棄讀取器和它可能緩沖超過第一行的任何數(shù)據(jù)。
在連接的生命周期內(nèi)保留緩沖的閱讀器：
rdr := bufio.NewReader(conClient)
for {
netData, err := rdr.ReadString('\n')
...
您可以通過消除 goroutine 來簡化代碼（并修復(fù)與緩沖區(qū)問題無關(guān)的其他問題）。使用讀取期限來處理無響應(yīng)的服務(wù)器。
func HandleClientConnection(conClient net.Conn) {
defer conClient.Close()
chnLogging <- "Connection from " + conClient.RemoteAddr().String()
conClient.SetReadDeadline(time.Minute * SERVER_INACTIVITY_TIMEOUT_MINUTES)
scanner := bufio.NewScanner(conClient)
for scanner.Scan() {
var strctNetEncrypted stctNetEncrypted
err := json.Unmarshal(scanner.Bytes(), &strctNetEncrypted)
CheckErr(err)
switch strctNetEncrypted.IntMode {
// Insert contents of switch statement from
// question here with references to
// chnCloseConn removed.
}
conClient.SetReadDeadline(time.Minute * SERVER_INACTIVITY_TIMEOUT_MINUTES)
}
if scanner.Err() != nil {
chnLogging <- "Error from client " + conClient.RemoteAddr().String() + ": " + err.Error()
} else {
chnLogging <- "Client " + conClient.RemoteAddr().String() + " disconnected"
}
}
- 1 回答
- 0 關(guān)注
- 121 瀏覽
添加回答
舉報
0/150
提交
取消