SERVER-121142 and earlier work bring to light the server codebase's inconsistent handling of socket addresses.

The code was written with IP address families in mind, e.g. using the type HostAndPort, even though most places where an IP connection is used a unix domain connection could also be used. HostAndPort accounts for this by repurposing the "name" to mean "path to unix domain socket" when appropriate, but then the interpretation of the "port" varies from place to place.

Some code assumes that a zero "port" means "this is a unix domain socket," while other code uses the "port" to identify the associated IP listening interface.

When the server creates a unix domain socket, it picks a name that contains the port number of the associated IP listening interface – it so happens that there is a correspondence between IP listening interfaces and unix domain sockets, unless the database is configured to omit the latter.

In addition to HostAndPort and the unix-domain-sockets-kind-of-have-a-port-but-not-really convention, there is another type, SockAddr, that further confuses the meaning of "port" in the context of unix domain sockets. mongo::transport::CommonAsioSession has three relevant data members:

    boost::optional<HostAndPort> _proxiedSrcEndpoint;
    boost::optional<HostAndPort> _proxiedDstEndpoint;
    boost::optional<SockAddr> _proxiedSrcRemoteAddr;

Two of them have type HostAndPort, while the third and more recent has type SockAddr. It's not clear what "source" and "destination" endpoint means in the case of a unix domain socket, and there are conventions to use placeholders like "anonymous unix socket" and "proxy unix socket" in log messages, where the distinction is relevant.

This SERVER ticket tracks the work of drafting alternative representations for socket addresses that unify IP and unix domain connections, and remove the confusion of meanings for "host" and "port."