Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[Ole-Hjalmar Kristensen]

I agree with you that using the existing tag mechanism to keep multiple
requests in flight should be sufficient. I get the impression that this is
not readily supported by the higher level libraries, though.

As an aside, I seem to remember that John Floren sugegsed (and implemented)
changes to the 9P protocol making it more suitable for streaming media by
creating another TCP connection on the side.

On Mon, Jan 4, 2021 at 12:52 AM Ethan Gardener  wrote:

> > The idea, basically, is to use an open flag (OJUMBO) to signal that two
> > connections to the same server should be attempted.
>
> What's the advantage over fcp(1)? 9p can have numerous requests "in
> flight" at once to work around latency issues, but of all the user
> programs, fcp is probably the only one which takes advantage of this.
>
> > If a second
> > connection can be established, it is used for normal 9P transactions,
> > while the first connection is used for large ("jumbo") writes.
> 
> How large is "jumbo"? I believe all the user programs have 8KB buffers at
> present; are you going to change them all?
> 
> I'm not negative about this; just raising the points.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M32ea06de21be8e55f94d0b3b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port: acme remoting

[Ole-Hjalmar Kristensen]

Very interesting. In the past, I have resorted to using a combination of
Sam/9term/plumber in similar scenarios, but I really prefer Acme. At the
moment I'm running Acme over X11, since I'm constrained to using Windows on
the desktop, and I've got a working X server, but no Acme on Windows.
Anyone got plan9port to work under Cygwin?

On Mon, Jan 4, 2021 at 5:41 AM marius a. eriksen  wrote:

> Lately, I have needed to do a great deal of my work on remote servers.
> It's been difficult to do this with acme. Previously, I have attempted to
> run acme entirely remotely, and then attach to a local devdraw instance
> . This works okay, but also
> has many drawbacks, among which: (1) it's not economical with networking,
> and so not great for high latency or otherwise poor connections; (2) it's
> not resilient to connection disconnects; (3) often I want access to local
> resources too.
>
> I built an experimental remoting layer in acme to see how far I could get
> in recreating a modern "remoting" experience with acme. Since acme itself,
> of course, is designed around a bunch of 9p servers, this turned out to be
> fairly easy to do, and the resulting experience is nearly transparent.
>
> A remote may be attached to one or more path prefixes. These are similar
> to mount points in a file system. Thus, if the prefix /home/meriksen is
> attached to the remote "dev", then any file with this prefix is transparely
> fetched from the dev. Similarly, when commands are run from any directory
> with this prefix, the command is transparently run on the remote. The
> command is run in an environment that includes the acme and plumber 9p
> servers (forwarded from the local host), and so even acme programs just
> work. For example, if you run 'win' from a directory that is attached to a
> remote, 'win' is run on the remote host, but it accesses the acme 9p file
> tree (which is forwarded from the local acme) and creates its window and
> interacts with acme. It "just works". (I regularly run other programs like
> this too, e.g., acme-lsp, which uses the plumber to coordinate interaction).
>
> The design of the feature is quite simple: a new program, acmesrv
>  is
> run by acme (through ssh) on the remote host. Acme becomes a client of
> acmesrv, through which all further interaction is facilitated. Acmesrv
> itself is really just a 9p multiplexer: the local acme program exports the
> acme and plumber 9p servers; acmesrv provides two new 9p servers (exportfs
> and cmdfs) that gives the local acme access to the remote's file system
> (exportfs) and to run commands (cmdfs).
>
> The local acme manages a session for each remote, and properly deals with
> session disconnect/reconnect, etc. Thus, poor network conditions and
> disconnects are easily supported. Since acme's file handling is anyway
> stateless (the file is not kept open during editing), file state is easily
> maintained through disconnect-reconnect cycles.
>
> There are some synchronous code paths in acme, and these may cause
> temporary freezes when using remoting. For example, when acme queries for
> the existence of a file (stat), this blocks UI updates in acme. On session
> establishment (e.g., the first time a file is accessed on a remote), this
> can cause additional delays, since the file cannot be queried before first
> establishing a new session. I've not found this to be a big deal.
>
> This has been my "daily driver" for about a month at this point, and
> overall I'm very happy with the experience. It creates a nearly transparent
> experience editing remote files, and retains most of acme's functionality
> in remote settings as well. I never hesitate to shut my laptop lid while in
> the middle of a project. Most things just work. There are wrinkles, of
> course, and there are some sharp edges in this (experimental)
> implementation, but, to me, this provides really very useful functionality
> that lets me use acme in more challenging environments. (Not to mention
> that this means I can use a beefy remote host for heavy lifting.)
>
> In case this would be useful to anyone else, this version of acme resides
> in my plan9port tree on github
> .
> (Currently, these diffs: 1
> ,
> 2
> ,
> 3
> ,
> 4
> 

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[hiro]

reliability can be provided by AAN, already.

You can try out the Op protocol for inferno though, if you want to see
a working implementation of streaming 9p.
I've been running it for a long time and it worked perfectly for my use case.

On 1/4/21, Ole-Hjalmar Kristensen  wrote:
> I agree with you that using the existing tag mechanism to keep multiple
> requests in flight should be sufficient. I get the impression that this is
> not readily supported by the higher level libraries, though.
>
> As an aside, I seem to remember that John Floren sugegsed (and implemented)
> changes to the 9P protocol making it more suitable for streaming media by
> creating another TCP connection on the side.
>
> On Mon, Jan 4, 2021 at 12:52 AM Ethan Gardener  wrote:
>
>> > The idea, basically, is to use an open flag (OJUMBO) to signal that two
>> > connections to the same server should be attempted.
>>
>> What's the advantage over fcp(1)? 9p can have numerous requests "in
>> flight" at once to work around latency issues, but of all the user
>> programs, fcp is probably the only one which takes advantage of this.
>>
>> > If a second
>> > connection can be established, it is used for normal 9P transactions,
>> > while the first connection is used for large ("jumbo") writes.
>>
>> How large is "jumbo"? I believe all the user programs have 8KB buffers at
>> present; are you going to change them all?
>>
>> I'm not negative about this; just raising the points.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M6f610222b3d7fc1800e82174
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port: acme remoting

[Pouya Tafti]

On Mon, 4 Jan 2021, at 12:00, Ole-Hjalmar Kristensen wrote:
> Anyone got plan9port to work under Cygwin?

Never tried it on Cygwin, but I once had the misfortune of having to use 
Windows for work and got p9p to work on WSL w/o much trouble afaicr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcac494e4a963278fdb5b31b1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port: acme remoting

[Semyon Novikov]

Same here, works flawlessly with WSL2 and VcXsrv.
Also there is an option of Edwood, but it's not quite worked well for me in the 
past.

On Mon, 4 Jan 2021, at 14:43, Pouya Tafti wrote:
> On Mon, 4 Jan 2021, at 12:00, Ole-Hjalmar Kristensen wrote:
> > Anyone got plan9port to work under Cygwin?
> 
> Never tried it on Cygwin, but I once had the misfortune of having to
> use Windows for work and got p9p to work on WSL w/o much trouble afaicr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-M29e6fd3ba30aefcd492daeb0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[joe]

Might be more than it is worth but what if you made a small program/file server 
that addressed portions of the "larger" file as their own file in a temporary 
directory. On write you would have to preallocate the file on the disk and 
write eatch section to it's respective range. "Chunks" would be simplified by 
having a pre-copy size and a "Chunk number" appended on the end of each chunk. 
Used to write to the correct location in the destination. Everything in else 
could remain the same. You would just use the "Split/Bulk Copy" program to copy 
from source to destination. Getting better with plan9 but not enough so to 
implement something like this or know if it would work. Just a thought.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-Mb8a0447d7180b423909022ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Rudimentary web browser in Go

[philip.silva via 9fans]

Hi!

I've been working on a rudimentary web browser in Go which runs on Plan9(port) 
thanks to the duit UI framework. I've developed most of it of 9front/amd64 
although the initial setup and some debugging were done on macOS. The code 
itself without tests is at the moment less than 4 kloc - although it has a 
number of dependencies. It's still very experimental but it gives surprisingly 
usable results with many static web pages (Screenshot 
http://psilva.sdf.org/scr.png). Parts of the code are still a bit wild because 
they are more or less proof-of-concept. Also there is a very experimental JS 
support, at least in very isolated cases it can handle jQuery code. :-D It's 
hosted on shithub: http://shithub.us/git/ph/opossum/HEAD/info.html (I've also 
created a mirror on Github: https://github.com/psilva261/opossum) Would be 
great if someone is interested in contributing!

Greetings, Philip
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T08e3f4043301fdb1-M99102de53868f6a39fe2e10f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[hiro]

that doesn't make any sense.
9p already allows you to access many parts of the file at the same time...

On 1/4/21, j...@lifesoftserv.com  wrote:
> Might be more than it is worth but what if you made a small program/file
> server that addressed portions of the "larger" file as their own file in a
> temporary directory. On write you would have to preallocate the file on the
> disk and write eatch section to it's respective range. "Chunks" would be
> simplified by having a pre-copy size and a "Chunk number" appended on the
> end of each chunk. Used to write to the correct location in the destination.
> Everything in else could remain the same. You would just use the "Split/Bulk
> Copy" program to copy from source to destination. Getting better with plan9
> but not enough so to implement something like this or know if it would work.
> Just a thought.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M0af38d162f862329a4edc3c3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[ori]

Quoth j...@lifesoftserv.com:
> Might be more than it is worth but what if you made a small
> program/file server that addressed portions of the "larger" file as
> their own file in a temporary directory.  On write you would have to
> preallocate the file on the disk and write eatch section to it's
> respective range.  "Chunks" would be simplified by having a pre-copy
> size and a "Chunk number" appended on the end of each chunk.  Used to
> write to the correct location in the destination.  Everything in else
> could remain the same.  You would just use the "Split/Bulk Copy"
> program to copy from source to destination.  Getting better with plan9
> but not enough so to implement something like this or know if it would
> work.  Just a thought.

http://man.9front.org/4/cfs

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-Mf9a01546241ea2a688c1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Rudimentary web browser in Go

[Federico Benavento]

Nice.

> On 4 Jan 2021, at 16:13, philip.silva via 9fans <9fans@9fans.net> wrote:
> 
> Hi!
> 
> I've been working on a rudimentary web browser in Go which runs on 
> Plan9(port) thanks to the duit UI framework. I've developed most of it of 
> 9front/amd64 although the initial setup and some debugging were done on 
> macOS. The code itself without tests is at the moment less than 4 kloc - 
> although it has a number of dependencies. It's still very experimental but it 
> gives surprisingly usable results with many static web pages (Screenshot 
> http://psilva.sdf.org/scr.png ). Parts of the 
> code are still a bit wild because they are more or less proof-of-concept. 
> Also there is a very experimental JS support, at least in very isolated cases 
> it can handle jQuery code. :-D It's hosted on shithub: 
> http://shithub.us/git/ph/opossum/HEAD/info.html 
>  (I've also created a mirror 
> on Github: https://github.com/psilva261/opossum 
> ) Would be great if someone is 
> interested in contributing!
> 
> Greetings, Philip
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T08e3f4043301fdb1-M7a0637da7f7fcaf5abdbbedc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port: acme remoting

[Lyndon Nerenberg]

I've always just used aan(8) + cfs(4) for this sort of situation.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mb3f8fff0efe927f263afe55f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[Joe S]

hiro:
    The purpose of doing this was not to just access multiple parts of the 
file. I was working off the quote below.  Maybe a file server thats purpose is 
to mux parts of another file sounded like fun. My thoughts are that you could 
then transer thoes chunks on a single destination on seperate connections.

eg.
    % mux -C 3 -F large.file
    % tree.
  ├── large.file
  └── large.file.mux
              ├── 1
              ├── 2
              └── 3

1 directory, 4 files

Like I said though still learning though.

On Wednesday, 30 December 2020, at 12:20 AM, cigar562hfsp952fans wrote:
> There is, however, a very simple reason why this approach won't really
work: the fids for a file opened on one connection won't be recognized
by the server on the other connection.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-Mb319f4f5aae92c0b9de48f76
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription