Difference between revisions of "Why Asynchronous DNS"

From reSIProcate
Jump to navigation Jump to search
 
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
resiprocate uses the ares asynchronous dns library from MIT. We use a forked version of ares that is in the contrib subdirectory of the resip project. The main differences between the MIT version and the resip forked version are that numerous bugs have been fixed particularly on win32 architectures and IPV6 support has been added.  
+
Since the resip stack is intended to be suitable for use in server products, it is important that throughput should be minimally impacted by DNS latency. Using an asynchronous DNS allows processing to continue while we wait for a DNS result to come back. This is especially important because SIP uses a multi-step DNS resolution algorithm that may require several queries to be made in sequence before the end result is obtained.
  
It is impossible to know ahead of time how long a dns query will take. If the dns client library is synchronous care must be taken in the application to avoid blocking while a result is being retrieved. There are two methods of dealing with this problem: asynchronous blah, blah, blah
+
SIP clients and servers can use DNS to resolve URIs for locating next hops. Details are covered in [http://www.ietf.org/rfc/rfc3263.txt RFC 3263].
 +
 
 +
ReSIProcate uses a forked version of the ares asynchronous DNS library originally from MIT. This forked version is located in [https://scm.sipfoundry.org/rep/resiprocate/main/contrib/ares the contrib subdirectory of reSIProcate's svn repository]. The reSIProcate version offers the following over the MIT version:
 +
:* numerous bug fixes, particularly on win32 architectures
 +
:* support of IPV6
 +
 
 +
<!-- It is impossible to know ahead of time how long a DNS query will take. If the DNS client library is synchronous, care must be taken in the application to avoid blocking while a result is being retrieved. There are two methods of dealing with this problem: asynchronous blah, blah, blah -->

Latest revision as of 15:13, 23 February 2007

Since the resip stack is intended to be suitable for use in server products, it is important that throughput should be minimally impacted by DNS latency. Using an asynchronous DNS allows processing to continue while we wait for a DNS result to come back. This is especially important because SIP uses a multi-step DNS resolution algorithm that may require several queries to be made in sequence before the end result is obtained.

SIP clients and servers can use DNS to resolve URIs for locating next hops. Details are covered in RFC 3263.

ReSIProcate uses a forked version of the ares asynchronous DNS library originally from MIT. This forked version is located in the contrib subdirectory of reSIProcate's svn repository. The reSIProcate version offers the following over the MIT version:

  • numerous bug fixes, particularly on win32 architectures
  • support of IPV6