zsocket | Zero-copy sockets for Linux in Golang | Networking library

Better do not rely on static figures. Each JUMBO-message ( as depicted above ) has to be stored in several places, some of which are outside of the ZeroMQ domain of control ( typically the O/S & driver buffers ). Sure, ZeroMQ has done a great job on zero-copy, where possible, but injecting data onto network is typically an O/S job, so any free-space is "evaporating" pretty fast on Mammoth-sized data-blocks ( did I say, that ZeroMQ delivers either the whole, whatever sized data en-block, or nothing at all? ).

Next, there are Context-class instance settings ( High Water Marks and other ) that explicitly warn about not relying on having XYZ [B] free and available for message-data if having set that very value of XYZ [B] -- due to whatever internal buffer-management tricks, the API documentation and comments promote to expect anything under 2/3, if not 1/2 of that setting to remain actually available for any message-related data ( not mentioning, what would happen with buffer-space "consumption" if there would happen to be more than a single .connect()-ed counterparties

ZFrame implements IDisposable. As a general rule, you should Dispose of IDisposable objects when you are 'finished' with them.

It is particularly important with ZFrame since it contains a DispoIntPtr (pointer to unmanaged memory).

Without the Dispose call, it will not be freed in a timely manner. See https://github.com/zeromq/clrzmq4/blob/master/ZFrame.cs :

EINVAL
The requested option option_name is unknown, or the requested option_len or option_value is invalid, or the size of the buffer pointed to by option_value, as specified by option_len, is insufficient for storing the option value.

1. The ZeroMQ API defines the ZMQ_TCP_KEEPALIVE socket-configuration option to be of an int data type, not a string. Use the appropriate clrzmq4 binding interface function to request an int typed option_value and this first API incompliance will be solved.

Option value type int
Option value unit { -1 | 0 | 1 }
Default value -1 ( leave to OS default )
Applicable socket types all, when using TCP transports.

1. The ZeroMQ API defines this option to be valid if and only if the socket-instance was equipped with a tcp:// transport-class ( which the clients instance, as posted above, was not ). May defer the request to take place after the socket-instance has been instructed to associate a first tcp:// transport-class engine ( be it via a respective use of a .connect() or a .bind() ).

I'd post this as a comment, but don't have the rep:

Have you tried using NetMQ (https://github.com/zeromq/netmq)? I haven't used it on OSX (only Windows), but it's a native C# implementation of ZMQ that I've found to be pretty well designed, and in my opinion might be easier to get working than what you're using, which I assume is a C# wrapper around the C library.

Also, if you want help with the specific library that you're using, you should probably post what ways you've already tried to fix the exception, since you state there are "many ways to fix the exception, but there is no solution in Mac OSX".

On the receiving side, when you attempt to decode the marshaled Bond Compact Binary as an ASCII string, you're losing some of the payload. When marshaling a struct like Record to Compact Binary, the first four bytes of the payload are 0x43 0x42 0x10 0x00. When reading a string from a ZFrame, the first embedded NUL (0x00) that is encountered signals the end of the string, regardless of the size of the frame. So, the reading side sees only 0x43 0x42 0x10 instead of the whole payload (29 bytes when I tested).

Since Compact Binary is a binary protocol, you'll want to use the ZFrame constructor that takes a buffer on the publisher side: