Clean up network address handling

[mattklein123]

This came to a head as part of: #377

The entire string based system we are currently using for addresses, along with utility functions in Network::Utility, is a mess. We should clean this up so it properly supports TCP vs. UDP, is an interface, etc.

This will probably also help us more easily support IPv6 in the future.

[jamessynge]

Do you have a plan/design/sketch for how to represent addresses, addresses ranges, address families and protocols?

[mattklein123]

My current thinking here is to do something along the lines of what follows.

Basically, have a root class for an address, generic methods where possible, then a type switch to allow retrieving more detailed info when the caller needs to work with address details. For example Ip would support port/address/etc. where as unix only exposes name. I think with this design we can support IPv6 quite easily, and also actually hide some system details so that if/when we port to NT, etc. it's easier. @jamessynge lmk what you think.

enum class AddressType { Ip, Unix };

class IpAddress {
...
};

class UdsAddress {
...
};

class Address {
  virtual AddressType type() PURE;

  // returns a value IFF type() == Ip
  virtual IpAddress* ipAddress() PURE;

  // returns a value IFF type() == Unix
  virtual UdsAddress* udsAddress() PURE;

  // returns a generic friendly name for logging, etc.
  const std::string& friendlyName() PURE;
};

[jamessynge]

Regarding AddressType, I assume the point of having Unix is to support local communications ala a named pipe (but UDS). I notice a request for Windows support in #129, and wonder if a more generic name would work.

Regarding having the Address class be virtual, would your plan be to use a shared pImpl approach, to make it easy/low-cost to copy addresses around?

[mattklein123]

Yes we currently support UDS addresses for client connections. From an interface perspective we can call this Pipe or something similar.

Yes, the idea would be to make copying/accessing low cost, so would expose as shared_ptr where necessary.

[jamessynge]

Regarding a shared pImpl approach (rather than shared_ptr exposure), I was thinking of something like:

class Address {
 public:
...
 private:
  std::shared_ptr<AddressImpl> pImpl_;
};

This doesn't expose the shared_ptr, though it probably requires considering the AddressImpl to be immutable, with Address itself being modifiable via assignment (i.e. "overwrite" with a pointer to a new impl).

[jamessynge]

Note that I'm very supportive of the goal of hiding the details of a specific address (IPv4, IPv6, UDS, Pipe), and not continuing to use strings. One complication of course (the leaky abstractions problem) is that some APIs might be Internet specific, so receiving a UDS or Pipe address will necessitate arg checks and status returns.

[mattklein123]

re: the shared impl approach. That's fine. I don't have a strong opinion. I can take a first crack at getting the interfaces plumbed through and flesh out the details. In V1 it probably won't even require an embedded impl just to get parity with existing functionality.

re: Yes, I agree that ultimately there is no way around in some cases having code that does things based on type(), though I think that it is probably possible to limit this quite a bit.

Alright it seems like we are basically in agreement on approach. I can get this going soon.