Hi,
I'm writing a new measurement system interface library and was
wondering if anyone here has some ideas about best-way to implement
it.
The measurement system acts as the master and creates 2 or more TCP/IP sockets:
- One control socket, on which the measurement system sends status
information and the client (me) can send command to it (start/stop
etc) upon which the system sends a confirmation
- One or more data sockets, on which, after starting the measurement,
the next data sample is streamed as soon as it is available.
Now I checked an OROCOS component available for one of our robots in
which they handle a single socket. That component just reads out the
socket in the updateHook() and triggers itself at the end.
Looks like a good way, but is something like this possible to control
more than one socket in a single component? If yes, how would that
then go?
I don't care if the control socket information is a bit late, but do
need the data sockets to be read out as fast as possible.
regards,
Steven
Multiple TCP/IP socket handling
On 01/25/2011 09:43 PM, Steven Bellens wrote:
> Hi,
>
> I'm writing a new measurement system interface library and was
> wondering if anyone here has some ideas about best-way to implement
> it.
>
> The measurement system acts as the master and creates 2 or more TCP/IP sockets:
> - One control socket, on which the measurement system sends status
> information and the client (me) can send command to it (start/stop
> etc) upon which the system sends a confirmation
> - One or more data sockets, on which, after starting the measurement,
> the next data sample is streamed as soon as it is available.
> Now I checked an OROCOS component available for one of our robots in
> which they handle a single socket. That component just reads out the
> socket in the updateHook() and triggers itself at the end.
> Looks like a good way, but is something like this possible to control
> more than one socket in a single component? If yes, how would that
> then go?
> I don't care if the control socket information is a bit late, but do
> need the data sockets to be read out as fast as possible.
In RTT2, there is the RTT::extras::FileDescriptorActivity that allows
you to listen to an arbitrary number of file descriptors (in your case,
sockets) and be triggered whenever there is data on them, timeout has
occured and/or there is an error on the FDs.
The oroGen documentation contains information on how to use it at the
C++ level (see http://rock-robotics.org/orogen/triggering/fd.html)
That's how I would do it ...
Multiple TCP/IP socket handling
2011/1/26 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 01/25/2011 09:43 PM, Steven Bellens wrote:
>> Hi,
>>
>> I'm writing a new measurement system interface library and was
>> wondering if anyone here has some ideas about best-way to implement
>> it.
>>
>> The measurement system acts as the master and creates 2 or more TCP/IP sockets:
>> - One control socket, on which the measurement system sends status
>> information and the client (me) can send command to it (start/stop
>> etc) upon which the system sends a confirmation
>> - One or more data sockets, on which, after starting the measurement,
>> the next data sample is streamed as soon as it is available.
>> Now I checked an OROCOS component available for one of our robots in
>> which they handle a single socket. That component just reads out the
>> socket in the updateHook() and triggers itself at the end.
>> Looks like a good way, but is something like this possible to control
>> more than one socket in a single component? If yes, how would that
>> then go?
>> I don't care if the control socket information is a bit late, but do
>> need the data sockets to be read out as fast as possible.
> In RTT2, there is the RTT::extras::FileDescriptorActivity that allows
> you to listen to an arbitrary number of file descriptors (in your case,
> sockets) and be triggered whenever there is data on them, timeout has
> occured and/or there is an error on the FDs.
>
> The oroGen documentation contains information on how to use it at the
> C++ level (see http://rock-robotics.org/orogen/triggering/fd.html)
>
> That's how I would do it ...
Look like what I need, thanks!
Can I use multiple FileDescriptorActivity pointers in one component,
so as to set different timeouts for certain sockets?
Steven
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
Multiple TCP/IP socket handling
On 01/26/2011 10:00 AM, Steven Bellens wrote:
>> In RTT2, there is the RTT::extras::FileDescriptorActivity that allows
>> you to listen to an arbitrary number of file descriptors (in your case,
>> sockets) and be triggered whenever there is data on them, timeout has
>> occured and/or there is an error on the FDs.
>>
>> The oroGen documentation contains information on how to use it at the
>> C++ level (see http://rock-robotics.org/orogen/triggering/fd.html)
>>
>> That's how I would do it ...
>
> Look like what I need, thanks!
> Can I use multiple FileDescriptorActivity pointers in one component,
> so as to set different timeouts for certain sockets?
"Using different FDAs" makes no sense. The FDA, in essence, blocks until
there is data on any file descriptor. You can't really "block with
various timeouts" -- you will always have to wake up to your smallest
timeout.
One thing that the FDA could you for you is keep track what data was
available on which FD and automatically adjust the select() timeout
based on the specified per-fd timeout. But it does not do that -- feel
free to add it though ;-)
So, in principle, you will have to pass the smallest timeout to FDA and
handle the various FD timeouts in your updateHook().
Multiple TCP/IP socket handling
2011/1/26 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 01/26/2011 10:00 AM, Steven Bellens wrote:
>>> In RTT2, there is the RTT::extras::FileDescriptorActivity that allows
>>> you to listen to an arbitrary number of file descriptors (in your case,
>>> sockets) and be triggered whenever there is data on them, timeout has
>>> occured and/or there is an error on the FDs.
>>>
>>> The oroGen documentation contains information on how to use it at the
>>> C++ level (see http://rock-robotics.org/orogen/triggering/fd.html)
Can you give me an example on how to set a components activity as a
FileDescriptorActivity?
Before I used a deploy script with
"setActivity("Krypton",0.01,HighestPriority,ORO_SCHED_RT)" to make it periodic
I removed that line and added in the configureHook:
act = new RTT::extras::FileDescriptorActivity(0);
this->setActivity(act);
But now my updateHook never get's called. I do get errors due to
socket timeouts from the FileDescriptorActivity:
6.745 [ ERROR ][Logger] FileDescriptorActivity: timeout in select()
Steven
>>>
>>> That's how I would do it ...
>>
>> Look like what I need, thanks!
>> Can I use multiple FileDescriptorActivity pointers in one component,
>> so as to set different timeouts for certain sockets?
> "Using different FDAs" makes no sense. The FDA, in essence, blocks until
> there is data on any file descriptor. You can't really "block with
> various timeouts" -- you will always have to wake up to your smallest
> timeout.
>
> One thing that the FDA could you for you is keep track what data was
> available on which FD and automatically adjust the select() timeout
> based on the specified per-fd timeout. But it does not do that -- feel
> free to add it though ;-)
>
> So, in principle, you will have to pass the smallest timeout to FDA and
> handle the various FD timeouts in your updateHook().
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
Multiple TCP/IP socket handling
On 01/26/2011 11:54 AM, Steven Bellens wrote:
> I removed that line and added in the configureHook:
> act = new RTT::extras::FileDescriptorActivity(0);
> this->setActivity(act);
I don't know anything about changing activities in the configureHook, sorry
The normal workflow for me is:
* create the task and the activity, set the activity on the task
* call start(). The task's configureHook() calls watch() as described
in the orogen documentation
* here I am
If there is a timeout, updateHook() should be called anyway as it is not
a fatal error from the FDA's point of view.
Obviously, as with all task contexts, you have to call start() to get
updateHook() called, right ?
Multiple TCP/IP socket handling
2011/1/26 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> On 01/26/2011 11:54 AM, Steven Bellens wrote:
>> I removed that line and added in the configureHook:
>> act = new RTT::extras::FileDescriptorActivity(0);
>> this->setActivity(act);
> I don't know anything about changing activities in the configureHook, sorry
>
> The normal workflow for me is:
> * create the task and the activity, set the activity on the task
> * call start(). The task's configureHook() calls watch() as described
> in the orogen documentation
> * here I am
>
> If there is a timeout, updateHook() should be called anyway as it is not
> a fatal error from the FDA's point of view.
>
> Obviously, as with all task contexts, you have to call start() to get
> updateHook() called, right ?
I'm starting my component in the TaskBrowser at run time.
I converted the component to an executable implementing ORO_main in
which I make the FileDescriptorActivity and assign it to the task.
Same behaviour however occurs as described earlier: startHook()
executes - valid activity pointer watches my socket descriptor, but
updateHook never gets executed - FileDescriptor Timeouts occurs.
Do you have a working example with 2.x available?
Steven
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
Multiple TCP/IP socket handling
2011/1/26 Steven Bellens <steven [dot] bellens [..] ...>:
> 2011/1/26 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>> On 01/26/2011 11:54 AM, Steven Bellens wrote:
>>> I removed that line and added in the configureHook:
>>> act = new RTT::extras::FileDescriptorActivity(0);
>>> this->setActivity(act);
>> I don't know anything about changing activities in the configureHook, sorry
>>
>> The normal workflow for me is:
>> * create the task and the activity, set the activity on the task
>> * call start(). The task's configureHook() calls watch() as described
>> in the orogen documentation
>> * here I am
>>
>> If there is a timeout, updateHook() should be called anyway as it is not
>> a fatal error from the FDA's point of view.
>>
>> Obviously, as with all task contexts, you have to call start() to get
>> updateHook() called, right ?
>
> I'm starting my component in the TaskBrowser at run time.
> I converted the component to an executable implementing ORO_main in
> which I make the FileDescriptorActivity and assign it to the task.
> Same behaviour however occurs as described earlier: startHook()
> executes - valid activity pointer watches my socket descriptor, but
> updateHook never gets executed - FileDescriptor Timeouts occurs.
>
> Do you have a working example with 2.x available?
2 patches in appendix.
- the FileDescriptorActivity should use the runner pointer which is
available in the Activity class instead of its own
- removing compile warning by removing unused var w
UpdateHook now get's called correctly - socket checks seem to be
working at first sight.
Thanks to Ruben for looking into this!
Steven
>
> Steven
>
>> --
>> Sylvain Joyeux (Dr.Ing.)
>> Space & Security Robotics
>>
>> !!! Achtung, neue Telefonnummer!!!
>>
>> Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 178-454136
>> Fax: +49 (0)421 218-454150
>> E-Mail: robotik [..] ...
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> -----------------------------------------------------------------------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>> (Vorsitzender) Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> USt-Id.Nr.: DE 148646973
>> Steuernummer: 19/673/0060/3
>> -----------------------------------------------------------------------
>>
>