[zeromq-dev] Notes from a hackathon

[frank]

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 <ph at imatix.com>:

> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1439 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150203/8e024ca6/attachment.bin>