I don't think ZMQ connects should be timing out like you are doing. See <a href="http:

May be as simple as removing the check and return at <div class="Box Box--condense

This is a better reference: <a href="https://rfc.zeromq.org/spec/23/#socket-semantics"

Dial timeout? about zmq4 HOT 7 OPEN

go-zeromq commented on August 16, 2024

Dial timeout?

from zmq4.

Comments (7)

sbinet commented on August 16, 2024

you're right.

from zmq4.

ckoehler commented on August 16, 2024

May be as simple as removing the check and return at

zmq4/socket.go

Line 236 in 59e906c

if retries < 10 {

. The sleep is a good idea. No expert, though.

Also, thanks so much for doing this, it's saving me a lot of pain trying to build my app for other architectures. No CGO is a win!

from zmq4.

ckoehler commented on August 16, 2024

This is a better reference: https://rfc.zeromq.org/spec/23/#socket-semantics

from zmq4.

guidog commented on August 16, 2024

Hi!

At the moment the user facing .Dial is synchronous. This should be kept that way.

The spec talks about "reconnect", which in my view is something different from the initial connect.

I would opt for the following:

leave the initial connect synchronous to get some errors back (network unreachable, unknown host etc.)
implement a reconnect method used after there has been a successful first connection

While implementing 1. I'd like to add a context.Context to the .Dial methods or add a .DialContext method.

Cheers
Guido

from zmq4.

thielepaul commented on August 16, 2024

I think that the numbers of retries should be configurable, if the user sets it to infinite (could be -1 or so) then the behavior will be very similar to the libzmq implementation, while still being synchronous

from zmq4.

sbinet commented on August 16, 2024

sure, why not.
do you want to try your hand at a PR?

from zmq4.

thielepaul commented on August 16, 2024