czmq | High-level C binding for ØMQ

I am answering my own question for a complete solution pub/rec

Publisher code:

The IP_ADAPTER_ADDRESSES::FirstPrefix field gives you a list of subnets/prefixes that are assigned to the adapter, but as the documentation states, GetAdaptersAddresses() doesn't tell you which specific IP address on the adapter corresponds to which subnet/prefix. So, to determine each IP address's particular subnet/prefix, you have to look at the individual entries in the IP_ADAPTER_ADDRESSES::FirstUnicastAddresses list.

On Windows Vista and later, the IP_ADAPTER_UNICAST_ADDRESS::OnLinkPrefixLength field provides the length of the IPv4 subnet mask for an AF_INET address, and the length of the IPv6 prefix for an AF_INET6 address. For IPv4, the length can be passed to the ConvertLengthToIpv4Mask() function if you need the actual subnet mask.

On Windows XP, the OnLinkPrefixLength field does not exist. Fortunately, an AF_INET address's IPv4 subnet mask can be retrieved by calling the GetIpAddrTable() function and then looking for the IP address in the table (in the MIB_IPADDRROW::dwAddr field - the subnet mask will be in the MIB_IPADDRROW::dwMask field).

I don't know how to get an AF_INET6 address's IPv6 prefix length on XP, if you need that.

The mock-up code has a caveat - it disobeys the published API as it never sends a single message to any peer ( because of a missing non-SNDMORE flagged frame ever ) + better .bind() onto an existing, reachable TCP-address ( not an emulated abstract loopback interface on 127.0.0.1 ), otherwise there would be no external peer to ever be able to initialise a communication and deliver any request to only next process the raw[] or whatever else in the infinite while-loop:

I identified the issue. It is related to the mdp_broker. As of commit 603a304fb674733bd00c0314761242da013a327f from Sat Feb 29 10:20:52 2020, the broker does not dispatch queued requests unless there is either a "worker_ready" or a "client_request" event. So, if there are requests added to the queue while no worker is available, the total number of requests received and requests dispatched will diverge and some requests will remain in the queue unprocessed until they time out.

MDP-Broker needs to also check/dispatch any requests as soon as/as long as there are requests in the queue and a worker waiting - regardless of an incoming handle_request event.

So I added a call to s_dispatch() at the end of the handle_final() function in mdp_broker.c . It causes the broker to check for pending requests and send dispatch them, every time a worker is re-added to the list of waiting workers after it has processed a previous requests.

handle_final() in mdp_broker.c should therefore look like this: