Architecture

Supervision Hierarchy

• ed_sup is the root supervisor
• ed_udp_server accepts incoming queries via UDP
• ed_udp_handler_sup spawns child worker processes to answer queries
• 0.64.0 and 0.67.0 are ed_udp_handler_server instances each working on a DNS request
• ed_zone_sup is responsible for supervising the zone subsystem
• ed_zone_registry_server contains information about all zones registered with the server
• ed_zone_data_sup supervises the actual zone servers
• 0.43.0 is an example of a ed_zone_data_server (here the sample root zone from the end-to-end tests).

Sample Query and Answer

1. A DNS query is received via UDP and accepted by ed_udp_server
2. ed_udp_server asks ed_udp_handler_sup to spawn a worker ed_udp_handler_server to process the request
3. ed_udp_handler_server decodes the request and calls ed_query_resolver to answer the query
4. ed_query_resolver asks ed_zone_registry_server for the zone associated with the request
5. if a zone exists ed_query_resolver requests a copy of the zone data from the associated ed_zone_data_server
6. ed_query_resolver answers the query from the zone data, optionally making recursive calls to fetch additional details
7. ed_udp_handler_server encodes the answer data and sends it to the original requester via UDP.

Notes

This is my first "real" OTP application, so I am not claiming that this architecture is particularly suitable or finalised for that matter. Comments are certainly most welcome.

If you are new to OTP, please take a look at my tutorial here: http://blog.bot.co.za/en/article/349/an-erlang-otp-tutorial-for-beginners. It's become quite popular and I had to constantly refer to it as I built up the app.