8 Feb
2006
8 Feb
'06
4:38 p.m.
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(a)thursday.com