On 03/22/2011 10:06 AM, Pieter Hintjens 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.
There are basically 2 options: 1. Mimic UDP, ie. recv into undersized buffer truncates the message, however, there's MSG_PEEK flag, which allows you not to consume the message. That allows you to check the size of the message in advance, allocate the buffer and read it afterwards. 2. Mimic SCTP's partial delivery. Read data into buffer, check whether EOR was reached. If not read more data etc. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
