Re: [9front] Bounty: tmux-esque /dev/draw intermediary

[hiro <23hiro@gmail.com>]

On 7/8/22, Thaddeus Woskowiak <tswoskowiak@gmail.com> wrote:
> How would open fd's to files and binds to things in /mnt/term be
> handled on reconnect on a different machine with a different
> /mnt/term?

that's a great question.
i never noticed this problem.

the things that are always required from /mnt/term/dev (kbd, mouse,
draw) have to be handled specifically. i made a prototype for that
once. most of the work went to draw as the OP seems to also be aware
of :)

about the performance discussion: i agree that mothra sucks over
drawterm, that's because huge uncompressed images are being
transferred over 9p in relatively small chunks without any form of
streaming/pre-fetching, so it becomes latency-bottlenecked.

otoh: if you mostly have text rio/sam windows open and no modern
multimedia stuff (no pdf, no images/mothra), drawterm saves a lot of
*bandwidth*. i've been using it on 64kbit and 128kbit connections and
as long as your latency is alright (over LTE i had 30ms to my 9front
vps in france), it's super snappy.

if you do all the work required for the draw detach, then you can kick
out draw clients that cannot keep up with the draw updates,
effectively limiting their outstanding draw RPCs, and then batch
everything like in the reconnect-attach process, effectively removing
latency-bottlenecks, in other words, the clients become asynchronous
and thus the main draw can continue much faster (being local, network
delay wouldn't effect draw anymore).

you could also micro-manage this, compress all uncompressed Dimages
before syncing to the clients, and even more involved: only transmit
differences after re-attach.

also, i'd prefer if mothra and page didn't decode jpegs and instead
devdraw got support for that compression format.

i have a prototype that's super hacky, i didn't really want to go on
before we have a good generalized streaming solution e.g. for
something simple like distributed pipes.
and the compression part is too hard for me, too :D

also thought burnzez would report back his findings after he tested my
prototype. but i guess it was too hacky :D

now that there's clear interest expressed in true currency values i
might think about cleaning it up and finding other non-9p-layer
workarounds for speeding up streaming for my few specific cases. i'll
not do the compression or other crazy ideas i described above though.