[zeromq-dev] Notes from a hackathon

[Trevor Bernard]

The single biggest problem I see people having in the JVM community is
their lack of understanding of the concurrency model. I haven't had
time to internalize the proposal just yet but if it helps people write
better/simpler software, I'm all for it.

-Trev

On Tue, Feb 3, 2015 at 4:33 PM, frank <soundart at gmx.net> wrote:
> 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
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>