On Wed, Mar 23, 2011 at 10:30 PM, gonzalo diethelm <[email protected]> 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);
> }
>
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.
>From my experience, in most projects we do use a pool of pre-allocated
buffers of fixed size. 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.
Another approach, in case the provided buffer is smaller than the message
size, could be that it would return partial data flagged with MSG_TRUNC.
Partial reads shouldn't be a problem since only one thread can read from a
ZMQ socket. But neither this is really POSIX compliant.
I personally find ZMQ API superior to the POSIX one and it's an unpleasant
experience when I have to use the latter (especially when working with SCTP,
which is quite often). It feels like going a couple of decades back in time.
Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
