[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Channel sessions

From: olafBuddenhagen
Subject: Re: Channel sessions
Date: Wed, 1 Aug 2007 12:32:26 +0200
User-agent: Mutt/1.5.16 (2007-06-11)


On Thu, Jul 26, 2007 at 09:24:32PM +0200, Carl Fredrik Hammar wrote:

> My solution is simple enough; they should all be implemented in
> channels (as opposed to being implemented in channelio.)  This will be
> more general and give the user more control.  The downside is that it
> will be a bit more unwieldy, almost every translator will introduce a
> chain of channels at a time, instead of just one.

What is the reason for this decision? My feeling is that I should be
able to individually express every single element of a channel stack
with a distinct translator...

Well, maybe I just didn't get your meaning right.

> Multiplexors are primarily used to gain multiple sessions to exclusive
> access devices and also balances io over sub-channels.  E.g. they
> multiplex in both directions.

Why do you want to merge these functionalities? They seem totally
independant -- I can't think of any situation where one would want to
use both together.

Maybe there *are* cases where you need multiple inputs and multiple
outputs in a single component, so it's probably reasonable to leave this
option open; but I don't think it should be used in any of the standard

Also, "multiplexer" is a bad choice of name, as this term is already
used for a specific kind of translators.

> I have identified two generally useful multiplexors.  The simpler one
> I will just call a `tee'.  It simply forwards each read and write to
> it's children, to whichever is most responsive or cyclicly if they are
> equally so.
> More interesting perhaps is a `broadcast' multiplexor, which forwards
> any input to all it's children and output to all clients in the order
> received.

I'm not sure I fully understand your descriptions; but it seems to me
that what you call "broadcast" is more or less what I was proposing as
"tee": It takes one input stream and creates several indentical outputs
from that -- just like the UNIX tool tee. What you call a "tee" on the
other hand seems to be a simple fifo.

Of course, if merging and splitting are distinct as I suggested above,
one actually gets four distinct base functionalities, with two variants
of each of tee and fifo: One multiplexing several devices for a single
client, and one multiplexing several clients on a single device...

This brings up another problem: The fact that for some kinds of
channels, input and output are rather independant, and may be handled

For networking, the situaiton is probabably rather clear. Doing load
balancing on several backend devices for example has a logical symmetry:
If output packets from the client are balanced among several devices,
input packets from the devices probably simply should be interleaved for
the client.

For audio however things get more complicated. One possible situation
could be mixing output of several clients, and copying input to several
clients. But other setups are also possible: One might want to mix
output, but enforce exclusive access for input; or the other way round.

A simpler case of asymmetry would be if one wants to apply one filter
for output and a different one for input. This can be easily achieved by
stacking one module that only handles the output and passes through the
input, and another module only handling the input. But the situation is
much trickier if you have to do multiplexing.

I can think of several approaches for that. One possibility is, if you
have a module that merges outputs for example, i.e. from all the client
outputs generates only a single output stream to the device, to simply
pass through all client inputs as distinct streams (channel instances).
You could then put another translator below that, which for example
duplicates all the inputs from a single device stream, and directly
passes through the output stream.

Another possibility would be making the input/output split explicit,
using a dedicated pair of modules for that: First you have a module that
splits each client session into an output stream and an input stream,
forwarded to different backends. The output and input backend then could
be implemented by totally distinct translator paths (sitting on
different FS nodes). Finally, the other dedicated module would merge
output and input stream again and forward them to a common device

(The input/output splitting and merging modules might be useful in other
situations as well...)

The above may be the most elegant and transparent solution, but could be
a bit cumbersome due to the many translators one needs to set
explicitely. Yet another variant could be using a single special
translator that internally splits output and input, and passes them to
two extra modules specified as command line parameters.

Seeing the complexity of all this, and considering that you have to
deliver working code in only a few more weeks, maybe you should just
leave these issues open for now, and concentrate on the basic
functionality. But that is something you need to discuss with Richard
I'd say...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]