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

Reply via email to