[Devel] Re: [Users] NEW FEATURE: NAPTR lookup

[Bogdan-Andrei Iancu]

Hi Greg,

at the moment there is no retry support for neither NAPTR nor SRV. The 
resolver loops through all NAPTR/SRV records and looks for the first 
NAPTR|SRV|A pair of records that can be successfully resolved to IP address.

The biggest problem with having retry support for the resolve is the 
combination between parallel and serial forking. Lets supposed the 
following scenario:
    uriA parallel forks to uriX and uriY
    both uriX and uriY leads to distinctive sets of NAPTR/SRV records.

in such a case, even if it's a single transaction, you have to keep the 
state of the resolver for each branch to be able to do serial forking 
independently on each of them.

Another problem is detecting the failures. According to "4.3 Details of 
RFC 2782 Process" specifies usage on ICMP for UDP failures...and ICMP 
support is not reliable (depends on OS) and tricky to implement.

Do not get me wrong, I am not saying it's impossible, but it will take 
some time to get to it... :)

regards,
Bogdan


Greg Fausak wrote:

>Bogdan,
>
>This is great news!  Thank you!  I've got
>a questions about retries.
>
>I'm curious if retries are built in, or do I employ t_on_failure?
>What I mean is...
>
>How do I get the t_relay() to try subsequent naptrs and/or srvs in the
>event the current one fails?  Is all of that automatic, or do I need
>a t_on_failure?
>
>I think I understand that you skip ones that don't resolve, but, what if
>they resolve but the transaction times out either on the naptr or on the srv?
>
>Best,
>
>-g
>
>
>
>--
>Greg Fausak
>greg at thursday.com
>  
>