Thanks for clarifying that.
At the moment, I'm using the directory for discovery so I can exchange keys
through there at the same time as I discover peer ensuring that this edge case
never happens. It's like hitting two birds with one stone :-)
André
> On Jan 19, 2015, at 10:23 AM, Pieter Hin
On Mon, Jan 19, 2015 at 2:41 PM, André Caron wrote:
> If a peer is rejected by curve authentication, does ZMQ automatic
> reconnection still work (and will it successfully connect once the "server"
> receives the public key)?
This is the part I'm not happy with. The client side used to retry.
Ho
Ah, indeed, I could use the doubled-up router-dealer part of the Harmony
pattern even with my current design. Makes sense.
> There's an edge case where a node tries to connect and is rejected as its
peer hasn't yet received a key.
If a peer is rejected by curve authentication, does ZMQ automatic
You should not be changing public keys IMO.
It is supported and documented and thus guaranteed, however I believe
it's a misfeature that solves no real problem and rather, opens the
door for confusion.
On Sun, Jan 18, 2015 at 8:05 PM, Andre Caron wrote:
> Yes, I understand the web of trust model
Yes, I understand the web of trust model. In my case, all (legitimate) nodes
are controlled by the same organization, so I can afford something akin to a
CA. My question stays, how could I adapt the Harmony pattern to use curve?
And, back to my original question: can I assume that zmq-connect(
On Sun, Jan 18, 2015 at 7:43 PM, André Caron wrote:
> ... the
> Harmony pattern doesn't provide for secure exchange of public keys.
It is identical to any pattern. Long term key exchange has to happen
out of band. Using router-router changes nothing here. Each peer has
its LT key, and each conne
It's a very difficult and deep question, if you're building a true P2P
network. If all peers are equal, nobody has some truth with regards to
the identity of another peer. Say you have the following protocol:
each peer starts announcing the identity of all known peers before
exchange data. One peer
I've looked at that already and still prefer the router-router setup and
have a convenient solution for discovery, which I'll get back to shortly.
Obviously my immediate curve problem would be solved when using the Harmony
pattern because you always create a new dealer socket for each outbound
con
I'd recommend reading about the Harmony pattern in the Guide.
Router-to-router topologies tend to be nasty. I don't use them, and
don't recommend them.
On Sun, Jan 18, 2015 at 5:57 PM, André Caron wrote:
> Hi all,
>
> I've been building an example of a router-router setup in which all nodes
> dyn
Hi all,
I've been building an example of a router-router setup in which all nodes
dynamically discover each other. This currently works like a charm. Now,
I'm trying to add curve support for this application, which is proving a
bit confusing despite the API's apparent simplicity.
Basically, all
10 matches
Mail list logo
