[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: Mon, 20 Aug 2007 05:56:22 +0200
User-agent: Mutt/1.5.16 (2007-06-11)


On Tue, Aug 14, 2007 at 02:15:46PM +0200, Carl Fredrik Hammar wrote:
> <olafBuddenhagen@gmx.net> writes:
> > On Mon, Aug 13, 2007 at 03:08:27PM +0200, Carl Fredrik Hammar wrote:

> >> I will use channel for the object that a client interacts with,
> >> i.e. one is created whenever the translator is opened.
> >
> > That is what I call a channel instance. You can also call it a
> > channel session; but referring to an individual instance only as
> > "channel" would be very confusing IMHO.
> I have found the opposite very confusing or at least it has misguided
> me in the past.  The word channel suggest that their is a only single
> stream of data (in both directions) transferred between the two
> end-points.  Associating it with the translator, gives the idea that
> every client will receive the same data, i.e. opening a channel
> subscribes a client to the channel.  I was under the impression that
> this was the case for quite some time.
> But I think we both agree is not always the desired behavior.  Instead
> opening the translator should give the client a *new* communication
> channel to the end-point.

Well, we agree about the semantics; but I don't think that it should be
reflected in some obscure terminology.

Channel instances are pretty much of an internal detail IMHO. When a
user thinks of setting up a channel, he doesn't care about individual
client connections; it's the whole entity he thinks about.

Also, consider stores: The store is the whole entity, not some client
connection. The channel is the whole entity, not some individual
connection; why should it be anything else? Really, the static setup is
the most visible, most obvious part of the concept; it doesn't make any
sense to use the generic term "channel" for anything else.

I *strongly* object to any other use.

> > Well, I can't make much of OO terminology; I'm still not really sure
> > what you actually mean by a channel class... I hope you don't mind
> > if I don't use these terms :-)
> Lets take it from the top and see if it clears things up.

Sorry, I still don't understand what classes and types are supposed to
be exactly :-( What's worse, I don't know whether they are compatible
with my intuitive use of the terms. It seems to me that you are using
them in relation to a specific hub; while I'm rather thinking about
different kinds of channels (channel stacks), like audio channels or
network channels.

An audio channel for example has some additional facilities aside from
the generic channel stuff to control bitrates etc., and also requires
specific semantics when merging/splitting instances. So an audio channel
stack will most likely include some audio-specific hubs (perhaps in
addition to some generic ones). A network channel stack will use
network-specifc hubs. What term would you use to describe such stacks
(and hubs) for handling particular kinds of data?

> But you must acknowledge that stacks containing junctions can be
> mighty complicated to specify.

Of course. I don't consider that a problem, though. I'd say such stacks
are a rather special thing anyways.

> > I think there might be some cases, where some variant of fifo is
> > most appropriate; but I'm not at all convinced that it's the most
> > useful in the general case. In fact, my point was that there might
> > not be such a thing as a general case here... Useful behaviour is
> > just too type-specific I think.
> Hmmm... yes, I think it might be best to simply make junctions read or
> write only, and force the user to handle it appropriately.

Yes, I believe that if there are any generic junctions, they probably
should always be unidirectional. However, for specialized junctions
handling specific kinds of channels, e.g. an audio junction, I think
there might be some obvious combinations.

What I wonder about is whether it's even useful to have any other than
such specialized junctions...

> >> Yes, I am well aware of the differences.  The out-tee is much, much
> >> simpler.  Handling the case when some channels of an in-tee aren't
> >> so that other channels don't stall is tricky.
> >
> > I'm not sure there is any difference in this regard. I don't see why
> > backends should provide any more guarantees about not stalling than
> > frontends...
> The difference is in the difficulty in handling stalling, not whether
> they stall or not.  The problem is more that the client has control,
> the server can only wait for all clients initiates a transfer or
> time-out.  A client can simply specify a time-out when doing an RPC to
> handle stalling servers.

I see.

> For a general purpose fifo I would split and merge requests, e.g.
> merging two reads or splitting a write in two.  Of course this would
> break up packets.  One way to get around it might be to introduce
> packeting channels, that simply makes sure that each request is in
> whole packets, buffering if that is not the case.

Well, unless I'm missing something, I'd say you need that in any case
for things like network channels... I don't see how one could handle
network channels in any useful manner without awareness of packets.

> >> A modified version of three might work though, where the split and
> >> join is in a single module that maintains two separate stacks.
> >> Lets call this option four.
> For now I will go with option four, since it will work without adding
> functionality to libchannel.  But client IDs should be definitely be
> explored as an alternative.

Are you sure that doesn't require additional functionality? It seems to
me that handling such sub-modules actually requires quite a lot of
additional infrastructure; maybe even more than client IDs... (Aside
from the fact that it's not very elegant IMHO.)


reply via email to

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