On Tue, Mar 22, 2011 at 10:40 PM, Martin Lucina <[email protected]> wrote:
> Pieter, you asked for a zmq_recv() example. It's analogous to POSIX recv(): > > char *buffer[1000]; > rc = zmq_recv (s, buffer, 1000, 0); > > with the obvious caveat that you will get something like EMSGSIZE back if > you gave a 1000 byte buffer, but the next-to-be-received message is too > large to be held in that buffer. I.e. no partial recv()s. Yes, this is obvious but as discussed on IRC (and in my email already), this looks like a broken semantic for length-specified frames (POSIX recv operates on streams). 1. you have to guess the size of frames you've not yet read. 2. if you store the buffer, e.g. on a queue, you have to over-allocate significantly. 3. if you want to store in a properly-sized buffer you have to allocate a new buffer and copy. 4. if you get an EMSGSIZE back, does 0MQ re-read the frame the next time, or read the remaining part of the frame? 5. in the first case, how do you know how much to allocate? Do you keep doubling the buffer size until it works? 6. in the second case, you get fragmentation, and have to start copying again, and it's confusing to treat an error return as valid semantics. These are the issues I can see without deep thought. I trust you see why forcing a length-specified frame recv into an API designed for streams is not the most brilliant idea. You might be able to hack it like vsnprintf, returning the *actual* frame size and allowing the caller to reallocate and try again. Ugly, though, and limits you to an int frame size. Making 0MQ look like an ancient stream API will bring you closer to TCP sockets but it will make an API that no-one will enjoy using. As long as the native API allocates properly, and can be wrapped in layers that make it less verbose but no less elegant, that's what people will use. The only way to force people to use such an API would be to kill the native API, and then people would end up doing their own length encoding so they'd be able to read frames sanely. Just my 5c. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
