reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] DNS SRV support

Hi Boris,

I'll take a stab at answering some of these questions.  But I hope someone who is more familiar with the resip failover and DNS cache logic can chime in here.  

> 1.  What is a difference between graylist and blacklist. (I suspect that hosts from black list are never tried, while grey-listed hosts are tried when there are no other hosts left to try)?

[Scott]  Correct.

> 2.  Why timeout for no response case (408) is so short. Faulty host is being tried very fast again, the transaction fails instead of going with available hosts.

[Scott]  I think it configurable, but I'm not sure why this default was chosen. 

> 3.  Is there any way to use ICMP messages as indication of host unavailability instead of waiting until transaction timeout and if there is any way to resend request to the next host in this case?

[Scott]  For UDP this is not really practical.  See the "How can I read ICMP errors from "connected" UDP sockets?" section of http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-socket-faq-5.html - we don't use connected UDP sockets in the resiprocate transports.  I think it would be possible to get this working for TCP connections though - however this may already be the case.  Someone who knows the DNS failover code logic better, please chime in here.  : )

> 4.  Is there any way to get notified regarding list of all hosts maintained by stack instance and does it make sense to ping (using OPTIONS for example) these hosts directly (bypassing SRV query), so if status of the host is changed it will be known sooner and probably even without wasting real transaction?

[Scott]  Take a look at the KeepAliveManager logic in DUM.  This tracks all hosts that resiprocate is communicating with, and send CRLFCRLF keepalive packets to them, if enabled.  I think it could easily be changed to send OPTIONS instead of CRLFCRLF packets.  If the OPTIONS transaction times out then we could assume the server is down, and potentially greylist or blacklist it.  This would likely involve code changes to the stack as well as DUM.

Scott


On Sun, Apr 12, 2009 at 9:39 PM, Boris Rozinov <borisrozinov@xxxxxxxx> wrote:

Hi folks,

 

I got some questions regarding DNS SRV support and will appreciate your response:

 

For the code in TransactionState::sendToTU:

  1. In case of 503 with Retry-After host is added to blacklist for timeout specified in Retry-After
  2. In case of internally generated 408, host is added to grey list to for 32 seconds.
  3. In case of any other response host is being white listed.

 

My questions are:

  1. What is a difference between graylist and blacklist. (I suspect that hosts from black list are never tried, while grey-listed hosts are tried when there are no other hosts left to try)?
  2. Why timeout for no response case (408) is so short. Faulty host is being tried very fast again, the transaction fails instead of going with available hosts.
  3. Is there any way to use ICMP messages as indication of host unavailability instead of waiting until transaction timeout and if there is any way to resend request to the next host in this case?
  4. Is there any way to get notified regarding list of all hosts maintained by stack instance and does it make sense to ping (using OPTIONS for example) these hosts directly (bypassing SRV query), so if status of the host is changed it will be known sooner and probably even without wasting real transaction?

 

 

Thanks,
Boris

Get the name you've always wanted ! @ymail.com or @rocketmail.com.