[openrtm-users 03036] Re: multiple provider one consumer

[György Persa]

Hello Geoffrey,

​​Thank you for your answer,
Those port are CorbaPort-s, "X" marked are holding Consumer and "O" marked
are holding Provider of an interface, having one getter and one setter
function. The component on the right (PoC_VirCA) is supposed to provide
information for every other component by getters (it does), and utilize
setter functions of connected components, thus update their state. But only
if needed! We want to update only "subscribed" components, so want to
define which active connection should be used for updating.
But maybe my example was a little bit irrelevant in this context, sorry for
that! There is a lot of part in code, which can lead to this (now I guess
buggy) measurements.

I meant only ask, what is the expected behaviour in the case of multiple
provider one consumer. Is it suppose to call the remote function on every
provider?
Is it a way to choose which provider to use?
For instance, in SimpleService example project, can I call function on a
specific MyServiceProvider from MyServiceConsumer if there are multiple of
them?

Meanwhile, we have further experimental setups, which shows, that we can
address providers, but it's a bit complicated. We defined
ConnectionListener for the Consumer and when "on connected" call-back
function is called, we store a copy(!) of the Consumer in an std::map,
using the connection_id for key value. Later, we can use this map
(containing copies of the same Consumer) for calling functions on specified
connections.

Next week I'll try to do the same method in SimpleService example and share
the code. I hope that will be more clear!

Best regards,
György Persa


György Persa
*Software engineer*
Institute for Computer Science and Control
Hungarian Academy of Sciences
3D Internet-based Control and Communications Research Laboratory / 3DICC
*Project VirCA* (www.virca.hu)


On Thu, May 8, 2014 at 1:34 AM, Geoffrey Biggs <geoffrey.biggs ＠ aist.go.jp>wrote:

> Hi György,
>
> Could you give some more details about how your components are implemented
> and connected? Details such as what port types you are using to connect
> them, what the connector profiles are, and so on will make it easier to
> answer your question. If possible, could you provide your code?
>
> Geoff
>
>
>  On 7 May 2014 18:50, György Persa <persa ＠ sztaki.hu> wrote:
>
>>  Hello everyone,
>>
>> Recently I made an experimental setup in our system, and it seems to me,
>> that if I connect multiple provider to one consumer I can call function
>> only one of the providers/implementations.
>> In attached image I displayed the function call counts in console window.
>> In the relation of one provider to multiple consumer function was called
>> twice as much as in opposite direction. Thus I suggest, that when I connect
>> multiple provider to one consumer only one of the providers is taking
>> action.
>> My questions are:
>>
>>    - Is it really the case? If I connect multiple provider to one
>>    consumer only one of them will answer?
>>    - Is it possible to declare which provider's function should be
>>    called if a consumer has many of them (thus choose between
>>    implementations)?
>>    - Or can I access all the providers and call function on them somehow?
>>
>> Thanks in advance!
>> Best regards,
>> György Persa
>>
>>
>> György Persa
>> *Software engineer*
>> Institute for Computer Science and Control
>> Hungarian Academy of Sciences
>> 3D Internet-based Control and Communications Research Laboratory / 3DICC
>> *Project VirCA* (www.virca.hu)
>>
>>
>> _______________________________________________
>> openrtm-users mailing list
>> openrtm-users ＠ openrtm.org
>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>
>>
>
> _______________________________________________
> openrtm-users mailing list
> openrtm-users ＠ openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users
>
>
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://www.openrtm.org/pipermail/openrtm-users/attachments/20140509/0e487eb5/attachment.html>