[casper] Re: tcpborphserver violates katcp specification

[Kiran Shila]

On 7/1/22 12:13, Kiran Shila wrote:

Hey everyone,

I've been recently working on getting a SNAP up and running and have been digging into the guts into how all these parts fit together. As I try to avoid python like the plague, I thought it would useful to start to write some of the functionality in Rust. I followed the official SARAO spec and have published a pure-rust implementation here: https://github.com/kiranshila/katcp

Regards,
Kiran

This library could be used in clients and servers, even microcontrollers (which I believe currently isn't possible). This also leaves any runtime decisions (like which async engine to use) up to eventual implementers. Now, I'm trying to design a client to configure my SNAP - but am discovering that tcpborphserver doesn't actually match the prescribed behavior. Specifically, the fact that `read` and `write` work with raw bytes violates the condition that "the contents of the parameter should be restricted to plain ASCII text". This means that *any* strict implementation of the katcp spec (including my own) are unable to use those commands. Updating these commands to send escaped bytes doesn't seem too tricky, but would be a breaking change. In fact, these commands could match the behavior of `wordread/wordwrite` and send the bytes as hex literals (although those technically violate the spec as well as hex literals aren't one of the valid types). This change would enable spec-compliant implementers to utilize the commands without building in technically invalid behavior, which in turn would lead to more robust implementations.

-Kiran

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/3cad4c49-f85d-f07d-0a44-b54a2731bf1b%40kiranshila.com.

Actually, the more I think about this - I'm really unsure how this even works. What happens if the binary payload contains 0x20 or 0x10 (space or newline)? Wouldn't that just break the parser? Is there something somewhere that guarantees these bytes don't exist in the payload?

OpenPGP_signature
Description: OpenPGP digital signature