On 7/15/22 08:16, Marc wrote:
So re-reading my first reply it becomes clear that this was much too terse - sorry.Here then the longer explanation: At the lowest level katcp is a line-based protocol consisting out of lines starting with either '#', '?', '!', followed by one or more words, each word separated from the subsequent one by one or more spaces or tabs. Generally katcp is intended to be human readable, so where possible the words should be plain (ascii) text, but where not[1] katcp offers the following backslash escapes '\\' '\n', '\r', '\t', '\0', '\e', '\@' and '\_'. The first five of these escapes are the same as C. The other three require some explanation: '\_' is interesting as it decodes to a *space*, so ' ', not an underscore. The reason for that is that it means a naive parser unaware of escapes at least still manages to extract the correct word. ?hello paramter1 parameter\_two parameter3 will yield 'parameter3' to the quick and dirty parser (say "cut -f4 -d ' ') which simply splits on space, rather than 'two' if this were not the case. '\e' escapes the 27 (0x1b) as a curtesy, so that binary data displayed to the terminal doesn't generate too many escape sequences. '\@' is the null parameter - so represents a word of zero length or nothing. This means it is possible to have optional parameters not just at the end of list, so making it easier to refer to parameterN, even if nothing is given for parameterN-1. It is possible to think about each word/parameter has having a type, and while that might be useful in a number of cases, say when binding it to a strongly typed language, at this level they are all just a sequence of octets... regards marc [1] - It is always good to offer an escape - not only to cornered wild animals, but to other programmers too :) There is an ancient famous critique of Pascal which takes it to task for not providing this.
Thanks Marc for your response,Yes - the escaping component of the plain text part of the protocol makes perfect sense and is currently handled by my parser (https://github.com/kiranshila/katcp/blob/2201557ea81d8c00dda3e72a02de0d81cdf6b3fb/src/protocol.rs#L213-L216)
I'm mostly concerned with tcpborphserver's `read` and `write` messages as they send raw (non-ascii) bytes.
For example, if I run:
client.blindwrite("sys_scratchpad", b'\xde\xad\xbe\xef')
The katcp payload sent over TCP is:
0x3F7772697465207379735F73637261746368706164203020DEADBEEF0A
Or
?write sys_scratchpad 0 <4 bytes not representable in ASCII>
,clearly violating this plaintext contract. The fact that parser
constants gets escaped in the middle of this payload honestly add to the
confusion because then there is random plaintext in a binary payload.
This is why I'm suggesting a revision of TCPBorphserver and casperfpga to use something plaintext to represent these payloads. Base64 wouldn't be a bad option.
I've implemented TCP middleware (https://github.com/GReX-Telescope/katcp_canonicalizer) to transform the binary payloads in place to base64, as an example.
-Kiran -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/ff0136a6-c45b-23ae-ce11-1cc87af72f82%40kiranshila.com.
OpenPGP_signature
Description: OpenPGP digital signature
