[9fans] 9ttp

[9fans] 9ttp

[s s]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

With 9p's ability to send and receive arbitrary information as file i/o,
does http remain "necessary"?

Is there any reason that 9p cannot do this ...

''HTTP functions as a
request-response<http://en.wikipedia.org/wiki/Request-response>protocol
in the
client-server <http://en.wikipedia.org/wiki/Client-server> computing model.
In HTTP, a web browser <http://en.wikipedia.org/wiki/Web_browser>, for
example, acts as a *client*, while an application running on a computer
hosting <http://en.wikipedia.org/wiki/Host_%28network%29> a web
site<http://en.wikipedia.org/wiki/Web_site>functions as a
*server*. The client submits an HTTP *request* message to the server. The
server, which stores content, or provides *resources*, such as
HTML<http://en.wikipedia.org/wiki/HTML>files, or performs other
functions on behalf of the client, returns a
response message to the client. A response contains completion status
information about the request and may contain any content requested by the
client in its message body.''
  -- http://en.wikipedia.org/wiki/Http#Technical_overview

 - Leonard

[-- Attachment #2: Type: text/html, Size: 1482 bytes --]

Re: [9fans] 9ttp

[hiro]

HTTP is technically different and not easily comparable to 9p. HTTP is
not a good example of how to do things, but over high-latency links 9p
is much slower for getting files.

Re: [9fans] 9ttp

[dexen deVries]

On Thursday 08 of September 2011 10:36:00 s s wrote:
> With 9p's ability to send and receive arbitrary information as file i/o,
> does http remain "necessary"?
> 
> Is there any reason that 9p cannot do this ...


http works around high latency by packing as much information as sensible in 
one request, one response. http does not perform step-by-step hierarchy 
traversal, instead specifies whole pathname at once. http takes just one 
request/response to list whole directory (or similar). you need TCP (or 
similar) setup -- say, three packets, then one packet request (+ACK), one or 
few packets response (+ACK) and connection teardown.

9p seems to assume the latency is low enough to perform all both pathname and 
file operations separately.

you could create a 9p->http->9p bridge to work around high-latency links; it 
would gather a bunch of 9p operations: pathname traversal, file open, file read 
(sending locally fake `T' 9p responses to indicate success in spite of not 
doing any real work). it would then push them on-the-wire with just one http 
request. on the other end, the other process would issue locally several 9p 
requests to gather necessary data and respond with an usual http response -- 
which would get translated to Tread by the originating bridge process.

could get a bit hairy for writes.

-- 
dexen deVries

[[[↓][→]]]

For example, if the first thing in the file is:
   <?kzy irefvba="1.0" rapbqvat="ebg13"?>
an XML parser will recognize that the document is stored in the traditional 
ROT13 encoding.

(( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))

Re: [9fans] 9ttp

[Steve Simon]

> you could create a 9p->http->9p bridge to work around high-latency links

my understanding is, this is pretty much what octopus does for
comms, see http://lsub.org/ls/octopus.html, though it keeps within
the 9p protocol, but it adds some extra RPCs.

[Hope I have not muddled my project names here].

-Steve

Re: [9fans] 9ttp

[dexen deVries]

On Thursday 08 of September 2011 11:09:41 dexen wrote:
> you could create a 9p->http->9p bridge to work around high-latency links;
> it would gather a bunch of 9p operations (...)

the idea is NOT to serialize and send 9p packets themselves, but rather than 
to translate a bunch of 9p operations into one HTTP request/response.
send one HTTP GET with proper pathname, and obtain one HTTP 200 OK with the 
right content (possibly using Range header, possibly also requesting more data 
than strictly necessary and cache it locally to serve subsequent TReads, to 
avoid many HTTP requests for small amounts of data).

> could get a bit hairy for writes.

IIRC there's that `PATCH' HTTP method; not widely supported but could do.

TAuth could probably translate to HTTP Auth, at least to some extent. HTTP 
itself is stateless, but a pipelined HTTP connection could be equated to one 
authenticated 9p session.

-- 
dexen deVries

[[[↓][→]]]

For example, if the first thing in the file is:
   <?kzy irefvba="1.0" rapbqvat="ebg13"?>
an XML parser will recognize that the document is stored in the traditional 
ROT13 encoding.

(( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))

Re: [9fans] 9ttp

[hiro]

why do you want this??

Re: [9fans] 9ttp

[erik quanstrom]

On Thu Sep  8 04:52:08 EDT 2011, 23hiro@googlemail.com wrote:
> HTTP is technically different and not easily comparable to 9p. HTTP is
> not a good example of how to do things, but over high-latency links 9p
	with a single outstanding request
> is much slower for getting files.

there, fixed that for ya.

- erik

Re: [9fans] 9ttp

[dexen deVries]

On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote:
> On Thu Sep  8 04:52:08 EDT 2011, 23hiro@googlemail.com wrote:
> > HTTP is technically different and not easily comparable to 9p. HTTP is
> > not a good example of how to do things, but over high-latency links 9p
> 
> 	with a single outstanding request
> 
> > is much slower for getting files.
> 
> there, fixed that for ya.

is 9p windowable at all? is that implemented?


-- 
dexen deVries

[[[↓][→]]]

For example, if the first thing in the file is:
   <?kzy irefvba="1.0" rapbqvat="ebg13"?>
an XML parser will recognize that the document is stored in the traditional 
ROT13 encoding.

(( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))

Re: [9fans] 9ttp

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Thu, Sep 8, 2011 at 1:51 AM, hiro <23hiro@googlemail.com> wrote:

> HTTP is technically different and not easily comparable to 9p. HTTP is
> not a good example of how to do things, but over high-latency links 9p
> is much slower for getting files.
>
> HTTP tries to be stateless as well.  Hence REST.  9p is a fairly stateful
protocol.
... but then so is NFSv4, and 9p remains simpler.

There's also pi-P documented somewhere that takes the ideas of 9p and makes
them more applicable to the space where http is interesting, as well as
others.

Dave

[-- Attachment #2: Type: text/html, Size: 859 bytes --]

Re: [9fans] 9ttp

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Thu, Sep 8, 2011 at 6:04 AM, dexen deVries <dexen.devries@gmail.com>wrote:

> On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote:
> > On Thu Sep  8 04:52:08 EDT 2011, 23hiro@googlemail.com wrote:
> > > HTTP is technically different and not easily comparable to 9p. HTTP is
> > > not a good example of how to do things, but over high-latency links 9p
> >
> >       with a single outstanding request
> >
> > > is much slower for getting files.
> >
> > there, fixed that for ya.
>
> is 9p windowable at all? is that implemented?
>
>
>
9p has tagged requests.  The client chooses them, and therefore, for certain
servers you can overlap requests and get reasonable performance.  I've
designed very simplistic protocols like this before, and they typically pan
out nicely.  I had a simple request/response system for issuing commands to
a C program that would fetch data of CAN bus connected microcontrollers.
It was very nice to work with as you could drive the C program from
basically any programming language.  I ended up using Erlang.  Go wasn't
really quite available yet :-).

Dave


> --
> dexen deVries
>
> [[[↓][→]]]
>
> For example, if the first thing in the file is:
>   <?kzy irefvba="1.0" rapbqvat="ebg13"?>
> an XML parser will recognize that the document is stored in the traditional
> ROT13 encoding.
>
> (( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))
>
>

[-- Attachment #2: Type: text/html, Size: 2230 bytes --]

Re: [9fans] 9ttp

[erik quanstrom]

> > On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote:
> > > On Thu Sep  8 04:52:08 EDT 2011, 23hiro@googlemail.com wrote:
> > > > HTTP is technically different and not easily comparable to 9p. HTTP is
> > > > not a good example of how to do things, but over high-latency links 9p
> > >
> > >       with a single outstanding request
> > >
> > > > is much slower for getting files.
> > >
> > > there, fixed that for ya.
> >
> > is 9p windowable at all? is that implemented?
> >
> >
> >
> 9p has tagged requests.

cf. /sys/src/cmd/fcp.c

- erik

Re: [9fans] 9ttp

[John Floren]

On Thu, Sep 8, 2011 at 9:31 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote:
>> > > On Thu Sep  8 04:52:08 EDT 2011, 23hiro@googlemail.com wrote:
>> > > > HTTP is technically different and not easily comparable to 9p. HTTP is
>> > > > not a good example of how to do things, but over high-latency links 9p
>> > >
>> > >       with a single outstanding request
>> > >
>> > > > is much slower for getting files.
>> > >
>> > > there, fixed that for ya.
>> >
>> > is 9p windowable at all? is that implemented?
>> >
>> >
>> >
>> 9p has tagged requests.
>
> cf. /sys/src/cmd/fcp.c
>
> - erik
>
>

I do not think it is acceptable to have to fork repeatedly merely to
efficiently read a file. Also, as far as I can tell, exactly one
program (fcp) does that.

Can a single process have multiple outstanding requests? My
investigations indicated not, but then again I may have mis-read
things.


John

Re: [9fans] 9ttp

[ron minnich]

On Thu, Sep 8, 2011 at 9:56 AM, John Floren <john@jfloren.net> wrote:

> I do not think it is acceptable to have to fork repeatedly merely to
> efficiently read a file. Also, as far as I can tell, exactly one
> program (fcp) does that.
>
> Can a single process have multiple outstanding requests? My
> investigations indicated not, but then again I may have mis-read
> things.

So, John, you don't think it's reasonable to rewrite every program a
la fcp? How unreasonable of you :-)

ron

Re: [9fans] 9ttp

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Thu, Sep 8, 2011 at 9:59 AM, ron minnich <rminnich@gmail.com> wrote:

> On Thu, Sep 8, 2011 at 9:56 AM, John Floren <john@jfloren.net> wrote:
>
> > I do not think it is acceptable to have to fork repeatedly merely to
> > efficiently read a file. Also, as far as I can tell, exactly one
> > program (fcp) does that.
> >
> > Can a single process have multiple outstanding requests? My
> > investigations indicated not, but then again I may have mis-read
> > things.
>
> So, John, you don't think it's reasonable to rewrite every program a
> la fcp? How unreasonable of you :-)
>
> ron
>
> "Perhaps if we built a large wooden badger..."

[-- Attachment #2: Type: text/html, Size: 1047 bytes --]

Re: [9fans] 9ttp

[erik quanstrom]

> > Can a single process have multiple outstanding requests? My
> > investigations indicated not, but then again I may have mis-read
> > things.
>
> So, John, you don't think it's reasonable to rewrite every program a
> la fcp? How unreasonable of you :-)

alternatively, the mount driver could be rewritten.

- erik

Re: [9fans] 9ttp

[EBo]

 On Thu, 8 Sep 2011 10:18:16 -0700, David Leimbach wrote:
> On Thu, Sep 8, 2011 at 9:59 AM, ron minnich <rminnich@gmail.com>
> wrote:
>
>> On Thu, Sep 8, 2011 at 9:56 AM, John Floren <john@jfloren.net>
>> wrote:
>>
>> > I do not think it is acceptable to have to fork repeatedly merely
>> to
>> > efficiently read a file. Also, as far as I can tell, exactly one
>> > program (fcp) does that.
>> >
>> > Can a single process have multiple outstanding requests? My
>> > investigations indicated not, but then again I may have mis-read
>> > things.
>>
>> So, John, you don't think it's reasonable to rewrite every program a
>> la fcp? How unreasonable of you :-)
>
> "Perhaps if we built a large wooden badger..."

 On Thu, 8 Sep 2011 13:20:37 -0400, erik quanstrom wrote:
>
> alternatively, the mount driver could be rewritten.

 coconuts?

   EBo --

Re: [9fans] 9ttp

[Bakul Shah]

On Thu, 08 Sep 2011 09:56:10 PDT John Floren <john@jfloren.net>  wrote:
> On Thu, Sep 8, 2011 at 9:31 AM, erik quanstrom <quanstro@quanstro.net> wrot=
> e:
> >> > On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote:
> >> > > On Thu Sep =A08 04:52:08 EDT 2011, 23hiro@googlemail.com wrote:
> >> > > > HTTP is technically different and not easily comparable to 9p. HTT=
> P is
> >> > > > not a good example of how to do things, but over high-latency link=
> s 9p
> >> > >
> >> > > =A0 =A0 =A0 with a single outstanding request
> >> > >
> >> > > > is much slower for getting files.
> >> > >
> >> > > there, fixed that for ya.
> >> >
> >> > is 9p windowable at all? is that implemented?
> >> >
> >> >
> >> >
> >> 9p has tagged requests.
> >
> > cf. /sys/src/cmd/fcp.c
> >
> > - erik
> >
> >
>
> I do not think it is acceptable to have to fork repeatedly merely to
> efficiently read a file. Also, as far as I can tell, exactly one
> program (fcp) does that.
>
> Can a single process have multiple outstanding requests? My
> investigations indicated not, but then again I may have mis-read
> things.

Is there a way to distinguish between files backed by real
storage & synthetic files? Seems to me that the server
wouldn't know if you pipelined multiple read/write requests on
a given connection (in-order delivery). May be the client can
do read-ahead of N blocks. But one issue with read-ahead /
write-behind is the problem of head of line blocking --
further non-r/w requests queue up behind them. That is why FTP
uses a control connection for all the commands & responses but
data is delivered on a fresh tcp connection.

Re: [9fans] 9ttp

[John Floren]

On Thu, Sep 8, 2011 at 12:44 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> On Thu, 08 Sep 2011 09:56:10 PDT John Floren <john@jfloren.net>  wrote:
>> On Thu, Sep 8, 2011 at 9:31 AM, erik quanstrom <quanstro@quanstro.net> wrot=
>> e:
>> >> > On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote:
>> >> > > On Thu Sep =A08 04:52:08 EDT 2011, 23hiro@googlemail.com wrote:
>> >> > > > HTTP is technically different and not easily comparable to 9p. HTT=
>> P is
>> >> > > > not a good example of how to do things, but over high-latency link=
>> s 9p
>> >> > >
>> >> > > =A0 =A0 =A0 with a single outstanding request
>> >> > >
>> >> > > > is much slower for getting files.
>> >> > >
>> >> > > there, fixed that for ya.
>> >> >
>> >> > is 9p windowable at all? is that implemented?
>> >> >
>> >> >
>> >> >
>> >> 9p has tagged requests.
>> >
>> > cf. /sys/src/cmd/fcp.c
>> >
>> > - erik
>> >
>> >
>>
>> I do not think it is acceptable to have to fork repeatedly merely to
>> efficiently read a file. Also, as far as I can tell, exactly one
>> program (fcp) does that.
>>
>> Can a single process have multiple outstanding requests? My
>> investigations indicated not, but then again I may have mis-read
>> things.
>
> Is there a way to distinguish between files backed by real
> storage & synthetic files? Seems to me that the server
> wouldn't know if you pipelined multiple read/write requests on
> a given connection (in-order delivery). May be the client can
> do read-ahead of N blocks. But one issue with read-ahead /
> write-behind is the problem of head of line blocking --
> further non-r/w requests queue up behind them. That is why FTP
> uses a control connection for all the commands & responses but
> data is delivered on a fresh tcp connection.
>
>

See my thesis for an FTP-like extension to 9P
(https://bitbucket.org/floren/tstream/src/67c7419ad84a/documents/Thesis.pdf)
in which 9P messages are used to negotiate a separate TCP data stream,
avoiding the blocking problem. It achieved transfer performance
equivalent to that of HTTP over a high-latency link.

Deja vu here--I know we just discussed this about a month ago :)


John

Re: [9fans] 9ttp

[erik quanstrom]

> Is there a way to distinguish between files backed by real
> storage & synthetic files?

that's the wrong distinction.  ramfs is syntetic and so is /dev/sd00/raw.

i'm not so sure that you have to make this distinction anyway.  it's enough
for the the application to request > iounit bytes at a time.

- erik

Re: [9fans] 9ttp

[Bakul Shah]

On Thu, 08 Sep 2011 13:14:47 PDT John Floren <john@jfloren.net>  wrote:
> On Thu, Sep 8, 2011 at 12:44 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> >
> > Is there a way to distinguish between files backed by real
> > storage & synthetic files? Seems to me that the server
> > wouldn't know if you pipelined multiple read/write requests on
> > a given connection (in-order delivery). May be the client can
> > do read-ahead of N blocks. But one issue with read-ahead /
> > write-behind is the problem of head of line blocking --
> > further non-r/w requests queue up behind them. That is why FTP
> > uses a control connection for all the commands & responses but
> > data is delivered on a fresh tcp connection.
>
> See my thesis for an FTP-like extension to 9P
> (https://bitbucket.org/floren/tstream/src/67c7419ad84a/documents/Thesis.pdf)
> in which 9P messages are used to negotiate a separate TCP data stream,
> avoiding the blocking problem. It achieved transfer performance
> equivalent to that of HTTP over a high-latency link.
>
> Deja vu here--I know we just discussed this about a month ago :)

Deja vu all over again. We seem have this discussion every N months.

But why do you need to extend the protocol? Just use a new
connection for every file from a local proxy or something! I
will have to read your thesis.

Re: [9fans] 9ttp

[Francisco J Ballesteros]

And it's likely we'll have it again :)

For nix, I've just implemented something called IX, while is mostly
multiplexing a single stream to provide concurrent channels and then send
modified 9p requests on them, to be able to put/get entire files like op does.
The server seems to work, and the protocol, according to early testing,
I'm with a caching client doing 9p<>IX, as we speak.


>> Deja vu here--I know we just discussed this about a month ago :)
>
> Deja vu all over again. We seem have this discussion every N months.
>

Re: [9fans] 9ttp

[Bruce Ellis]

Can I just say this is the first time I've been on television?

On 9 September 2011 06:43, Francisco J Ballesteros <nemo@lsub.org> wrote:
> And it's likely we'll have it again :)
>
> For nix, I've just implemented something called IX, while is mostly
> multiplexing a single stream to provide concurrent channels and then send
> modified 9p requests on them, to be able to put/get entire files like op does.
> The server seems to work, and the protocol, according to early testing,
> I'm with a caching client doing 9p<>IX, as we speak.
>
>
>>> Deja vu here--I know we just discussed this about a month ago :)
>>
>> Deja vu all over again. We seem have this discussion every N months.
>>
>
>



--
Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)

Re: [9fans] 9ttp

[Venkatesh Srinivas]

Just asynchronous TClunk is enough to improve 9P's performance over
high-latency links dramatically.

-- vs

Re: [9fans] 9ttp

[ron minnich]

On Thu, Sep 8, 2011 at 4:19 PM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
> Just asynchronous TClunk is enough to improve 9P's performance over
> high-latency links dramatically.

not my experience, but I'm willing to be convinced.

ron

Re: [9fans] 9ttp

[erik quanstrom]

On Thu Sep  8 19:31:19 EDT 2011, rminnich@gmail.com wrote:
> On Thu, Sep 8, 2011 at 4:19 PM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
> > Just asynchronous TClunk is enough to improve 9P's performance over
> > high-latency links dramatically.
>
> not my experience, but I'm willing to be convinced.

iirc, async clunks are dangerous.

- erik

Re: [9fans] 9ttp

[Venkatesh Srinivas]

Using the hacky inferno-npe async clunk implementation, from october
2010; from a Linux server running inferno-npe to a Linux client
running inferno-npe; latency ~15ms. Getting the sources of cwfs from
the server fell from 5.6 sec to 4.5 sec. For the 9 kernel sources, 51
sec fell to 41 sec.

Got better results with sources (40ms away) but don't have the numbers handy.

-- vs

Re: [9fans] 9ttp

[Venkatesh Srinivas]

On Thu, Sep 8, 2011 at 7:32 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Thu Sep  8 19:31:19 EDT 2011, rminnich@gmail.com wrote:
>> On Thu, Sep 8, 2011 at 4:19 PM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
>> > Just asynchronous TClunk is enough to improve 9P's performance over
>> > high-latency links dramatically.
>>
>> not my experience, but I'm willing to be convinced.
>
> iirc, async clunks are dangerous.
>
> -erik

I never agreed with that conclusion from the oct 2010 discussion here.

-- vs

Re: [9fans] 9ttp

[Eric Van Hensbergen]

On Thu, Sep 8, 2011 at 5:49 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> Can I just say this is the first time I've been on television?
>

sorry, there isn't time, we're just about to get another result...

Re: [9fans] 9ttp

[Charles Forsyth]

>> iirc, async clunks are dangerous.
>>
>> -erik

>I never agreed with that conclusion from the oct 2010 discussion here.

`dangerous' is not the right word; they simply confound the use of the protocol

Re: [9fans] 9ttp

[Bruce Ellis]

I think that all good, right thinking people in this country are sick
and tired of being told that all good, right thinking people in this
country are fed up with being told that all good, right thinking
people in this country are fed up with being sick and tired.

I'm certainly not, and I'm sick and tired of being told that I am!

On 9 September 2011 18:13, Charles Forsyth <forsyth@terzarima.net> wrote:
>>> iirc, async clunks are dangerous.
>>>
>>> -erik
>
>>I never agreed with that conclusion from the oct 2010 discussion here.
>
> `dangerous' is not the right word; they simply confound the use of the protocol
>
>



--
Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)

Re: [9fans] 9ttp

[dexen deVries]

On Friday 09 of September 2011 11:26:18 Bruce Ellis wrote:
> I think that all good, right thinking people in this country are sick
> and tired of being told that all good, right thinking people in this
> country are fed up with being told that all good, right thinking
> people in this country are fed up with being sick and tired.

what was the Plan 9 stack limit again? ;-)

Re: [9fans] 9ttp

[Bruce Ellis]

That was a seriously good get.

I've heard there is a serious build up of SAT (surface-to-air tapas)
deployment in Spain.

I will talk about Inferno Multi Processor experience in these matters
in a WIP, or a tapas bar. Unfortunately my Spanish tutor was deported
for unspecified reasons, and listening to Molotov and watching the SBS
Spanish news is not cutting it - unless of course the workshop moves
to East LA or I need to talk on the World Economy or Mid East unrest.

Might need the Shaney "just hit the n key" post for this thread so it
doesn't diverge and end up on slash-dot talking about video card
performance.

OT I had to fill in a confusing, lengthy, government form yesterday
and it asked me to list my aliases. I listed Mark V. Shaney just to
take attention off the rest of the form. Well, I listed my US Bounty
Hunter License as a qualification.

Tclunk,

brucee

On 9 September 2011 19:36, dexen deVries <dexen.devries@gmail.com> wrote:
> On Friday 09 of September 2011 11:26:18 Bruce Ellis wrote:
>> I think that all good, right thinking people in this country are sick
>> and tired of being told that all good, right thinking people in this
>> country are fed up with being told that all good, right thinking
>> people in this country are fed up with being sick and tired.
>
> what was the Plan 9 stack limit again? ;-)
>
>
>



--
Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)