Data flow in Corba

On Monday 14 March 2011 16:27:00 Davide Faconti wrote:
> Hi Oro-Developers,
>
> I have a question that may be you can answer about DataFlow and ports.
>
> Let's assume we have a provider (output port) that writes at 10.000 Hz.
> On the other side there is a subscriber (input port) that read only 10
> times per second.
> The two components are deployed using CORBA since they are two different
> processes.
> My question is: how many times per seconds there will be a CORBA
> communication? I believe the answer is 10.000 times, am I right?

That depends. For each connection between any two ports, you specify a
connection policy. One flag of the policy is the 'pull' flag (see [1]). If you
set this to 10, the message will only be read 10 times a second.

There is however another problem even if 'pull' is set. That's that we
'signal' the receiver that new data is available (consider this as a single
tcp/ip packet), such that it can wakeup to 'pull' if such a signal is
received. If the data to be transfered fits in a single tcp/ip packet, the pull
is actually not a win in network bandwidth.

We could solve the latter by detecting that the receiving end is not an
EventPort and does not need the signal functionality, as such, the pull flag
would have it's maximal efficiency. I think this is only a minor addition to the
existing code base.

> If I am, this seems to me a potential overhead (it is NOT a criticism, I
> understand the answer to the problem isn't trivial).
> Has anyone consider such use case and figured out a solution?

If both are living on the same host, we prefer the mqueue transport (posix
message queues), which has lower overhead. It however does not have this
'pull' property, so every sample is sent.

AFAIKT, we configure our transports to drop the oldest sample, (Sylvain
proposed this as standard policy iirc). Such that the 10Hz receiver has the
newest data.

Peter

[1]
http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v2.x/api/ht...