parallax background

Using DynConD - Implementation for client-side load balancing

parallax background

DynConD client-side load balancer implementation

  • In stand-alone mobile and desktop applications, DynConD uses its own DNS client library which is a proxy between standard DNS name resolving function such as getaddrinfo() and DNS client app (Android, Linux, iOS, Windows)
  • Dyncond Service Client-side load balancing implementation is simple, fast and straightforward by replacing the existing getaddrinfo() function with new dyncondgetaddrinfo() function (Linux, iOS, Windows) and InetAddress() with a new DynConDInetAddress() function (Android)
  • dyncondgetaddrinfo/DynConDInetAddress calculates DNS metric and sorts the IP addresses of the servers for DynConD.Net hosts (the servers of the network service) from optimal to less suitable by using server parameters (server load or service response time) and measuring the network distance from the client to the servers and checking their availability at the same time
  • Download DynConD’s Android, Linux, iOS and Windows libraries
 
 

DynConD client functionality

  • DynConD’s dyncondgetaddrinfo/DynConDInetAddress functions send every “Interval Parameter” “Request” number of measurement packets to defined “Protocol” and “Port” for “Server’s Response Time” measurements. Requests are sent simultaneously on all received IPv4 and/or IPv6 IP addresses for all TXT RR for a particular FQDN. If the IPv4 / IPv6 IP address of a server does not reply in the “Timeout” interval for all measurements, it is declared unavailable. Measurements are made using a TCP-SYN packet, unless the proxy pass option is enabled when a full TCP connection is made to any public IP address, which prevents the measurement of the response time of proxy / mobile proxy requests by using unique server requests
  • DynConD TXT RRs can be obtained from the local DNS resolvers of the client or from the ADNS servers of DynConD, whereby real-time data is provided to the client
  • If DynConD does not resolve an IP address for provided FQDN, a default error value is returned to the client, informing that a classic A / AAAA query must be used, which does not normally return the optimal type of IP addresses
  • Implementation examples: for FQDN www.example.com there are 3 TXT/A RR’s for IP1, IP2 and IP3. Number of requests is 3, Interval is 5 ms and defined Timeout is 200 msec
    • If server response time is IP1=100 msec, IP2=50 msec and IP3=80 msec, the overall duration of composite DNS metric calculation is 110 msec (100 msec for IP1 response time measurement + 2×5 msec of Interval value)
    If server response time is IP1=100 msec, IP2=50 msec and IP3 is unavailable, the overall duration of composite DNS metric calculation is 210 msec (200 msec of Timeout + 2×5 msec of Interval value)
 
 

DynConD on the server side

  • DynConD implementation does not require any changes or adaptation to existing network services
  • There are two types of implementation:
    • If CNAME RR implementation is used, in ADNS of the network service existing DNS’s host A/AAAA/CNAME RR have to be replaced with DynConD.Net host CNAME RR (www.example.com becomes alias of A/AAAA RR www.example.com.dyncond.net), no need for changes of http host header
    If A RR implementation is used, a new A/AAAA DynConD.Net host (for example www.example.com.dyncond.net) is added in DynConD.Net ADNS, there is no need for changes in www.example.com’s ADNS, http host header needs to accept hostname www.example.com.dyncond.net
 
 

Example for using DynConD with CNAME

  • http service www.example.com is available on 2 servers, IP1 and IP2
  • FQDN www.example.com is an alias to CNAME www.example.com.dyncond.net (administrated by example.com domain owner)
  • www.example.com.dyncond.net has two A RRs in DynConD.Net ADNS servers that refer to IP1 and IP2 and two TXT RRs with DSS parameters for IP1 and IP2 (administrated by DynConD.Net)
  • DynConD DNS client (dyncondgetaddrinfo/DynConDInetAddress) on client device resolves www.example.com and receives 2 TXT RRs for IP1 and IP2, measures network distance to IP1 and IP2 and calculates metrics
  • The client device starts communication with the server which has the lower DNS metric
 
 

How can a network service start using DynConD?

There are a few simple and quick steps to get started with DynConD:

  1. Register the network service on my.dyncond.com user portal:
    • Register the FQDN of the network service
    • Enter all public IPv4/IPv6 addresses of the network service
    • Configure mandatory DynConD options (common predefined values are offered)
    • If the Load method is selected, download Windows/Linux Agent and configuration file and install Agent on each server
    • If the service response time is selected, the http page must be available to DynConD.Net servers for measuring the response time
  2. If CNAME implementation is used, then change the existing A/AAAA RR of the network service to the alias of DynConD.Net CNAME
  3. Implement DynConD client library to the mobile and desktop application
  4. Deploy the application to the users
 
 

How does DynConD work?

  • The client Android, Linux, iOS or Windows application uses the DynConD library to query its DNS resolver or DynConD’s ADNS servers for a TXT RRs* of a network service (www.example.com when using CNAME RR or directly www.example.com.dyncond.net when using A/AAAA RR)
  • DynConD.Net ADNS server response with TXT RRs of hostname www.example.com.dyncond.net which contains the IP addresses of network service servers and parameters for DSS metric calculation
  • The client measures the network distance from the IP address of each server, calculates DNS metric with network distance and server service response time and/or server load as parameters, and sorts server IP addresses from the lowest (optimal) to the highest DNS metric
  • The client establishes a TCP or UDP connection to the optimal server
* DynConD.Net ADNS servers also answer to A/AAAA DNS queries
 
 

Testing DynConD

DynConD can be tested free of charge for one DynConD native FQDN (for example: myservice.dyncond.net) and one CNAME FQDN (for exymple: myservice.example.com.dyncond.net)

FQDN and server configuration and management, system and server status monitoring can be done via the DynConD user portal:

Portal_ServerEdit
Portal_ServerGraph

Client-side load balancing testing can be performed by using Android, iOS, Linux and Windows demo and testing applications:

 
DynConD_Android_app
 
 
User portal: Free trial for 30 days!
gdpr-image
This website uses cookies to improve your experience. By using this website you agree to our Privacy policy.
Read more