On Thu, Sep 8, 2011 at 12:44 PM, Bakul Shah <ba...@bitblocks.com> wrote: > On Thu, 08 Sep 2011 09:56:10 PDT John Floren <j...@jfloren.net> wrote: >> On Thu, Sep 8, 2011 at 9:31 AM, erik quanstrom <quans...@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, 23h...@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