Odd Intermittent Browser "Cannot Connect" to Sakai

Question

Hello All,
This one has really stumped the professor...
In short, the problem is that there is one site hosting Sakai for the Oregon Health and Science University (OHSU) that I, and only I, have intermittent problems connecting to. By that I mean, just me out of hundreds of people currently, and thousands of people over history.
The host is http://www.longsight.com/ and the system is Sakai.
I am using an Airport Simultaneous Dual-Band 7.5.2, an iMac and Macbook Pro both using 10.6.7, Earthlink as the ISP using PPPoE, and a ZyXEL P-600 Series DSL modem, and FireFox 4.0.
Everything has worked without a hitch for years. The only website I have issue with is sakai.ohsu.edu, hosted by LongSight.
The intermittent problem is that FireFox reports it cannot connect to the site when I navigate. When I refresh, it seems to usually refresh fine.
Same problem with Safari and Chrome.
Same problem with both the iMac and the MacBook Pro.
Same problem with an Ethernet cable connected directly to the back of the Airport to either.
Does not seem to be a problem with the modem connected directly to either computer (intermittent, remember, so I am not 100% certain, but I have not gotten it to happen).
The LongSite host provider sees nothing odd in the logs.
If I click the Try Again that FireFox puts up, I get logged out of Sakai and have to log back in. If I instead just refresh in FireFox, the page seems to load.
Q: Is there a "tolerance" setting that would prevent this problem from happening?
Q: Is there anything to ask the host to do? Setting to check?

Answer 1

When its just one web page - you can access other web pages like Google or Apple - the problem is the Intenet connection between you and the server hosting the web page you want.
Nothing to do with your local equipment or connection.  There are local settings you could set or have changed that would prevent connecting to a specific web site, I'm going to assume that is not the case since you don't mention fiddling with the HOSTS file (for example).
If the server that hosts that page is not "down" or over-loaded then the problem most likley lies with your ISP's network.
To try and get a glimmer of what is wrong, open your Applications/Utilities folder and run "Network Utility".  Click on the TRACEROUTE tab and enter the host name for the page you want.
For example, the Sakai page address is "http://www.longsight.com/longsight/sakai".  The name of the server hosting that page is "www.longsight.com".  I put that into the TRACEROUTE field, and press the TRACE button.
What happens next is your computer attempts to figure out exaclty HOW all data between you and the target server are exchanged.  The internet is like a spider web, and at each junction there is a computer that handles (aka routes) traffic.
For your web page attempts to work, you need a reliable "route" to the server that hosts the web page you want.  This utility will generate a list of all the internet nodes and networks your request has to travel through.  The list should end with the target server in under 15-20 "hops".  If the list is much longer - or if it keeps going and going - then you have a DNS routing problem.  Or rather, your ISP has one.
Because the Internet is flexible, extensible, and self-healiing routing problems should go away on their own - it might take a day or two.  But shoddy maintenance or configuration of network equipment can create routing problems that don't go away until fixed.
Another problem I have seen is intentional filtering or mis-directing of requests from a certain provider or geropgrahic region.  For example, a NYC based company offered a contest only for local residents, so they had thier ISP filter-out all connection attempts coming from outside of NYC.  Very sneaky.
Another example would be companies trying to prevent access to Facebook.  They setup their network to drop any requests for that name or address - or re-direct to a corporate Internet use policy web page!
For reference, here is my TRACEROUTE report for this server:
Traceroute has started…
traceroute to www.longsight.com (209.190.181.136), 64 hops max, 72 byte packets
1  10.0.0.1 (10.0.0.1)  3.008 ms  0.910 ms  1.164 ms
2  66.49.188.255 (66.49.188.255)  13.472 ms  13.399 ms  14.625 ms
3  66.49.255.169 (66.49.255.169)  43.865 ms  12.877 ms  14.013 ms
4  77.67.108.113 (77.67.108.113)  28.436 ms  25.109 ms  15.116 ms
5  xe-4-3-0.nyc32.ip4.tinet.net (89.149.184.221)  35.873 ms  37.201 ms  36.777 ms
6  te9-4-10g.ar8.nyc1.gblx.net (64.212.107.181)  41.319 ms  36.820 ms  37.815 ms
7  continental-broadband.te6-2.ar5.chi1.gblx.net (207.138.128.70)  52.947 ms  50.436 ms  49.692 ms
8  v4006.cr2.350ec.chcgil.e-xpedient.com (216.130.11.134)  55.085 ms  54.699 ms  69.256 ms
9  v4005.cr1.strlng.clevoh.e-xpedient.com (216.130.11.130)  69.360 ms  79.594 ms  66.697 ms
10  v4008.cs1.neoprk.clevoh.e-xpedient.com (216.130.12.194)  66.474 ms  66.767 ms  68.681 ms
11  server17.longsightgroup.com (209.190.181.136)  66.319 ms  91.287 ms  68.452 ms
As you can see, my route to the server is only 11 hops.
Another test is PING:
Ping has started…
PING www.longsight.com (209.190.181.136): 56 data bytes
64 bytes from 209.190.181.136: icmp_seq=0 ttl=49 time=67.923 ms
64 bytes from 209.190.181.136: icmp_seq=1 ttl=49 time=66.202 ms
64 bytes from 209.190.181.136: icmp_seq=2 ttl=49 time=69.237 ms
64 bytes from 209.190.181.136: icmp_seq=3 ttl=49 time=68.239 ms
64 bytes from 209.190.181.136: icmp_seq=4 ttl=49 time=66.509 ms
64 bytes from 209.190.181.136: icmp_seq=5 ttl=49 time=68.771 ms
64 bytes from 209.190.181.136: icmp_seq=6 ttl=49 time=68.318 ms
64 bytes from 209.190.181.136: icmp_seq=7 ttl=49 time=67.339 ms
64 bytes from 209.190.181.136: icmp_seq=8 ttl=49 time=68.175 ms
64 bytes from 209.190.181.136: icmp_seq=9 ttl=49 time=68.549 ms
--- www.longsight.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 66.202/67.926/69.237/0.920 ms
PING shows that it takes less than 70 milli-seconds for my computer to talk to the server hosting that page.  That is very fast.  If you get very large (>5000 ms) PING times then there is a good chance your web browser will "give up" before the data comes back.
In such cases, what your doing (press REFRESH or otherwise try again) is the best wqy to recover.