[wxqc] cwop.aprs.net

Mon Jun 2 22:46:36 CDT 2008

I've considered that and already prototyped something using nsupdate. 
However, there is a lot of DNS caching going on out in internet land. 
Not all DNS flavors play by the same rules with respect to their 
interpretation of parameters and there is even variation just between 
different versions of bind. Some servers, for example, think TTL is some 
minimum suggestion and then go on to cache the record as long as they 
please. Bottom line is that even if you took the dead server out of the 
authoritative DNS server it would probably be back online before all of 
the caches expired the record. Its actually very easy to dynamically 
update DNS, I've done it. The challenge is getting the change to 
propagate quickly enough to do some good.

"Easily solved" were the first words out or my mouth months ago when I 
first started looking into this. Then I started to see the brick wall 
coming at me out of the fog... :-)

-Ted-

tim.mcmanus at mac.com wrote:
> The problem is easily solved if I can use your DNS servers and set it 
> up so that when a server is dead, DNS drops it from the round robin list.
>
> Perhaps a Nagios monitor that triggers an event that stops BIND, 
> updates the DNS record and restarts BIND.  I'm not a programmer, but 
> it seems simple enough (doesn't everything).
>
> In understand it's a problem with Davis's software, but I'm not going 
> to hold my breath for an update.
>
> Thanks for the comprehensive update!
>
> --
> Tim McManus
> tim.mcmanus at mac.com <mailto:tim.mcmanus at mac.com>
>
>> Date: Mon, 02 Jun 2008 12:39:42 -0400
>> From: Ted Lum <gladstonefamily.net at tedworld.com 
>> <mailto:gladstonefamily.net at tedworld.com>>
>> Subject: Re: [wxqc] cwop.aprs.net
>> To: Discussion of weather data quality issues
>> <wxqc at lists.gladstonefamily.net <mailto:wxqc at lists.gladstonefamily.net>>
>> Message-ID: <4844224E.7080204 at tedworld.com 
>> <mailto:4844224E.7080204 at tedworld.com>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Linux/Unix will send back an ICMP "connection refused" in response to an 
>> attempt to connect to a port where _nothing is listening_. This differs 
>> slightly from Windows that just won't send ICMP so you end up getting a 
>> socket timeout. Connection refused on a box is characteristic of a dead 
>> process. Routers on the other hand return ICMP "destination unreachable" 
>> because they can't route a packet, usually either due to route table 
>> errors or a route that has gone down. Servers do not send ICMP 
>> destination unreachable, only routers.
>>
>> Regardless, WeatherLink was architected poorly and would not try any 
>> other server no matter what comes back, and in some cases the 
>> application hangs and you have to restart it. This is the response I got 
>> back from Davis on this topic:
>>
>> "I forwarded your email to our WeatherLink server person. He said you are
>> entirely right.  CWOP lists several servers and Weatherlink.com does 
>> only try
>> to upload to the first one.  He said he thought it would be a good 
>> idea to
>> try the others but haven't coded it yet.  He is aware of the problem 
>> and it
>> has been added to the our bug list. Thank you for the input."
>>
>> Davis are the only ones that can fix WeatherLink. There is no simple 
>> work around for this. The best that could be hopped for would be a 
>> solution that dynamically updates DNS when a server goes down. But due 
>> the how DNS works and how the internet is put together with DNS caching 
>> all over the place, and not necessarily playing by all the same rules, 
>> it probably would still not be 100% effective. The server likely would 
>> be back up before all the stale records got aged out.
>>
>> Basically it goes like this. If the internet circuit goes down the 
>> gateway router will probably return "destination unreachable". There are 
>> a whole lot of reasons you might get "destination unreachable" but with 
>> the internet circuit usually being the most brittle that's the most 
>> likely cause. If the circuit is up and the path is good through the last 
>> router, down to the subnet, but the server operating system or network 
>> stack is down (or your talking to a Windows box or there is a firewall 
>> in the way) you'll get a local socket timeout because nothing at all 
>> came back and your client got tired of waiting. If the O/S and network 
>> are up but the process that services requests on the port is either not 
>> started or dead, you'll get "connection refused" (unless its Windows or 
>> there is a firewall in the way) - "connection refused" = "no one is 
>> listening". These messages are implemented deep in the internet protocol 
>> (ICMP and IP), they are not arbitrary messages that applications create 
>> or send. Its the responsibility of the client application to understand 
>> how the internet protocols work and do the right thing.
>>
>> -Ted-
>
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> ------------------------------------------------------------------------
>
> _______________________________________________
> wxqc mailing list
> Post messages to wxqc at lists.gladstonefamily.net
> To unsubcribe or change delivery options, please go to:
> http://server.gladstonefamily.net/mailman/listinfo/wxqc
> To search the archives: http://www.google.com/coop/cse?cx=008314629403309390388%3Aknlfnptih9u
>
> The contents of this message are the responsibility of the author.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://server.gladstonefamily.net/pipermail/wxqc/attachments/20080602/764c5e48/attachment-0001.html 