Le 11/03/2014 23:45, Alex Elsayed a écrit :
CurveCP will not work here. First of all, it's not 0-RTT. If you require a REQ/REP for key exchange before the data, your system is broken due to endpoint load-balancing.
Indeed
For me, what is lacking in the nanomsg API is the identity of the peer, as the one in libzmq ROUTER. That would solve this problem. I have prototyped libzmq mechanisms (CURVE) proxying successfully but I have no hair left ! Such identity is mandatory to have sticky clients and workers associations. With security, the server end-point (worker) shall remain the same for one client until the end of the communication, and possibly over several sessions.You need to bundle key data with your outgoing REQ, or at least sufficient identifiers for it to be looked up out-of-band (say, via the management interface). REP must do the same. The result looks more like OpenPGP than CurveCP - in fact, OpenPGP would work without any changes. Pity about the message inflation.
But I think I will solve the unavailability of the identity by a field function of the client MAC address.
