Introduction

ZeroMQ's REQ and REP sockets look simple, but they have a strict internal state machine. In Go, calling them in non-blocking mode can be useful for timeouts or polling, yet it does not remove the fundamental request-then-reply alternation, which is why non-blocking REQ/REP often feels senseless for more flexible workflows.

The Core Limitation of REQ/REP

A REQ socket must send, then receive, then send again. A REP socket must receive, then send, then receive again. That rule is enforced by ZeroMQ itself.

So even if you use zmq.DONTWAIT, the socket still cannot skip its state transition requirements. Non-blocking mode only changes whether the call waits. It does not change the legal order of operations.

Here is a minimal Go example:

1package main
2
3import (
4    "fmt"
5    "time"
6
7    zmq "github.com/pebbe/zmq4"
8)
9
10func main() {
11    req, err := zmq.NewSocket(zmq.REQ)
12    if err != nil {
13        panic(err)
14    }
15    defer req.Close()
16
17    if err := req.Connect("tcp://127.0.0.1:5555"); err != nil {
18        panic(err)
19    }
20
21    _, err = req.Send("hello", 0)
22    if err != nil {
23        panic(err)
24    }
25
26    msg, err := req.Recv(zmq.DONTWAIT)
27    if err != nil {
28        fmt.Println("no reply yet:", err)
29        time.Sleep(100 * time.Millisecond)
30        return
31    }
32
33    fmt.Println(msg)
34}

This is non-blocking in the narrow sense that Recv returns immediately if the reply is not ready. But until a reply is received, the REQ socket is still waiting for the receive step in its protocol.

Why It Feels "Senseless"

Developers often expect non-blocking I/O to let them keep sending work while replies arrive later. REQ does not work that way. After one send, it is locked into waiting for one reply. If you try to send another request first, ZeroMQ raises a state error.

That means non-blocking Recv on REQ mainly helps you avoid freezing the thread. It does not turn the socket into a multiplexed asynchronous client.

If your real requirement is "send many requests without waiting for each reply in order," REQ/REP is the wrong pattern. You usually want DEALER/ROUTER instead.

Better Options in Go

If you only need a timeout or periodic polling, non-blocking REQ can still be reasonable. A cleaner approach is often to use a poller rather than a busy loop.

1package main
2
3import (
4    "fmt"
5    zmq "github.com/pebbe/zmq4"
6)
7
8func main() {
9    req, _ := zmq.NewSocket(zmq.REQ)
10    defer req.Close()
11
12    req.Connect("tcp://127.0.0.1:5555")
13    req.Send("hello", 0)
14
15    poller := zmq.NewPoller()
16    poller.Add(req, zmq.POLLIN)
17
18    sockets, err := poller.Poll(1000)
19    if err != nil {
20        panic(err)
21    }
22
23    if len(sockets) == 0 {
24        fmt.Println("timed out waiting for reply")
25        return
26    }
27
28    msg, _ := req.Recv(0)
29    fmt.Println(msg)
30}

This still respects the REQ state machine, but it avoids spinning and makes timeout handling explicit.

When to Switch to DEALER/ROUTER

Use DEALER/ROUTER when you need one or more of these behaviors:

• multiple in-flight requests
• out-of-order replies
• fully asynchronous request handling
• higher control over routing identities

That pattern is more complex, but it matches the expectations people often project onto non-blocking REQ/REP.

Common Pitfalls

The most common mistake is assuming zmq.DONTWAIT changes the protocol rules. It does not. It only changes whether the method blocks.

Another issue is busy-loop polling with repeated non-blocking receives. That burns CPU and usually signals that a poller or timeout-based design would be cleaner.

Developers also sometimes try to recover from a missing reply by sending another request on the same REQ socket. That fails because the socket is still in its receive phase.

Finally, if you need retry logic after a timeout, the practical solution is often to close and recreate the REQ socket or use a different messaging pattern altogether. Fighting the strict REQ/REP state machine usually leads to brittle code.

Summary

• 'REQ/REP enforces strict alternating send and receive steps.'
• Non-blocking mode does not remove that state machine.
• Non-blocking Recv is useful for timeouts and responsiveness, not for multiple in-flight requests.
• Use a poller if you want cleaner timeout handling in Go.
• If you need true asynchronous client behavior, switch from REQ/REP to DEALER/ROUTER.