3 solutions

Solution 2

You can pass your structure just as buffer, exactly like you pass the strings. But it is not very ok, because binary representation of structure may be different on server and client. IStream is COM interface, so it is available at COM level which is higher than RPC level. Anyway, IStream is for serialization, but you need marshalling.

That you have to know, is that some user defined structure used in RPC, should be defined at RPC level. So, you have to marshalize it. It means, you make it RPC. After passing the structure between client and server, it should be unmarshalized and used. This means, clients and servers will have always the same structure, but binary compatible with own platform. This can be done manually, or can be used some RPC compiller, which will convert function calls to RPC calls, and all the RPC marshalling routines will be hidden in proxy stub files. You will describe your structure in the RPC language, so it should exist at RPC level. In your language you will deal with mappings from RPC level to your language.
If you use Microsoft RPC, you would likely to use IDL (MIDL) do define your own structures at RPC level. And use MIDL to compile them. All the marshalling/unmarshalling routines you will have in the generated proxy and stub files.http://msdn.microsoft.com/en-us/library/windows/desktop/aa367080(v=vs.85).aspx[^]

It is about IStream pointer, not about the Stream managed by IStream. This means marshalling pIstream to pIstream. This means after you unmarshall the pIStream you will be able to access the stream. But the stream itself remains the same unstructured buffer, on both, client and server. And marshaller knows nothing about how should be used an unstructured buffer.

It is unstructured, and it deppends on the implementation. Object serializes itself in an RPC unaware way. in/out has no warranty on correctness of transfer. For instance consider in/out on whole structure memory buffer at once.
Seralizing and marshalling make very different things, this is why they exists separated to each other.

Look at your link above again, and just think, that you have to implement in, out, reimplement again when changing the structure, and so on, чзж. Moreover you have to do it via one more layer, the COM. Much easier is pass marshalled memory buffer directly to RPC, as the IStream will solve exactly nothing in this case. IStream interface exists for COM objects and formats. While there is no COM, there is absolutely no reason to use IStream.
If user wants to pass a structure via RPC, the answer is to make it RPC. Any changes of the structure just recompile the RPC definition and recompile the program.

No. Not only sizeoff. If you need just within same HDD exchange, then you don't need RPC at all. Anyway, doing RPC you have to think RPC.
Consider a point
struct point{int x; int y;};
Consider two systems, big endiang(BE) and little endian(LE). Structure will have different binary representation.
The method void setPoint(const point) pass an rpcpoint, but each program two systems will have just point, with different binary representation.
Suppose you want to add one more dimension to your point, make it relativistic, and add the double time.
struct point{int x; int y;double time;};
Compiller generates marshalling for bigger point, with three attributes, the proxy code marshalls now the x, the y, and the z, and the stub code does the unmarshall for the same thing. So, server program pass a point to RPC and RPC does something. After that RPC does some other thing and pass it to client as a point.
All the code generated by RPC compiller is the RPC level, so you don't really have to carry about it.

You should define your structure at RPC level. This means to define it in RPC language, such as some kind of IDL, or other one, depending on your platform. After that you have to compile this one with provided compilers. These compillers will make C++ code, which you will use. If you use Windows RPC, then you will write your procedures in IDL and will compile with MIDL. Anyway, provide some more info about your system, compiler, kind of RPC, snippets of code.