Re: [9fans] 9ttp
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
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 fors...@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
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
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.devr...@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)
[9fans] 9ttp
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-responsehttp://en.wikipedia.org/wiki/Request-responseprotocol 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 sitehttp://en.wikipedia.org/wiki/Web_sitefunctions as a *server*. The client submits an HTTP *request* message to the server. The server, which stores content, or provides *resources*, such as HTMLhttp://en.wikipedia.org/wiki/HTMLfiles, 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
Re: [9fans] 9ttp
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
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
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
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
On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote: On Thu Sep 8 04:52:08 EDT 2011, 23h...@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
On Thu, Sep 8, 2011 at 1:51 AM, hiro 23h...@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
Re: [9fans] 9ttp
On Thu, Sep 8, 2011 at 6:04 AM, dexen deVries dexen.devr...@gmail.comwrote: On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote: On Thu Sep 8 04:52:08 EDT 2011, 23h...@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 ))
Re: [9fans] 9ttp
On Thu, Sep 8, 2011 at 9:31 AM, erik quanstrom quans...@quanstro.net wrote: On Thursday 08 of September 2011 14:54:40 erik quanstrom wrote: On Thu Sep 8 04:52:08 EDT 2011, 23h...@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
On Thu, Sep 8, 2011 at 9:56 AM, John Floren j...@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
On Thu, Sep 8, 2011 at 9:59 AM, ron minnich rminn...@gmail.com wrote: On Thu, Sep 8, 2011 at 9:56 AM, John Floren j...@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...
Re: [9fans] 9ttp
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
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.
Re: [9fans] 9ttp
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
Re: [9fans] 9ttp
On Thu, 08 Sep 2011 13:14:47 PDT John Floren j...@jfloren.net wrote: On Thu, Sep 8, 2011 at 12:44 PM, Bakul Shah ba...@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
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
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 9pIX, 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
Can I just say this is the first time I've been on television? On 9 September 2011 06:43, Francisco J Ballesteros n...@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 9pIX, 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
Just asynchronous TClunk is enough to improve 9P's performance over high-latency links dramatically. -- vs
Re: [9fans] 9ttp
On Thu, Sep 8, 2011 at 4:19 PM, Venkatesh Srinivas m...@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
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
On Thu Sep 8 19:31:19 EDT 2011, rminn...@gmail.com wrote: On Thu, Sep 8, 2011 at 4:19 PM, Venkatesh Srinivas m...@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
On Thu, Sep 8, 2011 at 7:32 PM, erik quanstrom quans...@quanstro.net wrote: On Thu Sep 8 19:31:19 EDT 2011, rminn...@gmail.com wrote: On Thu, Sep 8, 2011 at 4:19 PM, Venkatesh Srinivas m...@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
On Thu, Sep 8, 2011 at 5:49 PM, Bruce Ellis bruce.el...@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...
