9front - general discussion about 9front
 help / color / mirror / Atom feed
From: hiro <23hiro@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] Bounty: tmux-esque /dev/draw intermediary
Date: Fri, 8 Jul 2022 22:51:46 +0200	[thread overview]
Message-ID: <CAFSF3XM-DF-XJVLC9-ODgqqzTgRpNiZ86HqpyM05ap05Ri6zNw@mail.gmail.com> (raw)
In-Reply-To: <CAG3JMtYpy+-Wdk1BLj0MZLpTXbis8-W0RNVLTrb8KExGx5Eskw@mail.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.

  reply	other threads:[~2022-07-08 20:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 17:49 Larkin Nickle
2022-07-08 19:24 ` michael.grunditz
2022-07-08 19:33   ` Larkin Nickle
2022-07-08 19:40     ` Stanley Lieber
2022-07-08 19:46       ` Kurt H Maier
2022-07-08 19:51       ` mkf9
2022-07-08 20:05         ` Larkin Nickle
2022-07-08 20:11         ` Stanley Lieber
2022-07-08 20:15           ` mkf9
2022-07-08 20:24           ` Larkin Nickle
2022-07-08 20:28 ` Thaddeus Woskowiak
2022-07-08 20:51   ` hiro [this message]
2022-07-10 10:46     ` Philip Silva
2022-07-08 21:04   ` Larkin Nickle
2022-07-08 21:11   ` mkf9

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFSF3XM-DF-XJVLC9-ODgqqzTgRpNiZ86HqpyM05ap05Ri6zNw@mail.gmail.com \
    --to=23hiro@gmail.com \
    --cc=9front@9front.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).