Hi David,
thanks for the detailed answer. I considered your hint regarding the trustworthiness of the clients: now the parent is providing the service to its children.works like a charm! the slave approach also worked, but i think the reversed way is more elegant. i should have thought of that earlier ;)
great that you found this consideration worthwhile. :-)
in the next step, the parent shall process the calls from its client. thus, its necessary that the parent knows the label of the child which issued the call. The child sets its label in Child_policy::filter_session_args(...). my question is: how does the parent obtain these session arguments ?
The child creates the connection to your service by invoking the 'Parent::session' RPC call. The parent-side 'Child' object handles this request by calling 'Child_policy::resolve_session_request' with the session arguments as parameter. The label is just a part of the session arguments. By overriding this virtual function, you can monitor the arguments including the label.
Btw, the 'Child_policy::filter_session_args' function is not called by the child process but by the 'Child' object in the parent process. The terminology is a bit confusing: The 'Child' class represents the child inside the parent process.
However, addressing your actual problem, I recommend to not distinguish the children based on the labels supplied by themselves. A misbehaving child could forge the label and thereby trick the parent to do wrong things. The natural way to tell the origins of different requests apart is to hand out different sessions to each child. So when a child asks for session, hand out the child-specific session. E.g., you could host the respective 'Session_component' object as member of your child/policy class. So later, when a request comes in, it is dispatched in the context of the right session (that is associated with one particular child).
maybe there is another ( better? ) way to obtain the childs name?
Actually, child processes don't know their own names. Sticking a name to a child (or not) is entirely up to the parent. In the case of the init process, the assigned name is used to prefix the "label" session argument of each session originating from the child with the child's name. But that is just an option. You don't have to do that.
Cheers Norman