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 "Sat, 19 Feb 2011 16:15:47 EST." <98f813a8949fced7833e956973b97a99@brasstown.quanstro.net> References: <201102181445.41877.dexen.devries@gmail.com> <201102181753.30125.dexen.devries@gmail.com> <7769a67a9fbc1fae2186ff9315457e0d@ladd.quanstro.net> <20110219200901.575D75B63@mail.bitblocks.com> <98f813a8949fced7833e956973b97a99@brasstown.quanstro.net> From: Bakul Shah Date: Sun, 20 Feb 2011 15:49:29 -0800 Message-Id: <20110220234929.DA23A5B58@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b2882318-ead6-11e9-9d60-3106f5b1d025 On Sat, 19 Feb 2011 16:15:47 EST erik quanstrom wrote: > > > what is the goal? > > > > Better handling of latency at a minimum? If I were to do > > this I would experiment with extending the channel concept. > > hmm. let me try again ... do you have a concrete goal? > it's hard to know why a new file protocol would be necessary > given the very abstract goal of "reduced latency". Not reduced latency but increased throughput by streaming. Obviously a new protocol is not "necessary" but something worth exploring is what I said. > for example, i would like to use 1 file server at 3 locations. > 2 on the east coast, 1 on the west coast. the rtt is a:b 80ms > a:c 20ms b:c 100ms. i don't think any sort of streaming will > help that much. 100ms is a long time. i think (pre)caching will > need to be the answer. Caching is definitely worth doing but you don't always have the opportunity to do it. If you are copying a lot of files across, it would help quite a bit if you can just pipeline requests (or send fewer bundled requests). If you are copying very large files, streaming would help. When copying large amounts of data from various sources to a local file server, caching is not very relevant.