Francisco J Ballesteros wrote:
> Don't know, but we have strong group on that on the other corridor of
> the building.
> They count lines, and count, and count...
> They use Linux mostly, and have a huge ammount of lines to count.
Of course :-)
But then not many people are "fortunate enough" to se
Tags were introduced on November 21, 1990:
http://swtch.com/go/fid2tag
Thanksgiving weekend. We kicked everyone off for the weekend
and redid 9P to fix all the problems we'd figured out so far.
-rob
Note that
if (stat()){
open
read
close
}
is not new code. It's code in ls, 8c, mk, acme, etc. etc. etc.
The point is how to make that code work nicely across bad latency links.
But you do not want to change that code.
Also, there's no overhead if you don't use our stuff while "within the
On Sat, 2007-06-23 at 15:36 +0200, Francisco J Ballesteros wrote:
>
> Now, say you have a program that does:
> if (stat(afile)){
>open(afile)
>read(afile)
>close(afile)
> }
>
So those are 9P's bad manners. How many such idioms can one subsume
into a "caching" process? Because in my
It would be fine to just use the same tag as suggested by Russ ans Sape
if you just happen to have several 9P requests that you know that have
to be issued
to serve a particular call. For example, say you add a library
function (or syscall)
get(),
you could send Twalk tag3 nfid F Topen fid F, Trea
I thought russ (and charles and sape?) proposed a good solutions to
the latency issues in 9P at IWP9. Actually as far as I can remember it
was the only change to 9P that was accepted as justified.
My memory is bad, probably got the details wrong but I think there
were two approaches: one by allow
On Sat, 2007-06-23 at 08:08 -0400, erik quanstrom wrote:
> are there any protocols that deal well with latency?
>
IP does by design. The correct approach to the problem is the
sliding-window technique and I can only presume that applications that
suffer from high latency are written to conflict w
Yes, but latency from Madrid to Greece is 150ms (rtt, icmp) and that
I'd say is going
to stay that way for a long time. To the US (east coast) it's 120ms.
I still like to use my system while in the move.
Regarding protocols, lbfs is nice, but focuses on bandwidth and so, it
requires multiple
RPC
> 9P is just great for use when latency is reasonable (or not too bad,
> with cfs), but to go further
> away and still be comfortable using remote files, I'd say we need
> another protocol.
> I'd love to be proved wrong :)
are there any protocols that deal well with latency?
the only way i know t
Don't know, but we have strong group on that on the other corridor of
the building.
They count lines, and count, and count...
They use Linux mostly, and have a huge ammount of lines to count.
On 6/23/07, Skip Tavakkolian <[EMAIL PROTECTED]> wrote:
> Tags were introduced on November 21, 1990:
> h
Thank you Russ.
Russ Cox a écrit :
So unless Russ is right and that the
fact FIDS are choosen by the client has
been decided arbitrarily ... I still have
no answer to my question.
In the current version of 9P, there is no reason
why the client has to choose the fids (file ids).
You don't
> Tags were introduced on November 21, 1990:
> http://swtch.com/go/fid2tag
good question and great historical perspective.
is software archaeology a formal discipline yet?
> So unless Russ is right and that the
> fact FIDS are choosen by the client has
> been decided arbitrarily ... I still have
> no answer to my question.
In the current version of 9P, there is no reason
why the client has to choose the fids (file ids).
You don't have to believe me, but it's true.
I don't think so. Because we try to use results from past, and not to
look ahead.
On 6/23/07, Roman Shaposhnick <[EMAIL PROTECTED]> wrote:
On Sat, 2007-06-23 at 01:48 +0200, Francisco J Ballesteros wrote:
> Skip wrote:
> :there were discussions about aysnc syscalls. /sys/src/cmd/fcp.c is a
> :
On Sat, 2007-06-23 at 01:48 +0200, Francisco J Ballesteros wrote:
> Skip wrote:
> :there were discussions about aysnc syscalls. /sys/src/cmd/fcp.c is a
> :good example of why they're not needed. streaming and long delay
> :networks can be handled this way too, as was pointed out (by Russ i
> :thi
Skip wrote:
:there were discussions about aysnc syscalls. /sys/src/cmd/fcp.c is a
:good example of why they're not needed. streaming and long delay
:networks can be handled this way too, as was pointed out (by Russ i
:think) at iwp9.
But there is one problem. Consider "lc".
Usually you see
wal
there were discussions about aysnc syscalls. /sys/src/cmd/fcp.c is a
good example of why they're not needed. streaming and long delay
networks can be handled this way too, as was pointed out (by Russ i
think) at iwp9.
David Leimbach wrote:
> Perhaps that's why google's not doing full SOAP anymore and just
> returning XML that you have to parse yourself on the client side.
If they wanted to "leave" things to the client side, they wouldn't use
XML at all.
--
Anant
On 6/22/07, Philippe Anel <[EMAIL PROTECTED]> wrote:
Sometimes, I whish I could think faster.
The fact request can be pipelined like this -I mean, by taking care of the
fact replies are not necessarly returned in requests order- doesn't not
mean that clients have to choose the FIDs. This would
Sometimes, I whish I could think faster.
The fact request can be pipelined like this -I mean, by taking care of the
fact replies are not necessarly returned in requests order- doesn't not
mean that clients have to choose the FIDs. This would also work if FIDs
are choosen by the server (and even
Ok I agree ... as long as you don't expect the replies to be returned
in the same order as the requests, requests can be pipelined.
Therefore, now it makes sense to have FIDs chosen by the client.
Thank you.
Well you may have a point, but why not
1. send: open, fid, file
2. wait for reply to
On 6/22/07, Philippe Anel <[EMAIL PROTECTED]> wrote:
David Leimbach a écrit :
> Transactions are tagged right? So you can, in fact, have many in
> flight at once.
>
> Perhaps I'm missing what you meant by pipelined.
I meant sending a couple of requests on one fid before receiving
replies.
T
My bad, I'm not a good english writter ... I meant replies to request are
not supposed to be returned in request order.
Skip Tavakkolian a écrit :
So I think you should not pipeline the requests.
Can a 9P specialist can confirm this ?
not true.
David Leimbach a écrit :
Transactions are tagged right? So you can, in fact, have many in
flight at once.
Perhaps I'm missing what you meant by pipelined.
I meant sending a couple of requests on one fid before receiving
replies.
Yes transaction are tagged, this doesn't mean that requests are
> So I think you should not pipeline the requests.
> Can a 9P specialist can confirm this ?
not true.
Transactions are tagged right? So you can, in fact, have many in flight at
once.
Perhaps I'm missing what you meant by pipelined.
On 6/22/07, Philippe Anel <[EMAIL PROTECTED]> wrote:
Well even if it can work, I don't think 9P was designed to allow such
type of
operation. Indeed, 9P basis is t
Well even if it can work, I don't think 9P was designed to allow such
type of
operation. Indeed, 9P basis is the transaction : ie a Request followed
by a Reply.
So I think you should not pipeline the requests.
Can a 9P specialist can confirm this ? If so ... I now understand why
Fids are
(or m
On Fri, Jun 22, 2007 at 08:58:04AM +0200, Philippe Anel wrote:
> What do you mean ?
Well, I've not read the protocol details for a while.
But from memory I thought it allowed this type of operation:
send: open,fid,file
send: read,fid,args
send: read,fid,args
(wait one rtt)
What do you mean ?
Derek Fawcus a écrit :
On Tue, Jun 19, 2007 at 10:11:31PM +0200, Philippe Anel wrote:
Can someone explain me the reason why the Fids are not returned
by the server (along with the Qids by example) ?
I always assumed it was to enable pipelined operations.
DF
On Tue, Jun 19, 2007 at 10:11:31PM +0200, Philippe Anel wrote:
>
> Can someone explain me the reason why the Fids are not returned
> by the server (along with the Qids by example) ?
I always assumed it was to enable pipelined operations.
DF
perhaps my sense of humor's tweaked, but i understood russ' comment to
be sarcastic, since the added complexity of making fid lookup slightly
faster on both ends seems hard to justify given how vastly outweighed
fid lookup is bound to be by the encryption-related operations.
On Tue, 2007-06-19 at 20:37 -0400, Russ Cox wrote:
> Because after
> all the encryption and public key operations, it's really
> looking up the fids that is eating all the cpu.
Now this is an interesting point, because it sort of argues
in favor of doing the lookups on the client and conserving
> Because Fids are chosen by the client, the server must search in
> a table (hash table in lib9p) the associated file structure, Whereas
> if Fids are chosen by the server, a simple array is enough. I don't
> know however, if the performance improvement is really important.
> In fact I'm quite sur
Hello 9fans,
Regarding 9P design, I wonder why Fids are chosen by the client :
I tried to find an answer in the docs, manuals or in 9fans archive
but I have not found an answer (please tell me where I can find
an answer if I missed something).
Can someone explain me the reason why the Fids are n
34 matches
Mail list logo
