# Aeron Adds Name Re-Resolution for Changing Peer IP Addresses

DevFeed: [Aeron Adds Name Re-Resolution for Changing Peer IP Addresses](<https://devfeed.tech/articles/i-heard-a-rumour-30658.md>)

Original publisher: [Read original article](<http://bad-concurrency.blogspot.com/2020/04/i-heard-rumour.html>)

Author: Michael Barker (noreply@blogger.com)

Published: 2020-04-11T20:01:00Z

Content type: article

Language: en

Sources: [Bad Concurrency](<https://devfeed.tech/sources/bad-concurrency.md>)

Topics: [Network](<https://devfeed.tech/topics/network.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [Latency](<https://devfeed.tech/topics/latency.md>)

Tags: [cloud](<https://devfeed.tech/tags/cloud.md>), [dns](<https://devfeed.tech/tags/dns.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [latency](<https://devfeed.tech/tags/latency.md>), [network](<https://devfeed.tech/tags/network.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [pull-request](<https://devfeed.tech/tags/pull-request.md>)

## AI overview

The article explains Aeron's approach to resolving endpoint names again when peer nodes disappear and return with different IP addresses, a situation that can occur in cloud and Kubernetes environments. It describes using existing protocol messages to detect missing peers and moving potentially blocking name-resolution work from sender and receiver message-path threads to the conductor. It also introduces name resolvers that can use sources beyond system DNS.

## Source excerpt

Where Aeron catches up on the goss. The Need For Naming A few months ago a pull request appeared on Aeron's Github site that added the ability to request Aeron to resolve or re-resolve host names to IP addresses. In cloud environments, especially when using Kubernetes, when nodes fail and restart it is not uncommon for a node with the same host name to restart with a different IP address. Unfortunately for Aeron this could make life difficult as it would resolve IP addresses up front and stick with it for the life time of the media driver. This is particularly bad when we consider nodes that are part of Aeron Cluster, where we expect nodes to come and go from the cluster over time. It became very clear that we needed a plan that would allow Aeron to use logical names instead of IP addresses as endpoint identifiers and re-resolve those addresses appropriately. We didn't end up using the supplied pull request and came with an alternative solution that was a better fit with some of Aeron's longer term goals (I say we, it was mostly Todd Montgomery - I just did the C port). As DNS can often be a source odd network latency issues, we didn't want a name resolution solution that was entirely reliant on default system name resolution. So we have also included a mechanism for resolving names that works entirely within Aeron. Re-Resolution The first thing we needed to tackle was re-resolving IP addresses when peer nodes went away and came back with a different address. Fortunately we already have a indicators within the existing protocol that allows the media driver to detect when nodes have died. Aeron continually sends data frames or heartbeats (sender to receiver) and status messages (receiver to sender) during normal running. We can use the absence of these messages as a mechanism to detect that a node (that is identified by name rather than IP address) needs to be re-resolved. Periodically the sender and receiver will scan their endpoints to see if any having been missin