Re: RTT-Introspection and how to do it ?

Am 30.03.2015 um 13:49 schrieb Sylvain Joyeux:
> Below is a summary of what I understand from your proposal:
>
>   - transports must provide unique IDs that allows to identify endpoints
>   - the connection graph can be rebuilt by querying remote and local
> IDs and pair them
>   - somehow we could use this mechanism to get some stats about the
> channel itself
>
> Overall, it does seem like a pretty sound starting point.
>
> Some key points in my view:
>   - the info-gathering process must be purely local
>     - since we have to query both sides of the connection anyways, it
> does not reduce the amount of information we can gather. It is
> therefore a performance gain, allows it to work uniformly over one-way
> communication channels like MQs or RTT-to-RTT ROS, makes the info
> gathering more robust as we don't need to hit the network and will
> allow to query half-broken connections
>     - obviously, only the side of the connection which contains the
> data element would report about its state
>     - it would mean making the IDs per-channel instead of per-endpoint
>   - the channel API is private, and should remain so. Any connection
> info API should go on the ports. I would propose creating a
> ConnectionInfo structure and a getConnectionInfo call on PortInterface
> which returns a vector of ConnectionInfo objects
I don't plan to add an API to RTT itself. To keep RTT changes minimal,
I aim at implement a Service, that adds an operation that does the
query. The Service is supposed to be loaded remotely. (See my mail
about that)
>   - this structure would contain
>     - the channel ID
>     - the channel policy
>         1. it's important information since it tells how the connection
> has been built (buffer size, transport ID, ...)
>         2. it is guaranteed to contain information about the remote
> part in the case of streams (e.g. ROS)
>     - an additional data structure to store channel statistics (out of
> the top of my head, number of samples received, number of samples
> read, number of samples lost, current fill)
That pretty much matches it.
     Janosch

-- 
  Dipl. Inf. Janosch Machowinski
  SAR- & Sicherheitsrobotik

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany
  
  Zentrale: +49 421 178 45-6611
  
  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Tel.:    +49 421 178 45-6614
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  [email protected]

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

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