Hello,
welcome to the list. :-)
Okay. Now I changed my rpc params to transferable types. I am using Rpc_in_buffer<> instead of std::string. I want to receive a feedback message from a server through an Rpc_in_buffer<> argument, but the client doesn't receive the results from the server correctly while working correclty with an character array.
I should not use Rpc_in_buffer for a reply message from a server?
That is right. 'Rpc_in_buffer' is specifically meant as an input parameter, hence the name. Let me give you a bit of the rationale behind this class template: The most basic way of passing strings as RPC function arguments is by using a compound object that contains a character array. For example:
struct File_name { char buffer[64]; };
This compound struct works for both directions as RPC argument or as RPC return value. However, this approach has two slight problems. First, it is a bit clumsy to use. It would be much nicer to pass a string directly to the RPC function at the client side. And second, the whole buffer is transferred regardless of the actual string length. Because 'buffer[64]' is just a bunch of bytes, this is the only sensible thing to do. Because most kernels support variable-sized messages, it would be nice to transfer only the elements of the buffer that carry any meaningful information to speed things up a bit. This is where 'Rpc_in_buffer' comes into play. It is a class template for the basic idea outlined above. Thanks to its implicit constructor that takes a null-terminated string as argument, it is quite convenient to use. And because 'Rpc_in_buffer' is specially handled in 'ipc_generic.h', only the actual payload is stuffed into the RPC message.
In the other direction (which you asked about) there is no such convenience function yet. This is simply because, until now, there was no need for it. In the framework, there is currently no single place (at least that I am aware of) where a string is returned. If we observe that this use case becomes frequent, we might add an 'Rpc_out_buffer' type. Until then, I suggest to use a compound type as mentioned above.
Regarding the general problem of communicating complex types from one process to another, Christian already mentioned the packet-stream facility. However, I would like to point out another approach that is somewhere in the middle: Using a dataspace shared between client and server as buffer for complex arguments combined with synchronous RPC for invoking the actual RPC function. You can find a brief explanation and pointers to code examples in the following posting:
http://sourceforge.net/mailarchive/forum.php?thread_name=op.v56pvpky50x9fi%4...
Best regards Norman