[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] Intel atom system
I got the hardware (Supermicro X7SPA-H-D525, 4G RAM, 40G SATAII OCZ-2 SSD) and after a little poking at the etherdrivers, its up and running. I had to copy over some stuff from 9atom. Now I'm looking to get an old WiFi USB stick working. I haven't tried it yet, so it could just work. Time to start making cool 9programs!
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 ))
[9fans] C question - completely OT, but I'd like to know the answer
Sorry to bother the list, but I thought I might get a sensible answer
here from the few remaining people in the world who actually
understand C.
The following bit of code seems to be more or less syntactically OK:
switch (nurdge)
{
int nigel = 1;
case 0:
if(nigel == 1)
printf(nigel is one.\n);
else
printf(nigel is not one.\n);
default:
printf(The value of nigel is %d, nigel);
}
Something close to this compiles under my C compiler, and yet the
variable nigel is not initialised, and the test inside the first
case test is pretty much certain to print nigel is not one. Although
my C++ compiler does complain about an uninitialised variable.
I'm puzzled as to why the line int nigel = 1; is syntactically OK,
and although it seems to have declared the variable nigel - else the
following code would fail to compile - has failed to give it the
initial value of 1, as requested.
Re: [9fans] C question - completely OT, but I'd like to know the answer
On Thursday 08 of September 2011 11:41:05 Winston Kodogo wrote:
(...)
I'm puzzled as to why the line int nigel = 1; is syntactically OK,
and although it seems to have declared the variable nigel - else the
following code would fail to compile - has failed to give it the
initial value of 1, as requested.
consider the `switch' statement a switchboard that jumps to one of the
`case's.
nigel is not getting initialized because this code path is not executed -- as
it is not part of any `case' taken by the switch.
an `automatic' (non-static) variable is initialized by a piece of code, the
code gets executed whenever flow of control reaches that particular place.
a static variable (`static int inigel = 1') is initialized by static data,
before any code gets executed -- and only once. static will do what you
expect.
this is why you can place a static variable outside of any function and it
still gets initialized.
both kinds have their uses, in different situations.
for reference:
for (int i = 0; i 8; ++i) {
int nigel = 1; // this emits some code that gets executed for every loop and
resets the var to `1'
printf(nigel: %d,, nigel);
++nigel;
}
will print: nigel: 1,nigel: 1,nigel: 1, ...
on the other hand:
for (int i = 0; i 8; ++i) {
static int nigel = 1; // this var is initialized just once before main()
begins and doesn't reset
printf(nigel: %d,, nigel);
++nigel;
}
will print: nigel: 1,nigel: 2,nigel: 3, ...
--
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] C question - completely OT, but I'd like to know the answer
On Thursday 08 of September 2011 11:41:05 Winston Kodogo wrote: (stuff with switch/case) btw., the semantics of switch/case in C are quite elastic; there's a neat use of it: http://en.wikipedia.org/wiki/Duffs_device do/while interleaved with switch/case. -- 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 ))
[9fans] fossil deadlock
I can easily get fossil to deadlock. It would be great if anyone with fossil internals expertise could comment. As far as I can it tell from a stack dump it usually goes like: The snapshot thread has called cacheFlush with wait set to 1 to ensure all blocks are flushed to disk before continuing. It acquires dirtylk and then loops waiting for ndirty to become zero. In the loop it wakes flush to kick the flush thread and then sleeps on flushwait. Now the unlink thread tries to mark a block as dirty, and it gets stuck in blockDirty. It needs to increment ndirty, but can't acquire the dirtylk, as the snapshot thread is holding it. The flush thread is in _cacheLocalLookup. The block it was trying to return was in the process of being written by the disk thread so it waited for the io to complete. Subsequently the write finished and the block was declared clean but was grabbed by the unlink thread. The flush thread now can't reacquire the block lock on return from vtSleep(b-ioready). Does this sound feasible? Even if so, I'm not sure how to fix it. - rod Further notes: Probably not related, but occasionally I get an error similar to the following: fossil: diskReadRaw failed: /usr/glenda/test/fossil: score 0x00643e42: part=label block 6569538: illegal block address archive(0, 0xe51246a5): cannot find block: error reading block 0x00643e42 archWalk 0xe51246a5 failed; ptr is in 0x173d offset 0 archiveBlock 0x173d: error reading block 0x00643e42
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] Intel atom system
On Thu Sep 8 05:04:56 EDT 2011, steve.ruckdas...@gmail.com wrote: I got the hardware (Supermicro X7SPA-H-D525, 4G RAM, 40G SATAII OCZ-2 SSD) and after a little poking at the etherdrivers, its up and running. I had to copy over some stuff from 9atom. Now I'm looking to get an old WiFi USB stick working. I haven't tried it yet, so it could just work. Time to start making cool 9programs! if you run the 9atom kernel, you'll see all 4 processor threads. - erik
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...
