Update: so AMQ can support binary data if its content-length field in the
headers is used.
If I take the stomp client's string value and convert it to a buffer using
a "binary" encoding (rather than the default utf-8/ucs-2), then I seem to
be able to create the proper GPB object.
sample code
Yes, I agree, thank you very much for your input. The incoming data is
being treated as a string by the node AMQ stomp client library, and,
attempting to convert that string to a binary array is what is not working,
(thus the funky 65533 value). I either need to find a way for the AMQ
client
More info-- when the "header" is set with an index of >= 16, the encoding
process appears to insert an extra byte in the encoded value, and a decode
attempt will fail, here is an example where an index of 15 can allow for an
encode and subsequent decode, but an index of 16 fails at the
Gotcha, so the index value of 100 is not a non-standard value.
So I'm seeing "invalid wire type" when using the decode method of
protobuf.js of an AMQ body. This is in a Node using the protobuf.js,
stomp-client.js and an AMQ broker.
The GPB that I'm using has a basic format of this:
syntax =
100 isn't "non-standard" as such, and shouldn't cause anything to fail.
What exactly are you seeing?
The valid range is 1-536870911, omitting 19000-1 (and any reserved
areas in your specific messages) smaller numbers are cheaper (fewer bytes)
to encode, so are usually preferred - but: that's
