Re: lynx-dev partial not working on ftp:// url's (?)

[Kim DeVaughn]

On Wed, Jul 21, 1999, Klaus Weide (address@hidden) said:
|
| > | What if that 2nd key is something else than ^G - like 'z' or '^L' or
| > | down arrow?
| >
| > They have no effect (other than say, ^Z, which does the expected thing,
| > which BTW after fg'ing back to the lynx process, returns to the same
| > "state" ... blank screen, except for the now static xfer counter in the
| > statusline position).
| >
| > Only a ^G at that point will initiate the on-screen rendering (with either
| > "z" or ^G used to interrupt the xfer itself).
|
| You should be able to substitute 'z' for either or both of the ^G's.
| Are you *really* sure this isn't the case? :)

Heh.  Guess I missed trying a "z" as the 2nd key (though I thought I had).

Indeed, it ("z") *does* clear the "hang" condition, and allows the rendering
of the (interrupted) xfer to proceed.

So you're quite right ... "z" and ^G are equivalent, in that situation.


| > Well "partial" is defaulted to normally on, and adding "-partial" to the
| > command line should toggle it off, I believe.  I get the same results
| > with or w/o "-partial".
|
| Yes, it should be a toggle, but -partial=off should now work (as for other
| toggles) to force it off.

And it (partial) makes no difference, either on or off.


| > Haven't tried a build with "partial" compiled out (nor with NSL disabled,
| > for that matter).  A couple things to try and isolate the behavior(s), I
| > suppose ... maybe later on today ...
|
| I can't imagine how NSL_FORK would play a role here, since everything is
| happening long after the name lookup.

I didn't look at the code ... I just thought the "z" command, and NSL_FORK
were "coupled".


| > | If not, it may have something to do with the following (end of
| > | read_directory in HTFTP.c):
| >
| > | Maybe 'the response(NIL) below hangs' is true not only for those
| > | server types, but also for others.  I added that NETCLOSE a long
| > | time ago, when testing with those weird servers seemed to show
| > | that they needed it, but didn't add it for cases I didn't know
| > | about.  It should probably also be done if WasInterrupted is true
| > | at that point (please test, I don't want to start loading
| > | multimegabyte directory listings now..).

| Your trace looks entirely consistent with it.  (The first interruption
| should be visible [if it leaves any trace in TRACE] much earlier in
| the log, before the text and anchor dumps.)

Hmmm.  I couldn't find anything explicit for it (the 1st interruption) in
the log.  Specifically, there's no indication where it switches from the
ctrace lines like:

 >HTFTP: Line in alt is -rw-rw-r--   1 88       8            841 Mar 20  1996 
 >alt.aus.bonehead.jimo-ngygook.bulletsdtopper.poofter.Z
 >Adding file to BTree: alt.aus.bonehead.jimo-ngygook.bulletsdtopper.poofter.Z

over to lines like:

 >GridText: Change to style Preformatted
 >GridText: split_line(0 [now:19]) called
 >HTML:begin_element[0]: adding style to stack - Preformatted
 >new Anchor 0x17d460 named `' is child of 0x156400
 >Entered HTAnchor_findChildAndLink
 >HTParse: aName:alt/alt.*.Z   relatedName:ftp://ftp.isc.org/usenet/control/alt 
 >>2
 >HTParse:      result:ftp://ftp.isc.org/usenet/control/alt/alt.*.Z
 >HTParse: aName:ftp://ftp.isc.org/usenet/control/alt/alt.*.Z   relatedName:
 >HTParse:      result:
 >Entered HTAnchor_findAddress
 >New anchor 0x156f00 has hash 33 and address 
 >`ftp://ftp.isc.org/usenet/control/alt/alt.*.Z'
 >Linking anchor 0x17d460 to anchor 0x156f00
 >HText_endAnchor: number:2 link_type:1

or from those, to lines like:

 >HText_endAnchor: number:912 link_type:1
 >GridText: split_line(0 [now:70]) called
 >HTML:end_element[0]: Popped style off stack - Normal
 >GridText: Change to style Normal
 >GridText: split_line(0 [now:0]) called
 >Gridtext: Entering HText_endAppend
 >GridText: split_line(0 [now:0]) called
 >GridText: Removing bottom blank line:
 >GridText: New bottom line:
 >GridText: Removing bottom blank line:
 >GridText: New bottom line:
 >GridText: Removing bottom blank line:
 >GridText: New bottom line: Aug 30  1997  UNIX Compressed  
 >[912]^Ealt.<EF><AE>$.<A9>h<FC><AE><A9>h.<F8>m<F8>L<EB><FF><A9><AE><FC><EB>.Z^F
 >  2Kb
 >Gridtext: Entering HText_trimHightext (final)
 >Gridtext: Anchor found on line:3 col:3 [1] ext:15
 >anchor text: '[1]^EUp to control^F'
 >GridText:     add link on line 3 col 6 [1] in HText_trimHightext
 >Gridtext: Anchor found on line:4 col:34 [2] ext:9
 >anchor text: 'Oct  8  1997  UNIX Compressed  [2]^Ealt.*.Z^F  1Kb'
 >GridText:     add link on line 4 col 34 [2] in HText_trimHightext

which are the lind of lines that the trace ends with (when the 1st ^G/z has
been issued (but before the 2nd such cmd is issued).


| In fact, after thinking about it more, it seems more obvious to me now
| that this is exactly what has to happen.  We haven't closed the data
| socket at that point, we just stopped reading from it.  So the remote
| side just sees a stalled data connection if there are more outstanding
| data we haven't read than would fill up TCP windows and buffers.  So
| it just waits to be allowed to send more data.  But we're not opening
| the window for that, instead we wait for someting to happen on the
| control socket, so we have deadlock.
|
| The only things that don't fit are
|  1.) 'z' doesn't do the same as ^G.
|      If you canfirm that, it might be some kind of slang thing.

Nope, they do the same thing (see above).


|  2.) you think it has no sockets open (but you are not sure).
|      I think there should be two open.

Seems like it (per fstat(1) after the 1st ^G/z):

 >USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
 >kimdv    lynx        1735   wd /users/u2 445445 drwx------    2560  r
 >kimdv    lynx        1735 text /users/u2 361549 -rwxr-xr-x  466128  r
 >kimdv    lynx        1735    0 /         16113 crw-------   ttyP5 rw
 >kimdv    lynx        1735    1 /         16113 crw-------   ttyP5 rw
 >kimdv    lynx        1735    2 /         16113 crw-------   ttyP5 rw
 >kimdv    lynx        1735    3* internet stream tcp f3605100
 >kimdv    lynx        1735    4* internet stream tcp f32d3400
 >kimdv    lynx        1735    5* internet stream tcp f3ec4300

whereas, after the 2nd ^G/z, we get:

 >USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
 >kimdv    lynx        1735   wd /users/u2 445445 drwx------    2560  r
 >kimdv    lynx        1735 text /users/u2 361549 -rwxr-xr-x  466128  r
 >kimdv    lynx        1735    0 /         16113 crw-------   ttyP5 rw
 >kimdv    lynx        1735    1 /         16113 crw-------   ttyP5 rw
 >kimdv    lynx        1735    2 /         16113 crw-------   ttyP5 rw
 >kimdv    lynx        1735    4* internet stream tcp f32d3400

Though again, netstat(1) shows no sockets related to "isc.org", my uid,
or lynx's pid.


In summary, your analysis seems to be correct (as usual) ...

/kim