[zeromq-dev] CurveZMQ thoughts

[Pieter Hintjens]

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