From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20110908194409.743FBB827@mail.bitblocks.com> References: <9b73a2f7842fdf54ca57423261c7ae78@brasstown.quanstro.net> <201109081504.36357.dexen.devries@gmail.com> <20110908194409.743FBB827@mail.bitblocks.com> Date: Thu, 8 Sep 2011 13:14:47 -0700 Message-ID: From: John Floren To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9ttp Topicbox-Message-UUID: 1c1c461a-ead7-11e9-9d60-3106f5b1d025 On Thu, Sep 8, 2011 at 12:44 PM, Bakul Shah wrote: > On Thu, 08 Sep 2011 09:56:10 PDT John Floren =A0wrote: >> On Thu, Sep 8, 2011 at 9:31 AM, erik quanstrom w= rot=3D >> e: >> >> > On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote: >> >> > > On Thu Sep =3DA08 04:52:08 EDT 2011, 23hiro@googlemail.com wrote: >> >> > > > HTTP is technically different and not easily comparable to 9p. = HTT=3D >> P is >> >> > > > not a good example of how to do things, but over high-latency l= ink=3D >> s 9p >> >> > > >> >> > > =3DA0 =3DA0 =3DA0 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