[zeromq-dev] CurveZMQ thoughts

[Laurent Alebarde]

Great Pieter, thanks a lot.

Yes,                    "I think of a hash table with the sender id as a 
key"
means exactly    "I think of a hash table with the client identity as a key"

Other ideas :

9) Separing curvezmq_codec_execute in two parts, one for the client and 
the other for the server would quite not take more lines of code, and 
would provide better clarity and maintainability IMO.

10) In my understanding, the respect of nonce sequences, for long nonces 
that use them, should be controlled by the peers. Let's say the client 
uses 1, 3, 5, etc. and the server 2, 4, 6, etc, the client should 
control that the nonce is 2 when it processes the welcome. In case of 
sequence rupture, the connection should be closed.


Le 26/08/2013 13:14, Pieter Hintjens a écrit :
> On Sun, Aug 25, 2013 at 8:50 PM, Laurent Alebarde <l.alebarde at free.fr> wrote:
>
>> 1) A czmq zmsg extension to curvezmq would be nice. I assume it would be
>> included in curvezmq.
> Yes, this was my plan; to provide a message based API that hides all
> the encoding / decoding. It'll come in the curvezmq project, this was
> why I split that off from CZMQ, to let it grow independently.
>
>> 2) It looks like the second s_encrypt in s_produce_initiate can use precom
>> since it is (c'->S'). Same on the server side, precom could be computed
>> earlier inside s_produce_welcome to be used as of s_process_initiate in the
>> second s_decrypt.
> Nice, thanks. Both those changes work.
>
>> 3) It is writen in the TODO lines : "don't assert, but raise error on
>> connection". In my understanding, the error may be returned (process
>> function prototypes changed from return value void to int), and used by
>> curvezmq_codec_execute to reset the state machine. On the server side, there
>> shall not exist exception from bad client messages.
> Yes... to be resolved in the message-based interface. I'll finish this
> later, I intend to build a demo secure chat application that does both
> client-to-server security and end-to-end security, so using both CURVE
> in the ZMTP layer, and CurveZMQ on top.
>
>> 4) It may be a good idea to test the possible NULL return value from the
>> s_produce_ functions.
> I've added the asserts in the selftest.
>
>> 5) verbose should be passed to server_task
> OK, done, this makes the selftest output better.
>
>> 6) In s_process_hello, the signature should be compared to the original one.
> Done.
>
>> 7) In s_process_ready, the client metadata are overwritten by server's ones.
>> Is it the expected behaviour ?
> Yes, the client metadata is sent and then thrown away. This seemed
> sufficient. The alternative was to maintain two metadata dictionaries;
> it makes a more complex API but without any benefit.
>
>> 8) In s_process_ready, no size check is performed ws the hard-coded limit
>> 1,000, what can lead to memory violation. Would it be preferable to malloc
>> the metadata ?
> It's a throw-away minimal design, I'll write a proper one based on
> zhash later on.
>
>> and a question :
>>
>> 1) What would be the best design to handle several clients starting an
>> handshake on the same server socket in the same time ? I think of a hash
>> table with the sender id as a key, and a struct {lifetime;
>> curvezmq_codec_t*} as its value. The lifetime would be reset each time a
>> valid message is received.
> Yes, this would be the design I'd use. (I assume you mean client
> identity). It's a classic pattern for any ROUTER-based server.
>
>> I hope it is usefull ;-) .
> Very useful, and thanks a lot for reviewing the code. I'm pushing patches now.
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130826/9f3f4731/attachment.htm>