[zeromq-dev] Notes from a hackathon

[Arnaud Kapp]

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.duclos at 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 <ph at imatix.com> wrote:
>>
>> On Tue, Feb 3, 2015 at 1:01 PM, Doron Somech <somdoron at 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 at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Kapp Arnaud - Xaqq