Charles,

On Mon, Jan 21, 2013 at 10:33 AM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
>
> 2013/1/11 Peter Soetens <peter [..] ...>
>>
>> Hi Charles,
>>
>> On Thu, Jan 10, 2013 at 8:31 AM, Charles Lesire-Cabaniols
>> <charles [dot] lesire [..] ...> 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.
>
>
> I am not sure to have fully understood your statements.
>
> What is not clear in
> http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-trans...
> in whether the first example (with TaskContexts) is using CORBA or not...
> looks like CORBA is not used in this case, so that a pure MQueue OOB
> connection is created!

Yes, it's a pure mqueue connection, but it's not out-of-band ! there
is only one band, and that is mqueue.

So pure mqueue looks like this:

outport -> endpoint ->mqueue write -> | -> mqueue read -> endpoint > inport

This is very similar to CORBA, ROS etc.

And the OOB looks like this:

outport -> endpoint -> corba chan -> mqueue write -> | -> mqueue read
-> corba chan -> endpoint -> inport

I'm abstracting the use of a buffer on either side here...

so in 'true' OOB, the corba channel element passes the data, signal
etc on to the mqueue channel element.

That's why the CORBA code in RemoteChannelElement.hpp first tries to
use the base class and if that
fails, uses the CORBA pathway. So 'corba chan' needs to be aware of
out-of-band situations.

>
> If I use a CORBA proxy, I will be in the Remote case, not in the OOB, right?

If you use a CORBA proxy and then select the ORO_MQUEUE_PROTOCOL_ID in
your ConnPolicy,
it will first setup a CORBA connection and then in there the mqueue elements.

>
> Do you have a test case and an example of a Remote (using CORBA) connection
> so that I could test the flexiport branch on it?

The unit tests cover these cases afaikt.

>
> I have just pushed the createStream parts, that work with MQueue on my side
> (in both output and input sides). So Remote and OOB are the only things to
> fix now.

I'll have to delay a review/test a bit, but I'm not forgetting about it :-)

Peter