Inconsistent treatment of server entries causing compatibility issues with PHP's consistent node location algorithm

[kylerudy-imvu]

The behavior for adding servers to a new MemcachedClient differs, depending on whether you use AddServer after the ctor, or MemcachedClientOptions in the ctor.

When you pass in Server entries through MemcachedClientOptions, they are parsed and resolved, creating IPEndPoints for each entry. AddServer simply creates DnsEndPoints, and does not attempt to resolve.

Thanks to the excellent dependency inversion surrounding node locators and transcoders, there's the potential to add the serializer/deserializer and consistent node location algorithm necessary for full cross-compatibility with php applications that use memcache in the same pool. Unfortunately, the consistent node location algorithm uses the host name and port to calculate node selection for keys, which makes it compatible with DnsEndPoint but not IPEndPoints. This resulted in some difficult-to-diagnose bugs within our solution, as consistent node location would work with some initialization patterns but not with others.

At the very least, the behavior of creating DnsEndPoint vs IPEndPoints should be consistent between AddServer and the ctor, and configurable. It seems to me it would be more correct to expose the sanity checks around IPEndPoint construction for public consumption, and refactor the addition of Endpoints in either flow to require EndPoint rather than taking server strings and integer ports. That way, there's no hidden transformation in between the client's MemcachedClient configuration and their node locators.

Reference for the PHP consistent node locator algorithm: https://github.com/wayfair/memcache/blob/master/memcache_consistent_hash.c