Yes, we suspect the problem is in the transmit from .Net as well due
to the truncation at 1st NULL char in the Unicode string. I'm sending
the data back as a TIBCO message which also adds the field as a
string. Do you think if I use the AddField(string, byte) overload,
it'll work on the server?
On Apr 4, 6:04 am, Marc Gravell <marc.grav...@gmail.com> wrote:
> I've just been looking more - and ParseFromString should do the job.
> I /suspect/ the problem is the definition a "string"... you aren't
> going to be able to treat raw binary in .NET as a String; you are
> going to have to treat it as a Stream or a byte, or you can encode
> it to base-64 (as above) to get something that *can* be treated as a
> Either as binary or a base-64, you would then transfer that to the
> server. At the server, ProtoBuf again expects raw binary, but in a C++
> string (if you have used base-64 as a transfer mechanism, you would
> have to decode the base-64 back to binary). You should then be able to
> mount that data into a C++ string (or an istream).
> My best guess is that at the moment you are losing data during
> transfer (as above).
> What mechanism are you using to transfer the data? If it is a network
> socket (for example) you should be able to just send binary, without
> ever touching a .NET string; likewise HTTP can be used without
> creating a .NET string.
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at