Re: Alternative Transports / Master Server

Sylvain Joyeux <[email protected]> Tue, 11 Nov 2014 12:47:57 -0200
Newsgroups gmane.science.robotics.orocos.devel
Message-ID <CAFENT7LTMsnxAZtSz+53zBbFnk1GZsc_2+rdR4a9wrL8UUW1fw@mail.gmail.com>
2014-11-11 12:13 GMT-02:00 Janosch Machowinski <[email protected]>:
> Hey,
> we are currently looking into adding new transport layers to orocos.
> We haven't choosen the concrete implementation or candidate yet,
> the candidates so far are :
>   - LTP/BT (licklider transmission protocol / Bundle protocol)
>   - ICE
>   - DDS
>   - zeroMq
>
> Noe we stumbled over the issue with the "Master Server"
> for now, there is the implicit master server, being the
> corba nameserver.
Can you explain what you mean by that ? There is no "master" server in
RTT the way there is one in e.g. ROS. The only server that exists is a
name server, which is a very narrowed down definition of "master".

The corba client class currently registers tasks on the corba name
server (which made sense given that CORBA was the only name service),
but there's nothing in RTT that mandates it (not even in the CORBA
transport).

It is the job of the deployment tool (either the OCL deployer or
orogen-generated deployments) to register the task wherever they feel
like. I.e. it is a tooling concern (whichever toolchain you use is
really what mandates the task to be registered somewhere specific),
definitely not a transport concern.

In other words, the need for a name server arises on the tooling side,
and the Rock tooling can for instance deal with having many name
servers just fine.

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