lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Re: LYNX_DEV connection problems


From: Robert Bonomi
Subject: Re: LYNX-DEV Re: LYNX_DEV connection problems
Date: Sat, 30 Aug 1997 02:30:59 -0500 (CDT)

+ Date: Fri, 29 Aug 1997 08:45:53 -0500 (EST)
+ From: Foteos Macrides <address@hidden>
+ Subject: LYNX-DEV Re: LYNX_DEV connection problems
+ 
+ Laura Eaves <address@hidden> wrote:
+ >> From: Russell McOrmond <address@hidden>
+ >> Date: Thu, 28 Aug 1997 10:48:26 -0400 (EDT)
+ >>...
+ >>   Is there certain times of the day that it is worse than normal?  I 
+ >> notice that your provider is on the other side of some fairly busy 
+ >> networks from myself (flora.org) and thus it might just be things timing 
+ >> out that is the problem.
+ >
+ >I thought of that, but it doesn't time out; it fails immediately.
+ >I don't know the reason as intermediate statusline messages are overwritten.
+ 
+       It happens immediately, and not on subsequent attempts, and not in
+ TRACE mode.  I can get the same effect for http://lynx.browser.org/ (and
+ users don't get a second chance if that's their startfile).  It happens
+ (not often enough to track down) for VMS and all of my Unix guest accounts,
+ which are in different places across the US.  Very strange, and presumeably
+ associated with the DNS code.  It doen't matter whether NSL_FORK has been
+ defined.

This kind of thing is symptomatic of a 'caching' DNS server (that has tried
*once* to resolve a name, and _recorded_ the 'failure' to resolve in the cache),
*OR* of a router with insufficient memory for all 'routing table' information,
coupled with a *busy* circuit on the 'outside' side of said router (basically 
the router's attempt to query its 'neighbors' as to "do any of you know how to 
get stuff to this address"  gets clobbered -- dropped packets, and/or timeout).

One way to 'see' those "over-written"  intermediate status messages is to
use a terminal emulator that _logs_ *all* output, or to invoke a logging
capability (e.g. "script", on a UNIX system) from the command-line, before 
starting lynx.  Then (again, in a UNIX environment)  run 'strings' (or some
other utility -- e.g., 'od' -- that will 'translate' or suppress the terminal-
control sequences in the captured file) on the generated log.


<grin type=wry>
yeah, I've spent a *lot* of time, over the years, debugging apps where the 
error messages went by 'too fast to read'.
</grin>

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]