[zeromq-dev] Important: backward incompatible changes for 0MQ/3.0!

Martin Sustrik sustrik at 250bpm.com
Thu Mar 24 07:45:25 CET 2011


On 03/24/2011 12:03 AM, Martin Pales wrote:

>     A rather ugly but functional idea would be to return:
>
>     * number of bytes received on success;
>     * 0 on EOF;
>     * - number of bytes required for a successful receive.
>
>     This way you could do the following, if you really wanted to be on
>     the safe side:
>
>       char *buffer;
>       int size = 0;
>       // can allocate some memory the first time, or leave it at 0 bytes
>       int rc = zmq_recv(s, buffer, size, 0);
>       if (rc < 0) {
>         size = - rc;
>         buffer = malloc(size);
>         rc = zmq_recv(s, buffer, size, 0);
>       }

That's how UDP works. So far it looks like I am going to mimic that. 
Unless anybody has a better idea, of course. The only alternative system 
I am aware of, SCTP's partial delivery, is, IMO, more complex, with 
little added value for 0MQ

> It would be much more convenient if you just gave it a pointer and the
> buffer was allocated inside the zmq_recv() call since the library
> already knows the required size. But that wouldn't be a POSIX API AFAIK.

That's how it works now. Note that zmq_msg_t is basically something like 
this:

struct zmq_msg_t
{
     void *data;
     size_t size;
     deallocation_function_t *ffn;
};

This functionality is not going away. The functions will be renamed to 
zmq_sendmsg and zmq_recvmsg though, not to clash with simple 
POSIX-compliant send and recv.

>  From my experience, in most projects we do use a pool of pre-allocated
> buffers of fixed size.

Recycling of buffers happens in memory allocator. Let's not try to be 
smarter that mm experts. And in the case you are smarter, there's 
nothing preventing you to overload the standard allocators (see tcmalloc 
for example).

> As already said before, an application usually
> knows the maximum size of messages it handles. Larger messages can
> indicate either malicious clients or a bug.

Yup. There's a new option in trunk called ZMQ_MAXMSGSIZE which drops the 
connection in case of oversized message even *before* it is read to 
memory. It needs some polishing still though.

Martin



More information about the zeromq-dev mailing list