s/over 9p/higher than 9p/ On 5/29/22, fge...@gmail.com <fge...@gmail.com> wrote: > As a first approximation - assuming identical namespaces - this > multiplier 9p server (9plier? multi9plier?) could be trivially(?) > useful, used with recover(4) on all connections and with an > independent synchronization mechanism, in case states would fall out > of sync. > > Furthermore I would not rule out usefulness if the namespaces are not > identical, though I think a higher level model (over 9p) would need to > be considered to built anything useful. > Thanks for your insight! > > On 5/28/22, Skip Tavakkolian <skip.tavakkol...@gmail.com> wrote: >> Interesting idea! >> >> This assumes the downstream servers have identical namespace hierarchy; >> right? >> >> State management could be messy or impossible unless some sort of >> transaction structure is imposed on the {walk, [open/create, >> read/write]|[stat/wstat], clunk} sequences, where the server that >> replies to walk first, gets that transaction. >> >> On Sat, May 28, 2022 at 9:04 AM <fge...@gmail.com> wrote: >>> >>> Has anybody considered (or maybe even implemented) a 9p server to >>> multiply incoming 9p messages to 2 or more 9p servers? >>> Maybe with 2 different strategies for responding to the original >>> request? >>> 1. respond as soon as at least 1 response from one of the 9p servers >>> is received, >>> 2. respond only after all responses had been received. >>> thanks!
------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M176ab7d3e0344d1d02e485e3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription