Hi John,
One cool thing about Curve25519 is that, given the secret key, the public key
can be derived from it. And it seems that you actually you can use random bytes
for the secret key (almost). Only a few bits in the first and last byte are
fixed. Here an excerpt from [1]:
> Computing
What do would be an appropriate pattern to achieve bidirectional,
asynchronous messages between two nodes over TCP transport without binding
more than one TCP port? The two nodes would be in different processes at
least and possibly on different machines. I can imagine that a pair of
PUSH->PULL
On Wed, 2018-02-14 at 00:17 -0500, John Lane Schultz wrote:
> Hi Luca,
>
> Thanks for the update. I was holding out hope that someone might
> have taken a crack at it already.
>
> Yes, TLS is a pretty complicated protocol that supports tons of
> different cipher suites and options. I certainly
You would most likely use a ZMQ_ROUTER socket on both ends:
Summary of ZMQ_ROUTER characteristics:
Compatible peer sockets ZMQ_DEALER, ZMQ_REQ, ZMQ_ROUTER
Direction Bidirectional
On Wed, Feb 14, 2018 at 9:08 AM, Jake wrote:
> What do would be an appropriate pattern to
Hi
Not sure why Justin suggested using a ROUTER-Socket on each side.
I think having the A node bind a ROUTER socket and each B node connect using a
DEALER socket is enough. One single TCP port would have to be bound. The ROUTER
socket on the A node is needed to distinguish between the
Hi Jake
In fact, most ZMQ socket types do some sort of load balancing when
connected with multiple other sockets. See [1], especially the "Outgoing
routing strategy" and "Incoming routing strategy" in the table for each
socket type. TL;DR if the socket allows receiving messages and is
On Wed, Feb 14, 2018 at 12:28 PM, Patrik VV. wrote:
> Hi
>
> Not sure why Justin suggested using a ROUTER-Socket on each side.
Ah yes, I misread the original message. For "one-to-many" you would
use router-dealer. router+router would be more for many-to-many where
each node
That’s very cool that (almost) any random number can be used for the private
key and the public key can be easily derived from the private one!
See? I am quite clueless about the details of ECC. ;)
John
On Feb 14, 2018, at 4:05 AM, paddor wrote:
Hi John,
One cool thing
Isn't ROUTER-DEALER load balancing though? I've used it in a
REQ-ROUTER-DEALER-REP set up
but in that case the REQ -> ROUTER send does not target a particular
handler on the other side, it
just goes to an arbitrary one and the ROUTER makes sure the reply goes back
to the original sender.
How
Ok, thanks for the explanation and doc reference. My A node spawns the B
nodes in the
first place, so I guess I can either (1) assign the identity out-of-band at
spawn time and
have the B use it, or (2) have B handshake once at start up to allow A to
associate the
zmq-assigned identity. After
Ah right, I guess there will be a ZMQ-assigned identity if you don't set
one. Wasn't able to find that in the docs right away though. I found it
in the ZGuide now though. Seems like the ROUTER itself will invent those
for each connected socket that doesn't announce its own identity.
Happy
11 matches
Mail list logo