Dear Kiran, others, The specific problem of tcpborphserver not working on the latest RPis is solved in the katcp_devel fork on HERA_Team (and the rpi-devel-casperfpga branch of katcp_devel on casper-astro), if you need it. It’s a matter of the GPIO address on the Pi having changed.
Aaron On Wed, Jul 20, 2022 at 3:37 AM Marc <[email protected]> wrote: > Hello > > On Tue, Jul 19, 2022 at 10:01 PM Kiran Shila <[email protected]> wrote: > > > but there are use cases where multiple GBytes of data are moved through > > > katcp > > This is a crazy to me as clearly the protocol is not meant for this > > purpose. > > So quite a number of people have worked on the katcp protocol > specification > over the last decade or so, and everybody has of course had a slightly > different > view on it, so what it "meant" to do is fuzzy. > > But I always intended it to be plain text where possible but able to handle > arbitrary data where necessary. > > > > Could the problem have been solved without breaking the ascii > > > requirement - sure. Why was it not? I don't know. > > > > Again - why even have a formal specification if official implementations > > break it? > > The BNF defines an argument as one or more characters, of which 7 have to > be > escaped. It does not define what a character is, and now looking back > that is a deficiency, but to my mind a "control character" or "non > printable character" > are a subset of "character". Maybe "octet" would have been better... > > Then there is also "Where message parameters are described > as `human-readable' the content of the parameters should be restricted to > plain ASCII text" (pg11) but that is for parameters which are documented > to be human readable - and I'd be surprised if all the parameters > "?write" and "!read" are described as such. > > regards > > marc > > > > > > > > > > > Changing the tcpborphserver behaviour of read/write in a way that is > not > > > backwards compatible with casperfpga (and every other preexisting > casper > > > katcp client) seems unlikely to me to be a goer. Obviously you could do > > > it to meet your needs/desires, but this code isn't going to ever get > > > merged into the main repos/branches (you might reasonable ask whether > > > this matters, given how many distinct, incompatible code branches are > > > already lying around). In any case, making new bulk transfer commands > > > which are compliant, and work with the client you're building seems > like > > > a path which should keep everyone happy(?) > > > > For sure. I wasn't expecting anyone to actually update read and write, I > > was just providing an alternative should anyone want. Having a third > > option, (maybe `bulkread` and `bulkwrite`) that follows the spec sounds > > like it may be worth it. > > > > If we're actually worried about throughput, there are a number of > > solutions that pack binary data into plaintext relatively efficiently. > > Base64 is common in the web space, as well as compressing and then > > packing. Again, it seems like it would be better just to open another > > socket and not deal with the hassle. > > > > -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/af99003f-574f-4593-3a08-995a3dbdbff0%40kiranshila.com > . > > > > -- > https://katfs.kat.ac.za/~marc/ > > -- > 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/CAGrhWaS9Si3LESq76eoEezmrU6geXYjkHV3CdzPeMr5j_Xzd4w%40mail.gmail.com > . > -- Aaron Parsons 510-406-4322 (cell) Campbell Hall 425, UCB -- 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/CACu45XDcispeurNC2VgXsXLa9vJcO_RgfXcUF6m7zzr3RpSXvw%40mail.gmail.com.
