distributed-process
distributed-process copied to clipboard
haskell-distributed
Relax EndPointAddress equality requirement
There are tests which check that the address of an EndPoint is equal (as a ByteString) to the EndPointAddress which appears in events like ConnectionOpened on a peer to which it connects. I propose removing this requirement. Really we just need to ensure that connecting to the EndPointAddress given in the peer's event queue will indeed connect to the EndPoint which opened the connection. == may be sufficient for that but it's not necessary.
Some motivation: https://github.com/haskell-distributed/network-transport-tcp/pull/54 in network-transport-tcp we don't want to use the EndPointAddress reported by the peer as an identifier for a connection to it, because the peer could lie about it and thereby deny service to whoever really does have the given address. So the OS-determined host/port should factor into the EndPointAddress chosen by the contacted peer, but that can't be done because the equality constraint forces us to use the peer's reported address exactly.
It would be good documenting the fact that the address in events can differ from the one used to create the transport in the remote peer.
On second thought, this may not be a good idea. There ought to be some way to determine whether two addresses pick out the same EndPoint and equality strikes me as the simplest and most natural implementation-agnostic way to do this.
That pull request https://github.com/haskell-distributed/network-transport-tcp/pull/54 does in fact take the peer's EndPointAddress as it's reported, it just verifies that the host matches the socket's host. So there's no problem with that.
The other motivating case was supporting NAT in network-transport-tcp. EndPoints behind NAT won't have network addresses so the idea is to have them make one up at random; and when they connect to some other EndPoint, that one will also make it up at random. In that case the two EndPointAddresses won't match, but we can argue that this is OK: the address that the EndPoint behind NAT has for itself only identifies it locally, not on the network, and similarly for the address that its peer generates for that EndPoint when it connects.