[email protected] said: > 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).
Um, POSIX recv operates on all sorts of things, including e.g. any kind of datagram socket (UDP, raw IP, etc.). > 1. you have to guess the size of frames you've not yet read. recv() returns the number of bytes it filled in the buffer, or 0 (EOF) or -1 (error in errno). What is there to guess? > 2. if you store the buffer, e.g. on a queue, you have to over-allocate > significantly. I would expect that an application is generally aware of the maximum size frame it is willing to receive. > 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? Nope, if you get an EMSGSIZE back then your recv() call was obviously a no-op. The question remains of how to get information about how much you should allocate out of the system... > 5. in the first case, how do you know how much to allocate? Do you > keep doubling the buffer size until it works? Fair point. Probably, unless there's some other way to get that information out of the system. But, I will reiterate that *most* applications, i.e. the simple users for who this API is intended, should damn well know what the maximum size frame they expect to receive is. > 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. N/A. > > 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. All good points, and they need some thought. Thanks for the feedback. -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
