Re: RTT-Introspection and how to do it ?

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
 - 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)
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev