Hi, >Well, the problem is that it does not remember that which destination >did not work next time. The blacklisting would put the destination >that timed out into a container. The next transaction would look up >them and avoid blacklisted destination.
I think that blacklisting - as you describe it - is very useful to prevent servers that are considered dead from being used after a new DNS request. As for subsequent transactions, wouldn't it make sense to share some knowledge about the state of a server (with previous transactions). It's clear that the standard mandates that transactions are independent. But blacklisting also preserves some knowledge from earlier transactions. Quite a simple solution to circumvent a blacklisting algorithm would be to re-sort the internal DNS cache on a server timeout. A server that did not respond is moved to the tail of the list (kind of grey-listed). The next transaction would automatically use the server that answered the last request. The next DNS request sorts servers back into their initial order. If the server is still not running, it is grey-listed again. Can you see any reasons against this solution? Thanks and kind regards Stefan -----Original Message----- From: Pekka Pessi [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 1:52 PM To: Stefan Leuenberger Cc: sofia-sip-devel Subject: Re: Problem with proxy switch'over based on DNS results 2007/10/26, Stefan Leuenberger <[EMAIL PROTECTED]>: > Any hint where to implement blacklisting? > I'd thougth that the following code does this job (take the next result > and free the one that did not work...): Well, the problem is that it does not remember that which destination did not work next time. The blacklisting would put the destination that timed out into a container. The next transaction would look up them and avoid blacklisted destination. So what is needed to implement blacklisting? A hash table or a search tree where to put bad destinations (a su_addrinfo_t or tp_name_t perhaps) and a timestamp when they timed out last time. When a new transaction would be resolved, the results would be checked against the blacklisted destinations before using them in outgoing_query_results() and outgoing_resolve_next(). Perhaps also a setting to indicate how long time a blacklisted destination stay that way and when they become graylisted (like, stack would use them as a last resort even if they timed out. --Pekka > /** Resolve next destination. */ > static int > outgoing_resolve_next(nta_outgoing_t *orq) > { > struct sipdns_resolver *sr = orq->orq_resolver; > > if (sr == NULL) { > outgoing_resolving_error(orq, SIP_500_INTERNAL_SERVER_ERROR); > return 0; > } > > if (sr->sr_results) { > /* Use existing A/AAAA results */ > su_free(msg_home(orq->orq_request), sr->sr_results[0]); > sr->sr_results++; > if (sr->sr_results[0]) { > > > Kind regards > Stefan > > > -----Original Message----- > From: Pekka Pessi [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 25, 2007 6:34 PM > To: Stefan Leuenberger > Subject: Re: Problem with proxy switch'over based on DNS results > > 2007/10/25, Stefan Leuenberger <[EMAIL PROTECTED]>: > > The above behavior prevents that the switch-over to another proxy > works. Why > > does the stack switch back to helios (the proxy that is down) after it > > detected the outage and selected the next proxy (talos)? > > The helios should be blacklisted after the timeout, but the > blacklisting has not been implemented in the stack. > > -- > Pekka.Pessi mail at nokia.com > -- Pekka.Pessi mail at nokia.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
