From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5d375e920809180348t283e287bmba2ad66f5f09994e@mail.gmail.com> Date: Thu, 18 Sep 2008 12:48:44 +0200 From: Uriel To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <20080918103631.GG29361@hermes.my.domain> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <140e7ec30809180257y34722805y287fd9838bd76f35@mail.gmail.com> <20080918103631.GG29361@hermes.my.domain> Subject: Re: [9fans] 9p over high-latency Topicbox-Message-UUID: 11c3bb60-ead4-11e9-9d60-3106f5b1d025 Actually, this whole subject was thoroughly discussed at the *first* iwp9; but apparently nobody is bothered by this enough to implement any of the then suggested solutions. Op is not one the solutions discussed at the time, and saying 'just use another protocol' is not a way to resolve the shortcomings 9P clearly has. Moreover most of the solutions discussed back then seemed quite clear and would be (mostly) backwards compatible, so I still don't understand why Op was created rather than implement one of those solutions, although my understanding is that nemo and co. considered it easier (ie., didn't involve changing other people's code?). Also worth noting is that Op has some serious shortcomings, if I recall correctly it fails to translate some important 9P semantics like walks, which means that while Op can transparently proxy 9P connections, certain file servers wont work properly (I might be mistaken, and certainly don't remember the details). This is not to say that there is no use for a protocol like Op (it shares much in common with http, which clearly has found lots of use in the 'real world'). Peace uriel On Thu, Sep 18, 2008 at 12:36 PM, Christian Kellermann wrote: > * sqweek [080918 12:02]: >> On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom wrote: >> > as an aside: i don't think 9p itself limits plan 9 performance >> > over high-latency links. the limitations have more to do with >> > the number of outstanding messages, which is 1 in the mnt >> > driver. >> >> Hm, but what's the alternative here? Readahead seems somewhat >> attractive, if difficult (I worry about blocking reads and timing >> sensitive file systems). But there's one problem I can't resolve - how >> do you know what offset to Tread without consulting the previous >> Rread's count? >> Actually, I understand there has been discussion about grouping tags >> to allow for things like Twalk/Topen batching without waiting for >> Rwalk (which sounds like a great idea), maybe that would work here >> also... > > There are some interesting approaches which have been discussed at the last iwp9, including op from nemo's team. > http://plan9.bell-labs.com/iwp9/papers/10.op.esoriano.pdf > > Maybe that is worth looking at for your issue? > > Kind regards, > > Christian > > -- > You may use my gpg key for replies: > pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen) >