Re: Filter design for nsmux

[olafBuddenhagen]

Hi,

On Sun, Feb 22, 2009 at 08:56:50PM +0200, Sergiu Ivanov wrote:
> On Wed, Feb 18, 2009 at 10:01 PM,  <olafBuddenhagen@gmx.net> wrote:

> > As I already pointed out, sooner or later we will problably need
> > some framework to conflate simimlar translator instances in a single
> > process -- while dynamic translators are likely to make the problem
> > evident in many cases, the problem itself is not specific to them...
> 
> Indeed, I have also thought about reusing a single translator instance
> for similar requests this week, and this does solve the
> number-of-processes issue.
> 
> However, I remember you pointing out that some of the translators may
> be incapable of dealing with multiple clients... Do we forget about
> such possibility or shall we think about this further?..

I said running multiple translator instances in one process, not sharing
one translator instance among clients... That's quite a different thing
:-)

Anyways, the purpose of my remark was to remind you that -- as I
explained before -- this is really an orthogonal issue, and we should
not consider it as part of the nsmux design.

> >> Could we possibly define a new RPC (a bit frightening for me,
> >> unfourtunately) to make the shadow nodes yield the real port? That
> >> is, when the client should invoke this RPC on the port it obtains
> >> from the filter, they should get the port directly, not involving
> >> shadow nodes?
> >
> > That is actually the solution I was considering. I don't really like
> > it, because this way nsmux is not transparent to the filter: the
> > filter needs to be aware that it is run by nsmux, and handle it
> > specially. I can't think of any other approach, though.
> >
> > (At least this way nsmux/the shadow nodes would be transparent again
> > once the filter is done.)
> 
> By saying ``transparency'' do you mean that at the invocation of this
> new special RPC, nsmux will give to the client a proxy of the
> translator port directly, without employing shadow nodes?

I mean that the filter invokes the special RPC to obtain a version of
the node without surplus shadows, returning this to the actual client.
Thus the procedure is not transparent to the filter -- it needs to know
that nsmux is involved and invoke the special RPC -- but it is
transparent to the actual client: it gets a "clean" node, devoid of
undesired shadows, just as if they never existed.

> > My major concern here is deciding whether to add the new RPC(s) to
> > the existing interfaces, or create a completely new one...
> 
> I'm not sure I can fully comprehend the implications of this
> statement... Could you please explain further?..

RPCs don't exist on their own: they are always part of some interface.
The RPC for getting the underlying node logically would belong to the
file interface (fs.defs) -- we would have to modify the existing
interface, and adapt all users. (AIUI this shouldn't actually be too
hard: just add a new stub server function to all the translator
libraries.)

The alternative is creating a new interface just for this special call.
We wouldn't need to touch existing interfaces; but it would be rather
unelegant...

> >> Still, I cannot really discern the solution to the problem: the
> >> most natural way to traverse a translator stack is bottom-to-top
> >> (since the standard RPC provide the technique). As we have said not
> >> a single time before, a top-to-bottom traversal cannot be
> >> implemented but with some additional facilities (like proxy nodes,
> >> as far as I can understand).
> >
> > There is really no difference here -- we need special facilities in
> > either case. When traversing bottom-to-top, we need a way to obtain
> > the completely untranslated node; when traversing top-to-bottom, we
> > need a way to obtain the underlying node, i.e. one translation layer
> > lower.
> 
> Yes, and this is what I'm talking about: there is no already existing
> RPC for going one translation layer lower.

My point is that traversing bottom-to-top isn't any more natural, as it
requires obtaining the untranslated node at the bottom of the stack, and
there is no existing RPC for that either.

> > You *could* duplicate the proxy data in the shadow nodes, so you
> > don't have to follow the reference from shadow node to proxy node in
> > some cases -- but what's the point? Save following one reference?...
> 
> Hm, really... I'm sorry, I thought we could merge the functionality in
> a single node because it seemed to me that another node would mean
> another context switch...

As in the current implementation the shadow node lives in the same
process as the proxy node to which it is attached, there is no context
switch involved...

That would be different of course if the shadow nodes were indeed
implemented by distinct translators.

In either case, it's much to early to think about this kind of
optimizations.

(Note that this would actually be a case of translator stacking
optimization -- i.e. a use case for the "mobility framework" Frederik is
working on. I'm not quite sure whether it's better to create special
solutions for various use cases first, and only later factor out a
generic stacking framework, or only work on such optimizations once the
generic stacking framework is in place...)

-antrik-

PS. Did you break the thread on purpose?...