[reSIProcate] DNS not returning entries after 408?

[Scott Godin]

Good point about the 503's - I agree.  I am a little worried about only
blacklisting a timeout (408) for 32 seconds, when there are alternate
servers that could handle requests.  Does this mean that every 32 seconds we
will try to send requests to the black listed server again - and fail
(assuming the server is down)?  Or will the whitelisting logic kick in and
we will continue to use the good server?

 

Scott

 

From: Byron Campen [mailto:docfaraday at mac.com] 
Sent: Thursday, December 07, 2006 2:32 PM
To: Scott Godin
Cc: Jeremy Geras; resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] DNS not returning entries after 408?

 

            We can't unblacklist stuff that was blacklisted because of a
503. If all of the available servers are keeling over from overload, and
sending 503s, we are supposed to just shut up and wait for the blacklists to
expire. However, it is reasonable to say that this behavior is not warranted
in cases where we have blacklisted due to a timeout. If we wish to treat
these two scenarios differently, maybe a greylisting concept is what we
should use.

 

Best regards,

Byron Campen





Before the recent changes, that way I understood it the blacklisting was
supposed to work as follows:

1.        Only blacklist an entry if there other DNS entries to try.

2.       If we have ended up blacklisting all entries from a particular
lookup, then un-blacklist them all and let the next request start the cycle
again.

Scott

 

From: resiprocate-devel-bounces at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of Byron
Campen
Sent: Thursday, December 07, 2006 2:01 PM
To: Jeremy Geras
Cc: resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] DNS not returning entries after 408?

 

          This is happening because the stack is blacklisting the tuple that
your server was running on, because it didn't respond. This blacklist
(currently) lasts 32s. I was thinking about making this duration
configurable. Does anyone want to have a discussion about whether
blacklisting on a UDP timeout is something we want to be doing? It seems to
me that we might need to have a concept of "greylisting", where greylisted
tuples will only be used if they are all that remains to be tried. (This is
opposed to a blacklisted tuple, which we should never try, since chances are
we have been explicitly told, with a 503, to leave the tuple alone for a
while.) Any thoughts? (anyone?)

 

Best regards,

Byron Campen

Hi,

 

I'm using the latest code from SVN (updated today), and I've encountered an
issue with DNS in the following case:

 

Client                                          Registrar

      REGISTER (due to user login)------------->

      <---------------------------------- 200 OK

 

(at this point the Registrar becomes unavailable - its IP is still
reachable, but nothing is listening on UDP port 5060)

 

      re-REGISTER (due to Expires timer)------->

 

(~ 30 seconds go by and then I get a 408 from DUM)

(client sits idle for ~ 30 seconds more)

 

      REGISTER -------------------------------->

 

(Get a 503 Service Unavailable immediately from DUM)

(sit idle for any amount of time)

 

      REGISTER -------------------------------->

      <---------------------------------- 200 OK

 

 

My client is set up to use only UDP as a transport.  I'm using DUM.  I've
looked at the logs, and it seems the reason I'm getting the 503 is that
there aren't any DNS entries for my registrar: "Ran out of dns entries for
192.168.1.172. Send 503".  But this doesn't make sense, as there definitely
should be entries (and since I can register if I try once again after I get
the 503).

 

If I go back to an older revision (6609 which is from back in September), I
don't have this issue - i.e. I don't get the 503, my last REGISTER actually
goes out on the wire and I get my expected 200 OK.

 

Any thoughts?

 

Thanks,

 - Jeremy -

 

 

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel at list.resiprocate.org

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

 

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel at list.resiprocate.org

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061207/f56d9fe4/attachment.htm>