Hi rtt devs.
In order to connect my gui components to the remote ones, i use a connection policy with the pulled option, like this :
RTT::ConnPolicy::data(RTT::ConnPolicy::LOCK_FREE, true, true)
I set the pulled option because i thought that, whenever a data is written on a port, it would be send over the network only on a request from the remote end.
But when i scan the network traffic with, e.g., wireshark, i see a lot of traffic that seems to be generated by components with output ports... Perhaps only signals that a new data is available.
My questions are :
- is it possible to have asynchronous port transferts ? - where is the code involved in the writing of datas or signals on the network ?
Regards.
Paul.
Port connection over corba
Sorry.
My last post was a bit nervous :)
The code seems to be RemoteChannelElement::transfertSamples(). It seems that a signal is emitted for each new sample.
I try to comment the signal emission if it still works on the gui side :).
Port connection over corba
On Fri, Feb 3, 2012 at 6:20 PM, <paul [dot] chavent [..] ...> wrote:
> Sorry.
>
> My last post was a bit nervous :)
>
> The code seems to be RemoteChannelElement::transfertSamples(). It seems
> that
> a signal is emitted for each new sample.
>
Yes, and even for a pull, this signal is still sent, but not the data
itself.
>
> I try to comment the signal emission if it still works on the gui side :).
>
Indeed, It won't wake up any listening component, but a read will
effectively pull the new/latest data.
Maybe a simple thing we can add to RTT is to check if the input port of a
connection is an event port, and if not, don't call the signal function.
This would greatly improve such use cases as you have, where you want to
pull strictly.
The change is probably 'trivial' although it will require a slight addition
to the CORBA interface as well (to query the port type).
Sylvain, do you think this makes sense ?
Peter
Port connection over corba
On 02/04/2012 12:57 PM, Peter Soetens wrote:
> On Fri, Feb 3, 2012 at 6:20 PM, <paul [dot] chavent [..] ...
> <mailto:paul [dot] chavent [..] ...>> wrote:
>
> Sorry.
>
> My last post was a bit nervous :)
>
> The code seems to be RemoteChannelElement::transfertSamples(). It
> seems that
> a signal is emitted for each new sample.
>
>
> Yes, and even for a pull, this signal is still sent, but not the data
> itself.
>
>
> I try to comment the signal emission if it still works on the gui
> side :).
>
>
> Indeed, It won't wake up any listening component, but a read will
> effectively pull the new/latest data.
>
> Maybe a simple thing we can add to RTT is to check if the input port of
> a connection is an event port, and if not, don't call the signal
> function. This would greatly improve such use cases as you have, where
> you want to pull strictly.
>
> The change is probably 'trivial' although it will require a slight
> addition to the CORBA interface as well (to query the port type).
>
> Sylvain, do you think this makes sense ?
In principle, yes. However, we should make sure that the "type checking"
can be overriden by channel elements.
On the top of my head, a possible implementation would define
bool propagateNeedsSignalling()
method call on the channel elements, which is checked by the writer side
at connection time, and used to determine whether we should call
signal() or not.
As far as I remember, the elements that store values are the ones
calling signal(). I.e., the general call flow when pull and CORBA are
used is, schematically and without OOB transports:
Output channel.write()
OutputChannelElement next_channel.write()
DataElement next_channel.signal()
CORBASend next_channel.signal()
CORBAReceive next_channel.signal()
InputChannelElement port.signal()
The call flow at connection time would then be
Output channel.propagateNeedsSignalling()
OutputChannelElement next_channel.propagateNeedsSignalling()
DataElement next_channel.propagateNeedsSignalling() =>
stores return value, will call signal() only if
the returned value was true.
CORBASend next_channel.propagateNeedsSignalling()
CORBAReceive next_channel.propagateNeedsSignalling()
InputChannelElement return true if the newDataOnPortEvent has been
instanciated and false otherwise
Port connection over corba
I have submitted a patch that only add the propagateNeedsSignalling function.
I also provide a very simple (naive ?) test case.
http://bugs.orocos.org/show_bug.cgi?id=926
Could you comment it while i go ahead on the connection setup part please ?
Regards.
Paul.
Port connection over
On 02/06/2012 04:06 PM, paul [dot] chavent [..] ... wrote:
> I have submitted a patch that only add the propagateNeedsSignalling function.
>
> I also provide a very simple (naive ?) test case.
>
> http://bugs.orocos.org/show_bug.cgi?id=926
>
> Could you comment it while i go ahead on the connection setup part please ?
So far, looks good.
I would like to discuss the default return value if there is no next
channel element. The problem I have is that it will break transports
that (i) pass signalling (i.e. support pulling) and (ii) do not
reimplement the method. I'm wondering if returning true there would not
make more sense (i.e. make it more robust to these kind of errors). It
would have zero impact on the transports that do *not* support pulling,
as they don't see signalling anyways.
Re:
And what should we do when CORBA::is_nil(remote_side.in()) is true (exception, return false ...) ?
I still have a question about the RemoteChannelElement. Is there any method that is always called at connection time, where we could call propagateNeedsSignal for caching its return value ?
There is a last point to discuss : in addition to caching the return value of propagateNeedsSignal upon connection, I would like to update this value when signalInterface is called. Is it a good idea ? Is there other functions that can change this value ?
Regards.
Paul.
Port connection over corba
Le 02/04/2012 12:57 PM, Peter Soetens a écrit :
> Maybe a simple thing we can add to RTT is to check if the input port of a
> connection is an event port, and if not, don't call the signal function.
> This would greatly improve such use cases as you have, where you want to
> pull strictly.
>
> The change is probably 'trivial' although it will requirIt e a slight addition
> to the CORBA interface as well (to query the port type).
It would be a good option.
If no one have the time to make the change, i can work on it. Let me know who take the action !
Regards.
Paul.
Port connection over corba
Hi Paul,
On Sat, Feb 4, 2012 at 1:11 PM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
> Le 02/04/2012 12:57 PM, Peter Soetens a écrit :
>>
>> Maybe a simple thing we can add to RTT is to check if the input port of a
>> connection is an event port, and if not, don't call the signal function.
>> This would greatly improve such use cases as you have, where you want to
>> pull strictly.
>>
>> The change is probably 'trivial' although it will requirIt e a slight
>> addition
>>
>> to the CORBA interface as well (to query the port type).
>
>
> It would be a good option.
>
> If no one have the time to make the change, i can work on it. Let me know
> who take the action !
Honestly, I'm spending all my 'free' time trying to keep up with the
mailing list and apply patches for 2.5/2.6.
The fact is that 'add-ons'[*] are more valuable to the community right
now than fundamental changes to RTT, so I'm realizing that my support
to these people is most needed right now, or people will move along to
something else.
Peter
[*] rFSM, composites, deployment, itasc, dot service and alike
graphical representations
Port connection over corba
2012/2/4 Peter Soetens <peter [..] ...>
> Hi Paul,
>
> On Sat, Feb 4, 2012 at 1:11 PM, Paul Chavent <paul [dot] chavent [..] ...>
> wrote:
> > Le 02/04/2012 12:57 PM, Peter Soetens a écrit :
> >>
> >> Maybe a simple thing we can add to RTT is to check if the input port of
> a
> >> connection is an event port, and if not, don't call the signal function.
> >> This would greatly improve such use cases as you have, where you want to
> >> pull strictly.
> >>
> >> The change is probably 'trivial' although it will requirIt e a slight
> >> addition
> >>
> >> to the CORBA interface as well (to query the port type).
> >
> >
> > It would be a good option.
> >
> > If no one have the time to make the change, i can work on it. Let me know
> > who take the action !
>
> Honestly, I'm spending all my 'free' time trying to keep up with the
> mailing list and apply patches for 2.5/2.6.
>
> The fact is that 'add-ons'[*] are more valuable to the community right
> now than fundamental changes to RTT, so I'm realizing that my support
> to these people is most needed right now, or people will move along to
> something else
>
+1 !
> Peter
>
> [*] rFSM, composites, deployment, itasc, dot service and alike
> graphical representations
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>