Re: paging all socket geniuses
- From: Christopher Brown <cjbrown102@xxxxxxxxx>
- Date: Thu, 31 Jul 2008 09:08:19 -0700 (PDT)
On Jul 30, 8:53 am, Kenny <kentil...@xxxxxxxxx> wrote:
George Neuner wrote:
On Tue, 29 Jul 2008 21:31:11 -0400, Kenny <kentil...@xxxxxxxxx> wrote:
But on another XP of mine the call to make-socket goes away for almost a
minute and then returns:
(SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
:REMOTE-PORT 80
:TYPE :STREAM
:ADDRESS-FAMILY :INTERNET)
1[4]: returned
#<MULTIVALENT stream socket connected from smokinjoe/1044 to
s3.amazonaws.com/80 @ #x21affe9a>
"smokinjoe" is the network name (terminology perhaps off) of the laptop.
Anyway, the very long delay is to me a bad sign, and I am wondering if
smokinjoe instead an IP address (again, pardon if my terminology off,
this is not my field) is a reflection or cause or whatever of that.
After this a trace shows the cl-s3 family of code staggering on for a
while before grinding to a hang on some attempted communication, but I
can break out of it (the first time).
Side info: the laptop in question has no problem talking to the
Internet, and again, this code runs fine on three systems I have tried..
It sounds like it is an address resolution problem.
Check that the DNS client service is running on the laptop. The
service is a local name cache ... Windows works perfectly well, but
slower, without it.
Check the DNS and WINS settings on the laptop connection to be sure
you don't have erroneous domain suffixes or non-existent servers
listed. If you've moved the laptop from one net to another, there may
be dribbles in there. If there are any deliberate settings in the
"advanced" tabs, they will override the DHCP configuration.
If you're using a domain controller make sure that WINS requests are
not being resolved using DNS - the WINS service has an option to do
that rather than having parallel name databases, but there is a huge
delay when WINS relays a request to DNS. Either If you don't have to
worry about handling 9x or NT machines, you can turn off the WINS
service on the domain controller entirely.
If none of this helps, there are a few other esoteric things to try
before nuking the OS.
George
--
for email reply remove "/" from address
Thanks, George, that is a ton of great stuff to try, I wish I could. :)
But when I tried to open up the Networking control panels I was reminded
of a year-ago Bad Hair Day after which they themselves simply refused to
open. Fortunately I now feel justified in waiting until I get a report
from someone with a system in better shape.
Thx again to you and everyone who pitched in on this.
kt
As is usually the case on the 'net, there's some good and some bad
advice, and details missing. My advice is no different:
1) The best way to check for connectivity to something like S3, or
another HTTP speaker is (as someone above suggested) to make an HTTP
request using curl, wget or even 'telnet s3.amazonaws.com 80'. Ping
and traceroute answer different questions (i.e. whether the listener
or intermediate device blocks icmp *echo request* and blocks or does
not return icmp error messages) On a good day, they are useful
diagnostic tools in the right hands. On a bad day, they are just
confusing.
2) Blocking *all* icmp can be a bad thing, but selectively blocking
icmp subtypes (like loose source routing or echo request) is common
and healthy. It's also off-topic. The Path MTU problem results from
blocking ICMP can't fragment errors, not echo request / response.
3) Address resolution can be a problem, can cause delays, and can be
easily diagnosed. Someone mentioned 'nslookup'. Also check out
'dig'. If your initial socket call pauses for a long time, a packet
sniffer would tell you if the name resolution is taking a long time,
but then again, so would doing a lookup with dig and trying the IP
address directly. I like alien_guy's advice about changing Allegro's
resolver behaviour, but I wouldn't worry about udp being blocked
upstream. Almost all DNS traffic is udp (tcp being used for large
record transfers and other miscellania) and blocking it would bust so
much.
4) There's always a possibility of routing & traffic management
anomalies, but again these are usually red herrings. Large systems
like S3 and others typically have some form of global traffic mgmt in
the form of smart DNS. In one common technique, they look at the IP
address of the recursing DNS resolver making the resolution call,
ascertain approximately where it is, and return the "closest"
instance, or least-loaded, or whatever the cost function might be.
This is also the reason you can perform the same nslookup / dig
several times and get different answers or you can perform the lookup
in Poughkeepsie and get X whilst your friend in Sacramento does the
same and gets Y.
e.g.
skeptomai:~$ nslookup s3.amazonaws.com
Non-authoritative answer:
s3.amazonaws.com canonical name = s3-1.amazonaws.com.
Name: s3-1.amazonaws.com
Address: 72.21.211.129
(09:01:02 <~>) 0 $ nslookup s3.amazonaws.com
Non-authoritative answer:
s3.amazonaws.com canonical name = s3-2.amazonaws.com.
Name: s3-2.amazonaws.com
Address: 207.171.181.225
These are the results from 2 of my machines, one on the west coast of
the US and one in western Canada. These differences are the result of
a global traffic mgmt decision. (For more info, look at Level3, F5's
3DNS product, etc.)
If you do dig up more, or resort to a packet sniffer or whatever,
I'd be willing to take a look to help.
Cheers,
-Chris
.
- References:
- paging all socket geniuses
- From: Kenny
- Re: paging all socket geniuses
- From: George Neuner
- Re: paging all socket geniuses
- From: Kenny
- paging all socket geniuses
- Prev by Date: Re: Lisp based DSL for bio on Ars Technica
- Next by Date: Re: Lisp based DSL for bio on Ars Technica
- Previous by thread: Re: paging all socket geniuses
- Next by thread: Re: paging all socket geniuses
- Index(es):
Relevant Pages
|
