From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Sun May 17 20:23:58 EDT 2020
Received: from abbatoir.fios-router.home (pool-162-83-132-245.nycmny.fios.verizon.net [162.83.132.245])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id b53549e0 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO);
	Sun, 17 May 2020 17:23:43 -0700 (PDT)
Message-ID: <A797820D911FCFC5EF38156F3CD8E7AC@eigenstate.org>
To: unobe@cpan.org, 9front@9front.org
Subject: Re: 9P2000.s vs 9P2020 vs. ? (Was Re: [9front] Slow cp, support for 9P2000.s)
Date: Sun, 17 May 2020 17:23:41 -0700
From: ori@eigenstate.org
In-Reply-To: <133678F3-1EA1-446D-9313-F10F23C84936@cpan.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: stateless stateless rich-client WEB2.0 API reduce/map singleton 

> Since there's no existing discussion I can see, and IRC isn't meant for
> searching for answers to questions, is there anyone willing to summarize
> the state of solving problems like streaming for 9P?

Nothing that we're satisfied with at the moment, though there's
thoughts on providing early acks on writes, and io agents to do
bring at least some of the io logic closer to the data, instead
of shouting across the internet for every transaction.

> If Aiju remembers correctly, there were two things where 9P2000.s was found wanting:
> 1) it breaks the syscall interface; and
> 2) it forces 9P to run over TCP.
>
> FWIW, I finally finished reading through all of John's thesis,
> rather than just skimming, and I think John did a nice review of
> the previous work done in this area and presenting why he chose
> the solution he did.  His solution used TCP, but from his
> write-up, I don't see a technical reason why another transport
> protocol[1] could not be used.  That would leave only breaking
> the syscall interface.
> 
> Does breaking the syscall interface mean that it's merely adding a
> syscall? Or does it mean something else?

Yes -- any program that would want to take advantage of it needs
to be touched.  And would need heuristics: a 9p roundtrip is
still fewer roundtrips than a TCP handshake, so using it blindly
would slow things down when handling small files.  We also, by
design, make no distinction between remote and local files, so
there would need to be more guesswork here.

It also doesn't help with, for example, walking a directory
heirarchy, so things like browsing a mail archive over 9p will
remain painfully slow.

Finally, if we want an ad-hoc solution like this, we can do it
entirely in userspace, with a TCP server sitting on a remote
server, and a local 9p server that opens a TCP connection to
that server and streams the whole file, providing it locally.
I don't think this would be very hard to write, and would
probably give the benefits of streams, without needing any
changes to the existing code. (Thinking about this, it may
actually be worth writing.)

So. in short: This is a big hole in the abstractions provided
by 9p, and it doesn't solve the problem completely.

> Right now hget(1) is an rc script that uses webfs(4).  So if
> I'm at a terminal far away and am using webfs provided by the
> server I'm connected to, hget would be slow for a large file
> because the file would be transferred over 9P. It's no better
> than Plan 9's implementation, but no worse either.
> 
> [1] https://en.wikipedia.org/wiki/Category:Transport_layer_protocols