From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 08 Sep 2011 13:14:47 PDT." References: <9b73a2f7842fdf54ca57423261c7ae78@brasstown.quanstro.net> <201109081504.36357.dexen.devries@gmail.com> <20110908194409.743FBB827@mail.bitblocks.com> Date: Thu, 8 Sep 2011 13:35:47 -0700 From: Bakul Shah Message-Id: <20110908203547.C1CF1B827@mail.bitblocks.com> Subject: Re: [9fans] 9ttp Topicbox-Message-UUID: 1c3888d4-ead7-11e9-9d60-3106f5b1d025 On Thu, 08 Sep 2011 13:14:47 PDT John Floren wrote: > On Thu, Sep 8, 2011 at 12:44 PM, Bakul Shah 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.