[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
On Tuesday 23 Dec 2003 6:00 pm, Simon Waters wrote: > Neil Stone wrote: > > Neil Williams wrote: > > | When would a typical server refuse a connection request? > > > > Network or CPU load methinks.... > > Maybe, more likely the service was down, or you spoke to the wrong box > (which is the same thing really). Unless the DNS or the IP had been modified, it should always be the same box. I am getting fluctuations in DNS with other servers - they disappear from DNS then they're back then they're gone again. > The only thing I use regularly that refuses connections based on load > deliberately is sendmail, and I think it tends to do it within the SMTP > protocol rather than by just not listening, although I tend to see the > log messages not the temporary errors. > > Mr Williams what is the issue, you just handle it the same, but it > should at least come back promptly? I've just done another verification of the Z39.50 servers (nearly 1,000 of them) and my previous error messages archive shows that by far the most common error report was connection refused - up until today. Suddenly, not a single server out of 1000 has reported a refusal the allow the connection. Many have had other problems (only 600 are actually usable) - the most common now being timeouts. Where there's a canonical name, I check the DNS before blaming a timeout but a lot of the servers are only listed by IP. I also use a Net::IO::Socket connection to see if there's something actually running on that port at that IP. Only if both of those checks are OK do I pursue a formal connection and that's when I get refusals - or at least, I used to. The IO::Socket routine is new (it tries to open a tcp socket on the remote IP and port and then closes it if successful or dies) but I can't see how accepting one socket request would prevent the previously reported connection refused error. What I'm wondering is how these things get reported back - my Perl scripts check the die message $! for /Connection.refused/i or /Connection.timed.out/i so why would one disappear from the reports suddenly? It's not timeout related because previous runs have generated connection refused errors immediately upon attempting the connection - out of all the error reports, ECONNREFUSED was one of the quickest to be returned. Some of the most troublesome servers for refused connections since September are suddenly A-OK again. Duh? I notice it because there's a horrible bug in how the module deals with ECONNREFUSED and it's taken some work to handle it - albeit with a fair kludge. Suddenly, I'm not getting it being reported. Network/server overload would make sense - all these servers are in universities etc. where the students have just gone home. It's an ancient protocol and may well have a lot in common with sendmail than you may expect! (Plus the machines themselves are probably not in the best state / on the fastest network connections during term-time.) -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
Attachment:
pgp00032.pgp
Description: signature