On Tue, Mar 22, 2011 at 8:26 AM, Martin Sustrik <[email protected]> wrote:
> I would mimic UDP. I am open to suggestions though. The recvmsg call is complex and not obviously a fit for 0MQ semantics, which are, IMO, either: * get next frame and return that * get next multipart message and return that In either case, reading into pre-allocated buffers is clumsy and I don't see how you can make it work since the caller cannot know the frame size ahead of time. The only suggestion I can make is to allocate frames on demand. If you try to fit the 0MQ recv into either UDP or TCP semantics, the result will IMO be weird and surprising in bad ways, so while you'll get a beautiful simple send(), no-one will use recv(), making this a useless exercise. People will end up doing insane things like writing their own frame headers so they can pre-allocate accurately. > Btw, note that 0mq socket type can't be changed from void* to int. I wanted > to do that myself but then I realised that the file descriptor table is part > of the context rather than global and thus you would have to pass both > context pointer and int: > > zmq_send (context, sock, "A", 1, 0); :-) Heh, it'll have to wait until (context == kernel). -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
