M-Labs
/
thermostat
9
0
Fork 5
Code Issues 7 Pull Requests 6 Releases Wiki Activity

main: fix double brackets sent when socket rx ring buffer wraps around #55

Merged
sb10q merged 2 commits from fix_double_brac into master 2021-01-29 16:18:07 +08:00
Conversation 0 Commits 2 Files Changed 2
2 changed files with 7 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
pytec/autotune.py
View File

@ -243,11 +243,8 @@ def main():
lookback, noiseband, ch['interval'])
for data in tec.report_mode():
try:
ch = data[channel]
# Workaround for report_mode may yeild empty object
except KeyError:
continue
ch = data[channel]
temperature = ch['temperature']

8
src/main.rs
View File

@ -213,9 +213,11 @@ fn main() -> ! {
socket.close()
} else if socket.can_send() && socket.can_recv() {
match socket.recv(|buf| session.feed(buf)) {
Ok(SessionInput::Nothing) => {
send_line(&mut socket, b"{}");
}
// SessionInput::Nothing happens when the line reader parses a string of characters that is not
sb10q commented 2021-01-29 15:45:01 +08:00
Outdated
Review

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)?

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)?
topquark12 commented 2021-01-29 15:56:22 +08:00
Outdated
Review

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.

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.
sb10q commented 2021-01-29 15:58:39 +08:00
Outdated
Review

where every command will always be followed by a newline.

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.

> where every command will always be followed by a newline. 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.
topquark12 commented 2021-01-29 16:06:08 +08:00
Outdated
Review

Right, I am surprised this bug didn't occur more often then, given all the things that could have gone wrong.

Right, I am surprised this bug didn't occur more often then, given all the things that could have gone wrong.
// 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 {
Command::Quit =>
socket.close(),