There has been a zmq_sendiov/recviov call for ages, undocumented and rarely used. This would indeed be a good alternative to multipart for the zerocopy use case.
On Mon, Feb 2, 2015 at 10:59 PM, Maurice Barnum <m...@yahoo-inc.com> wrote: > Is there any thought to adding a writev() analogue like zmq_msg_sendv()? > > One of the reasons I send send multiple frames is to avoid stitching together > buffers just to call send, which something like writev() would address that > use > without the complexity of the socket buffering the parts. > > On Monday, February 2, 2015 8:36 AM, Joe McIlvain <joe.eli....@gmail.com> > wrote: > > > > In my opinion, maintaining some kind of multi-frame abstraction at the API > level is in fact very useful to applications, even if they are sent > atomically on the implementation level as you describe. > > For example, in CZMQ It's quite useful in program flow to be able to push or > pop a single zframe onto or off of a zmsg, then send that zmsg as an entire > message. Rarely do I find myself using zframe_send or zframe_recv with the > "send more" and "receive more" flags in a CZMQ application. The CZMQ > "picture" messages are nice, but they are not always the easiest API to > integrate into an application. Having zmsg and zframe remain (or something > like them), while removing zframe_send and zframe_recv could ease > applications relying on multi-frame semantics into the transition. The > implementation for zmsg would simply serialize the frames in some > zmsg-determined way into a single-part zmq_msg to send and deserialize > according to the same scheme to receive. This multi-frame serialization > essentially be at the application level rather than at the ZMTP level. > > In short, I think a multi-frame abstraction is important for applications, > but if we remove the ability to send one frame at a time at the fundamental > level, this abstraction can remain at a higher level (whether in libzmq, or > in CZMQ and other wrappers) and coexist happily with the proposed changes. > > > > > On Mon, Feb 2, 2015 at 7:37 AM, Doron Somech <somdo...@gmail.com> wrote: > > So the new sockets are in the github master, you can take a loot at the test > to see how to use the new routing id field: >> >>https://github.com/zeromq/libzmq/blob/master/tests/test_client_server.cpp >> >> >>Few of the reasons I didn't like multi frames: >> >>* I tried in the past to make both zeromq and NetMQ thread safe, think of >>sending from multiple threads or receiving from multiple threads. we cannot >>do that with Multipart. >> >>* There are a lot of good transport that already implement message framing >>(UDP, WebSockets, SCTP and even HTTP), but because zeromq required it is own >>framing it was not easy to add them. >> >>* Multipart, router usage (routing id frame) and not being thread safe make >>the learning curve of zeromq hard to beginners. Without three of them zeromq >>become much simpler. >> >>* At least with NetMQ single part message is much faster than multipart. >> >>* New stacks, multipart is complicated to implement, with the new API it will >>much more easier to implement new stacks (like JSMQ) or any native stack. >> >> >> >>Pieter I'm looking forward to see how you expose the routing id in the czmq >>API. >>I also like the czmq API for sending mutlipart messages (the picture feature) >>so maybe we can use that to generate single frame which is also compatible >>with zproto. >> >> >>About the implementation, none of new sockets support any option now. server >>behave like mandatory router, so when router is not reachable or highwater >>mark is reached an error will be returned. >> >> >>As ZMTP 3.1 is still in raw status, what do you think of removing the >>multipart from it? maybe the 3.1 will only support the new socket types. >> >> >> >>Anyway I really excited about this change. >> >> >> >> >> >> >> >> >> >>On Mon, Feb 2, 2015 at 4:17 PM, Thomas Rodgers <rodg...@twrodgers.com> wrote: >> >>What we really want IMO is per-peer metadata, and an API to get/set >>>>this. Using messages is a hack. >>> >>> >>>Currently working on that :) >>> >>> >>>Having two layers that both >>>>carry per-message data is... wrong IMO. >>> >>>Protocols supporting 'out of band' data aren't exactly uncommon. >>> >>> >>> >>>However the key thing is, what's the problem. Then we can discuss >>>>solutions to that. >>> >>> >>>I don't have an immediate use-case justifying it. I noted it, mostly because >>>it has come up a few times since I started paying attention. >>> >>> >>>On Mon, Feb 2, 2015 at 7:55 AM, Pieter Hintjens <p...@imatix.com> wrote: >>> >>>> It seems to me that in order to remove multi-part messages and introduce >>>> new >>>>> socket types (e.g. SERVER/CLIENT) that would >>>>> necessitate a revision of the wire protocol. If we are going to do that, >>>>> it >>>>> might be worth considering per-message >>>>> metadata - >>>> >>>>We'd have to be very clear about the problem that per-message metadata >>>>is aiming for. There is an elegance to delivering blobs and nothing >>>>more. Metadata can be added on top using zproto. >>>> >>>>What we really want IMO is per-peer metadata, and an API to get/set >>>>this. Using messages is a hack. If we are sending/receiving data on a >>>>per-message basis, that is the message. Having two layers that both >>>>carry per-message data is... wrong IMO. >>>> >>>>However the key thing is, what's the problem. Then we can discuss >>>>solutions to that. >>>> >>>>-Pieter >>>> >>>>_______________________________________________ >>>>zeromq-dev mailing list >>>>zeromq-dev@lists.zeromq.org >>>>http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>> >>>_______________________________________________ >>>zeromq-dev mailing list >>>zeromq-dev@lists.zeromq.org >>>http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >> >>_______________________________________________ >>zeromq-dev mailing list >>zeromq-dev@lists.zeromq.org >>http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
