Hi Steffen,
Steffen Liebergeld wrote:
Although I hate answering myself, I find find the answer and I am sharing it with you.
It turns out, that the badge that was submitted was invalid. I was able to circumvent this by adapting the Ipc_client::_call Method to set the badge to _dst.local_name(). This works for my scenario.
I don't know, what value you are using as 'local_name' (is this a unique object ID as used for most of the supported kernels?). Great that you found a solution for your current problem.
The way the 'Ipc_istream::badge' is handled depends very much on the underlying kernel. So its hard to give a general answer to your question. Generally speaking, the badge is used at the receiver side to identify the addressed server object. On kernels w/o capability support, each server object has a unique ID, known by both client and server. When invoking the server object, the client supplies the unique object ID as plain-data IPC payload. The server, in turn, uses the received ID as badge, which, in turn, is used to look up the local 'Server_object'. This is the scheme as you probably just noticed. On kernels with capability support, the badge could be implemented differently. For example, if the kernel's receive operation returns the invoked capability selector at the server side, this capability selector could be used as badge.
Cheers Norman