[Users] NEW FEATURE: NAPTR lookup

[Greg Fausak]

Howdy,

Back from the west coast...

Concerning this, inline:

On Feb 4, 2006, at 9:15 AM, Bogdan-Andrei Iancu wrote:

> Greg,
>
> this is the happy case where parallel forking is involved. The  
> serial forking works by keeping in AVPs the next uris to be tried  
> (in case of negative replies). But the AVPs are per transaction and  
> you cannot say on which specific branch to be used (in case of  
> parallel forking).
>

I think that's OK.  From what I can tell, the parallel fork branches
are serialized, then put into AVPs. I thought the order was maintained
with q values, but, initially I can deal with a random order I think.  I
was just wondering if it does what I think it does.  If so, it is
exactly what I need!

> Also, from performance reasons, the best approach will be to try to  
> perform the sequential queries only if the previous tried failed...
>

I thought that is what happened here.  That is, the branches are
serialized (serialize_branches()), then the next brand is made the
current one (next_branches()), and finally, t_on_failure() is fired
up and the packet is relayed with t_relay().  The next branch would only
be tried if there is a failure, right?  Am I missing the point?

-g


> I will try to put tougher a plan about how to have failover in the  
> resolver.
>
> regards and nice weekend to you also,
> bogdan
>
>
> Greg Fausak wrote:
>
>> Bogdan,
>>
>> Thanks for the reply.
>>
>> Will this work:
>>
>> here are some examples of how to uses this new functionality:
>>     1) enum doing serial forking:
>>        {
>>           .....
>>           enum_query("e164.arpa.","voice");
>>           serialize_branches(1);
>>           if (!next_branches()) {
>>               sl_send_reply(...no enum found...);
>>               exit;
>>           }
>>           t_on_failure("1");
>>           t_relay();
>>        }
>>
>>        failure_route[1] {
>>           if (next_branches()) {
>>               t_relay();
>>           }
>>        }
>>
>>
>> I haven't tried it yet.  But I think it is an example
>> of serial forking using naptrs.
>>
>> Have a great weekend!
>>
>> ---greg
>>
>> On Feb 4, 2006, at 4:01 AM, Bogdan-Andrei Iancu wrote:
>>
>>> 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
>>>>
>>>
>>
>