[oktal]

Context

A service bus peer can be configured to listen to a particular endpoint.
We currently support a configuration endpoint syntax where the port can either be a wildcard, eg tcp://*:*, letting the OS chose an ephemeral port, or a single, fixed port, eg tcp://*:14001

Motivation

We want to support specifying a port range in a configuration endpoint. This allows for easily discriminating zebus-specific traffic.

Changes

This MR introduces a new tcp://<host>:[<start>..<end>] syntax to configure the inbound endpoint the peer will listen on.
A [<start>..<end>] range can be configured as a port. The system will then pick the first available port in the range by attempting to bind to any single one.

A new ZmqPort discriminated enum type has been introduced to represent such a port, that can take the following values:

• ZmqPort.Wildcard, represents a * wildcard port
• ZmqPort.Single(port) represents a fixed <port> port
• ZmqPort.Range(start, end) represents a [<start>..<end>] port range

A ZmqSocket.TryBind operation has been introduced to attempt to bind to a given endpoint. When the operation returns EADDRINUSE, we simply attempt the next port in the range.

Two services starting at the same time on the same machine will compete on the same range, but they should all end up succeeding, given a reasonably-sized range.

[ocoanet]

nitpick: It seems weird that a type named ZmqPort can represent a wildcard or a range. I would prefer a more explicit name like ZmqPortSelector or ZmqPortSpec.

[oktal]

nitpick: It seems weird that a type named ZmqPort can represent a wildcard or a range. I would prefer a more explicit name like ZmqPortSelector or ZmqPortSpec.

To me it seems natural because I view it as a real, discriminated union type, but I understand your feeling.

I like ZmqPortSpec, the semantic would be, you have a spec, and then you get back a ZmqPort (or ushort) after resolution, even though we don't really need the port value, I think.

[oktal]

I renamed ZmqPort to ZmqPortSpec