I happily use multipart rather a lot, to the point that I recommend that pyzmq users exclusively use send/recv_multipart, and never single-frame send/recv. I think it enables a really nice API. I find it very useful to be able to send a large buffer plus a header of message information without having to copy both blocks into a new buffer before handing off to zeromq. I find this particularly valuable in Python, where building that new buffer can be quite expensive.
In Python, and I suspect other higher level wrappers, where most messages are bytes or buffer objects (not wrapped in Message APIs), moving the routing information to message properties is not really an improvement, because I'm not aware of any pyzmq users accessing message properties, so the standard way to use pyzmq is to discard the `zmq_msg_t` object and only deal with bytes. But that's more of an API question for pyzmq than libzmq. As far as I can tell, I also use the multihop case that Pieter's blog post suggests "does not seem to happen in practice" every day, so maybe my use of zeromq is not typical. >From the "never break things" stance of libzmq and the discussion above, it seems that there's no plan for multipart to ever be removed. Deprecated even seems like too strong a word for a useful feature that will continue to be supported indefinitely. Or is anyone proposing the eventual removal of multipart? -MinRK On Tue, Feb 3, 2015 at 9:37 AM, Arnaud Kapp <kapp.a...@gmail.com> wrote: > Hello everyone, > > I have read this thread and the blog post from Pieter. > I am looking forward to some of those things, but I have some reserve > about other points. I'll try to explain what I think, and why. > > I agree that ZMQ_IDENTITY is a bit confusing. Allowing remote client > to set routing information is a bit counterintuitive. Also there is > risk for impersonation. If a peer disconnect, an other one could > "steal" it's identity. I believe that relying on the socket identity > to identify peer is not a robust enough approach, even when using > CURVE. > Storing the peer routing id in the message's properties seems like a good > idea. > > I think thread-safe socket would be cool. As in great to have in some > particular situation, but most of the case it shouldn't be needed. > > > Aiming for a cleaner and simpler ZMQ internal code is good. We must be > careful however that this will not make the end-user's life harder. I > believe I see 2 points that would make my life harder as a ZMQ user > today if we had what we is discussed here: > + The removal (or depreciation) of the REQ-REP socket. While > fragile over the network, I find them very useful for sending > synchronous messages between threads. > + Removal / depreciation of multipart messages. Read below. > > The next paragraph is about multipart messages. Let me be honest and > state that I have no idea of the real performance penalty induced by > multipart messages. What I want to defend here is their usefulness. > I *really* like multipart messages. To be honest, this is one of the > many features that made me try ZMQ. This is also the feature that > helps me most: I my current project, I mainly pass messages around > between thread, so I have less use for other awesome features like > auto reconnect or security. > > IMO framing is very good because it allows you to send (and receive) > various kind of data *easily*. I like doing this kind of stuff: > > zmqpp::message msg; > msg << "HELLO WORLD" << 42 << 13; > s.send(msg); > > And on the receiving end: > std::string cmd; > int value_1, value_2; > msg >> cmd >> value_1 >> value_2; > > Sure, there is no verification of the message content, the application > would even crash if a message was badly formatted. However, this is > not a concern when messages are flowing on inproc:// : I know that I > send and I know what to receive. I believe that the picture, which is > great in CZMQ, is not really appropriate for C++ and maybe other > language. My point is (for c++) that stream operator are a more > apprioriate / natural way of doing what the picture does. > > ZProto is mentioned as a possible replacement to framing. Disclaimer: > I've taken a look at zproto, but I have never used it. > I think it's a great project with some strong advantages and real > world use case. However, it comes at the cost of more complexity. This > is what I meant when talking about making the end-user's life harder. > Do I want to use zproto to design complex, client-server protocol? > Yes, I probably should give it a try. > Do I really want to use zproto when sending 3-4 frames on an inproc > socket? I'd rather avoid it and keep it as simple as possible. > > > 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. > I totally agree with Joe on this point. > > > One last thing about multithreaded socket. Maybe this is completely > stupid as I know little about libzmq's internal, but wouldn't it be > possible to make explicit thread safe socket by providing a > zmq_socket_lock()/unlock() function that would allow ZMQ internal to > serialize multiple frames properly ? > Sure, this is a not as classy as properly thread-safe socket, but > would work in most case: grab the socket from shared memory, lock it, > write/receive, unlock it. > > > > On Tue, Feb 3, 2015 at 3:52 PM, Luna Duclos > <luna.duc...@palmstonegames.com> wrote: > > I'm not sure if I like having picture as a libzmq level thing. > > It really only makes sense for C language bindings in my book. most other > > bindings use their own serialization mechanisms. > > > > On Tue, Feb 3, 2015 at 2:06 PM, Pieter Hintjens <p...@imatix.com> wrote: > >> > >> On Tue, Feb 3, 2015 at 1:01 PM, Doron Somech <somdo...@gmail.com> > wrote: > >> > >> > Pieter - regarding the blog post, I'm not sure about setting the > routing > >> > id > >> > on the socket > >> > >> Indeed, that isn't atomic with sending and so can't work with > >> threadsafe sockets. I've changed the article. > >> > >> I think we can either get the routing id as a message property, and/or > >> add a "reply to message" semantic that does this implicitly. The > >> second is easier for simple servers, the first is better for realistic > >> servers. > >> > >> Since it only applies to server sockets, I think we would benefit from > >> a zserver_reply () method (or similar). > >> > >> We might also think of moving the picture send/recv API into libzmq at > >> some point since it's the immediate replacement for framing. > >> > >> > I also have a question regarding the session management (really liked > >> > it), > >> > but how would know it is a socket level message and not a application > >> > level? > >> > Also do you think it should be enabled by default or only if an option > >> > is > >> > set? > >> > >> To make session management work we'd have to implement it using ZMTP > >> control commands, invisibly to the application. Same as heartbeating > >> at that level. > >> > >> -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 > > > > > > -- > Kapp Arnaud - Xaqq > _______________________________________________ > 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
