On Wed, Jan 27, 2021, at 11:25, Ethan Gardener wrote:
> fcp(1)?
You are right, but fcp(1) would only produce multiple parallel read
and write messages, I'm talking about a more general approach. fcp is
probably a better compromise, though, as ori points out the client can
get complicated pretty
I found several of Bryan Ford's ideas interesting as always here,
particularly Structured Streams (https://bford.info/pub/net/sst-abs/) and
Breaking Up the Transport Logjam (https://bford.info/pub/net/logjam-abs/)
On Wed, Jan 27, 2021 at 4:53 PM wrote:
> Quoth David Arroyo :
> > On Tue, Dec 29,
Quoth David Arroyo :
> On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote:
> > It's well-known that 9P has trouble transferring large files (high
> > volume/high bandwith) over high-latency networks, such as the Internet.
>
> From what I know of 9P, I don't think this is the
On Mon, Jan 25, 2021, at 10:31 PM, David Arroyo wrote:
> On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote:
> > It's well-known that 9P has trouble transferring large files (high
> > volume/high bandwith) over high-latency networks, such as the Internet.
>
> From what I know
On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote:
> It's well-known that 9P has trouble transferring large files (high
> volume/high bandwith) over high-latency networks, such as the Internet.
>From what I know of 9P, I don't think this is the fault of the protocol
itself.
Quoth 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
yes but there is no benefit to do that
On 1/5/21, Joe S wrote:
> 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
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
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
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
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
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
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 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
14 matches
Mail list logo
