main: fix double brackets sent when socket rx ring buffer wraps around #55
@ -243,11 +243,8 @@ def main():
|
|||||||
lookback, noiseband, ch['interval'])
|
lookback, noiseband, ch['interval'])
|
||||||
|
|
||||||
for data in tec.report_mode():
|
for data in tec.report_mode():
|
||||||
try:
|
|
||||||
ch = data[channel]
|
ch = data[channel]
|
||||||
# Workaround for report_mode may yeild empty object
|
|
||||||
except KeyError:
|
|
||||||
continue
|
|
||||||
|
|
||||||
temperature = ch['temperature']
|
temperature = ch['temperature']
|
||||||
|
|
||||||
|
@ -213,9 +213,11 @@ fn main() -> ! {
|
|||||||
socket.close()
|
socket.close()
|
||||||
} else if socket.can_send() && socket.can_recv() {
|
} else if socket.can_send() && socket.can_recv() {
|
||||||
match socket.recv(|buf| session.feed(buf)) {
|
match socket.recv(|buf| session.feed(buf)) {
|
||||||
Ok(SessionInput::Nothing) => {
|
// SessionInput::Nothing happens when the line reader parses a string of characters that is not
|
||||||
|
|||||||
send_line(&mut socket, b"{}");
|
// followed by a newline character. Could be due to partial commands not terminated with newline,
|
||||||
}
|
// socket RX ring buffer wraps around, or when the command is sent as seperate TCP packets etc.
|
||||||
|
// Do nothing and feed more data to the line reader in the next loop cycle.
|
||||||
|
Ok(SessionInput::Nothing) => {}
|
||||||
Ok(SessionInput::Command(command)) => match command {
|
Ok(SessionInput::Command(command)) => match command {
|
||||||
Command::Quit =>
|
Command::Quit =>
|
||||||
socket.close(),
|
socket.close(),
|
||||||
|
Loading…
Reference in New Issue
Block a user
Your code seems correct but this comment sounds inaccurate: isn't
SessionInput::Nothing
also returned in other situations, e.g. if you send a partial command without the newline (irrespective of whether the ring buffer wrapped around or not)?Hm, I have only considered the use case of using Netcat or the pytec client library to interface the device, where every command will always be followed by a newline.
What you just said is certainly true if someone decides to roll their own application to interface with the thermostat. I'll update the comment.
No they won't. TCP doesn't guarantee that data will not be fragmented. For instance, if one side of the transmission sends "1234" then the other may receive "12" first and then "34" later. TCP data should be treated as a pure stream.
Right, I am surprised this bug didn't occur more often then, given all the things that could have gone wrong.