Hi, Please excuse for writing this on my phone....
I do not see any usecase nor detailed motivation what the problem is that
causes this somewhat fundamental proposal.
I think this approach is somewhat surprising and against the C4 thing. Not sure
if this is a problem or not, but there is a lesson there somehow.
Could you please (re-)publish the problem descriptions? Is the problem in czmq
, netmq, go-bindings or really in libzmq?
Apart from this 'style' related thing, i have a technical question:
When a router (API4.x)received a curve-encrypted message, i thought that the
identity field was the indented way to identify which of the many possible
clients send the message.
In fact I was thinking of signing the identity field using the client secret
key to have a robuster way of stopping clients which woul like to steal an
identity.
So with an 'int' as ID how is it possible to distinguish client1 from client2
cryptografically?
Or did I misunderstand how this should have been done in API4.x? And is this
possible with api5.x?
kind regards
Frank
--
unterwegs
Am 02.02.2015 um 10:23 schrieb Pieter Hintjens <[email protected]>:
> Hi folks,
>
> We had an interesting pre-FOSDEM hackathon on Thursday and Friday, in
> Brussels.
>
> One of the threads that came out, thanks mainly to Doron Somech
> (NetMQ) was a strategy for simplifying ZeroMQ. This started as a
> discussion of Nanomsg's dropping of multipart messages.
>
> Overall, multipart messages add a lot of complexity and confusion to
> the library and bindings. In case we forget:
>
> - frame vs, message vs. part
> - routing id frames
> - request-reply envelopes
> - router sockets
> - identities
>
> Multipart messages are the main reason we can't make threadsafe sockets.
>
> So, we're going to experiment with shifting ZeroMQ (libzmq, NetMQ,
> CZMQ, and other bindings) in this direction:
>
> - deprecate multipart messages from the API - when we need framing, we
> can use zproto
> - deprecate ROUTER and DEALER and slowly replace with SERVER / CLIENT
> sockets that refuse multipart data
> - deprecate REQ and REP
> - SERVER has get/set routing ID on message
> - routing ID is an integer
> - routing ID cannot be set by peer, so we deprecate ZMQ_IDENTITY
> - start to aim for threadsafe sockets
> - deprecate the ability to build request-reply chains
>
> ...
>
> This is not a roadmap, nor is this a proposal, it's just a realization
> by several of us that multipart messages create complexity, which we
> dislike, and which causes cost and irritation.
>
> Cheers
> Pieter
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
