Re: RTT Flexiport branch

Hi Charles,

On Thu, Jan 10, 2013 at 8:31 AM, Charles Lesire-Cabaniols <
[email protected]> wrote:

>
> Hi Peter (and others),
>
> I just came back into the flexiport branch.
>
> In ConnFactory::createConnection, you added the case where the input_port
> is not local, but I can't see why and when we could actually lead to this
> situation. My intuition is that when a port is not local, we should have
> called createStream instead of createConnection.
>

No... you could use createconnection on an output port of a regular TC and
an input port of a proxy TC and use the CORBA transport. The latter port
would then be in the case you describe above. It will be of type
'RemotePort', so isLocal() will return false. createStream is not
implemented by the CORBA transport, afaikt.


>
> Why did you consider this case? (the behavior in this case is not fully
> implemented, so I guess it is a specific flexiport use case)
> Is there a corner case I haven't seen?
>
> A complementary question about connections vs. streams: I think it would
> make sense to consider that creating an OutOfBand connection is just like
> creating two streams, respectively for the input and output parts, wouldn't
> it?
>

Yes, apart from the lifetime difference in both cases:

The 2 'streams' created by createStream are completely independent of each
other in terms of lifetime. Connections, outofband or not, are always a
single entity which are destructed/created in whole. A connection using an
outofband stream behind the scenes will also cleanup these 2 streams when
the connection is destroyed.

If you apply this to the mqueue transport, you can use CORBA to connect two
ports of different processes on the same machine using the outofband mqueue
transport and manage the mqueue lifetimes using the connection object. I'm
quite sure this is the specific use case why outofband exists.

Peter

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev