For how much time ZeroMQ (0MQ) server keeps state information of a client sending messges?

Question

I am studying the message delivery guarantee in ZeroMQ, if it ensures exactly-once message delivery.

The classic method is to keep the message number and client ID at the receiving node, and each time a message received should be compared with the log to check if the message is already received.

In ZeroMQ (0MQ) guide, chapter 4:

"To handle non-idempotent operations, use the fairly standard solution of detecting and rejecting duplicate requests. This means:

• The client must stamp every request with a unique client identifier and a unique message number.
• The server, before sending back a reply, stores it using the combination of client ID and message number as a key.
• The server, when getting a request from a given client, first checks whether it has a reply for that client ID and message number. If so, it does not process the request, but just resends the reply."

I want to know the type of the log ZeroMQ saves the messages and client IDs into it (Vector, map, array...), and for how much time it keeps the state for each client (ID, messages..).

Is there a timeout to remove the client information? After removing the information of a specific client, what if an old duplicate message was received?

Answer 1

Welcome to the Zen-of-Zero.

_{In case one has never worked with ZeroMQ,
one may here enjoy to first look at "ZeroMQ Principles in less than Five Seconds"
before diving into further details}

Q : "Is there a timeout to remove the client information?"

No, there is no such timeout made accessible from the documented API to the user-side application.

Q : "After removing the information of a specific client, what if an old duplicate message was received?"

During the life-time of a { .bind() : .connect() }-relation, setup between legally-cooperating counterparties, there is but one warranty - any kind of message gets either delivered as a 1:1 binary copy of the original, or not at all ( the intent is to keep any kind of messages, huge, small, multi-frame or even an empty one, a sort of atomic ( in-divisible ) entities ).

ZeroMQ is and always was a broker-less messaging, where state of message-flow throughout the infrastructures is not recorded, the less re-constructed via the ( not present ) broker and its services.

ZeroMQ principles of operations are well documented in published ZMTP/RFC-documents, which define the minimum scope of functionalities for any 3rd-party, so as to become a ZeroMQ-compliant cooperating peer. Yet, most of the ZMTP/RFC-documented requirements is being implemented "inside" the ZeroMQ, or 3rd-Pty-ZeroMQ-emulating nodes and not accessible via the published API-interfaces to the user-side application.

ZeroMQ internal design is always accessible in source-code repositories.