Support binary message

[mingfai]

NATS itself does support binary message
https://github.com/derekcollison/nats/blob/master/spec/binary_msg_spec.rb

[mheath]

Supporting binary messages is a bit harder in Java than Ruby. Ruby allows (and often expects) a string to hold binary data. In Java that's not the case. When converted from binary to a String, Java will validate the payload to make sure it conforms to a certain encoding. In the case of NATS it assumes UTF-8. At decoding time then, how do I know of the message payload is text or binary?

Have you verified if the Go NATS server supports binary messages?

Any support for binary messages is a low priority for me since my only use case for NATS is to support Cloud Foundry and Cloud Foundry doesn't use binary messages.

[mingfai]

I actually tried to play with the idea and it shouldn't be hard to implement. Instead of "a string to hold binary data", in Java, we just store stuff as bytes internally. It may be byte[](not preferred to avoid the copy) or ByteBuffer or ByteBuf (depends on Netty, not a good idea to expose in API) . In my experiment I just use ByteBuf and change the method signature to ByteBuf.
mingfai@21eb140

So it is the message user to decide the encoding and choose to call getBytes or getString(Charset) or getUtf8String().

No I didn't verify GNATSD. But as binary is more efficient than text, I don't see any reason they won't fix any bug.

Anyway, I view it as a future optimization option for now. I hope I'll get to the point that need such optimization. :-)

[mheath]

I like this suggestion. I'll look into holding the ByteBuf in the message and then lazily exposing it as a String or byte[]. I definitely don't want to expose Netty in the NATS client API.

I'll have some time in a week or so to start making some of these changes. Thanks for your feedback @mingfai!

[thjaeckle]

Hi there.
I am currently running in a situation where I want to transmit a byte[] and wrapping it into a String somehow screws the message up.

What about the commit of @mingfai ? Could it after all get into the codebase?

Regards Thomas

[mingfai]

if your app is not performance sensitive, and you don't want to wait or patch the lib yourself, consider to encode your byte[] to base64 string

[mheath]

I agree that being able to send/receive binary messages would be a very
useful feature to have. I think it would take some effort to get right both
from an API perspective as well as from a Netty ByteBuf efficiency
perspective.
Since Cloud Foundry doesn't use binary messages, it's hard for me to
justify investing the time to support this feature. Additionally, Cloud
Foundry is moving from NATS to more capable distributed state management
tools such as Consul. In spite of all the effort I've put into making this
client both fast and stable, I see this as a good thing. I have learned the
hard way that pushing the management of distributed state to every client
using a loose messaging system like NATS is really hard to get right.

NATS, of course, still has valid use cases. However, by the end of the
year, I don't expect to be maintaining this client any longer. If anyone is
interested in taking over this project and moving it out of the Cloud
Foundry community org, please let me know.

I would be really interested to see somebody build Java based NATS
server... mostly to definitively demonstrate that while gnatsd is faster
than Ruby natsd, gnatsd is still slow compared to Netty. :)

-Mike

On Tue, Apr 14, 2015 at 4:44 AM, Mingfai Ma notifications@github.com
wrote:

if your app is not performance sensitive, and you don't want to wait or
patch the lib yourself, consider to encode your byte[] to base64 string

—
Reply to this email directly or view it on GitHub
#28 (comment)
.