[sr-dev] handling failed t_relay() when multiple usr locations

[Andrei Pelinescu-Onciul]

On Mar 08, 2010 at 21:55, I?aki Baz Castillo <ibc at aliax.net> wrote:
> El Lunes 08 Marzo 2010, Alex Balashov escribi?:
> > But when does t_relay() itself ever fail due to endpoint reachability
> > issues?  I think t_relay() only fails for formal reasons, like host
> > name lookup failure, invalid address format, etc?  Otherwise, it
> > returns success;  if the endpoint is not reachable, the transaction
> > simply times out.  If this is the case, branch route does get called.

It depends. If the reachability issue can be detected immediately, then
t_relay() will fail. If it cannot be detected (e.g. connect error on tcp
in async mode), it won't.
Note also that t_relay() will fail only if all branches fail.

For example in tcp async mode (default), the first time you try to
t_relay() to an unreachable destination, t_relay() won't fail
immediately (it will timeout eventually).
The second time it will, because that address will be now in the
blacklist.

> 
> In case of error, the function returns the following codes: 
> -1 - generic internal error 
> -2 - bad message (parsing errors) 
> -3 - no destination available (no branches were added or request already 
> cancelled) 
> -4 - bad destination (unresolvable address) 
> -5 - destination filtered (black listed) 
> -6 - generic send failed

No, it only returns -1 (error).
It sets ser_error to one of the above error conditions (with the
exception that it uses E_SEND for send failure, blacklist, denied by
onsend_route or dns failure). ser_error is used for automatic reply
generation (in case now t_reply() is used in the script).


Andrei