Hello Maybe it is helpful to give the reason for having two different read/write mechanisms in tcpborphserver:
?wordread/?wordwrite was written with maximal human readability in mind. Somebody who has a misbehaving roach deployed somewhere can just telnet/netcat/socat/etc to port 7147 and issue a wordread to see if enough bits are toggling, or if some counter is ticking over, set a debug flag, etc. ?read/?write are intended to retrieve larger chunks of data, and use a represenation which is reasonably efficient. The link to the powerpc isn't particularly fast, and while there are things that could be optimised further, the current backslash encoding isn't computationally expensive and adds a bit over 3% overhead, which I think is reasonably good. When I was referring to escape (and cornered programmers) in the previous mail I didn't only mean literal escape characters, but also a means to escape some of the constaints or access extended functionality. In the above case, binary(ish) data to do more efficient bulk transfers. Of course, there is also nothing stopping you from only using ?wordread and ?wordwrite in your rust library if the ?read and ?write requests strike you as suffiently awkward. regards marc On Tue, Jul 19, 2022 at 1:52 PM Kiran Shila <m...@kiranshila.com> wrote: > > 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 > "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/ff0136a6-c45b-23ae-ce11-1cc87af72f82%40kiranshila.com. -- https://katfs.kat.ac.za/~marc/ -- 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/CAGrhWaTbk1RSQxhNAzUQ0%3D%2BunB3S%2BZExBtvB4MVJZgtcK3g4hQ%40mail.gmail.com.
