🚀 go-pugleaf

In article <1861@gazette.bcm.tmc.edu>, klong@wilkins.bcm.tmc.edu (Kevin Long) writes:
> Our experience with the NetSerial has been mixed, and I'd like to ask if
> anyone else has the problems we've had.

> People can call up from home and print small files to printers, etc, with
> no problem.  But if we equip the home machine with TOPS and try to mount
> a volume at the office or use ncsa telnet to pull a file off of one of
> our unix hosts gatewayed through the office network's fastpath, the 
> connection is inevitably dropped, sometimes after 5 minutes, sometimes 
> after 10. 

I've had people with similar problems with other serial link hardware
and software, specifically running one of the electronic mail
packages. They find that short messages are fine, but long ones die.
How long is long? About 2000 characters or so. The following from 2
months ago gives a good explanation of a possible reason: Note that
this addresses AppleShare, but applies to all programs that use
AppleTalk's Transaction Protocol (ATP) - this is most of them. Note
(for explanation) that a BIG data request on ATP looks like:

Req. Device:	[Request]
Rsp. Device:	         [RSP1] [RSP2] [3] [4] [5] [6] [7] [8]

so there are from 1 to 8 response packets (568 bytes each). This
depends on how much data was asked for. Anyway, the article:

> Date: 17 Oct 89 03:32:00 GMT
> Sender: daemon@ucbvax.BERKELEY.EDU
> Organization: The Internet
> Lines: 28

Does anyone have a fix for this piece of Apple stupidity?

Externally it appears that the AppleShare code uses the following
retransmission scheme:

During the server signon the user MAC sends a full size echo packet and
records the elapsed time until the reply. This time is then 2 times the
one way packet time.

It doubles this and uses that as the ATP timeout time. It is now 4 times
the one way packet time.

It then sends an 8 packet ATP request with a 4 packet time timeout. Guess
what happens. While the 5th packet is coming in it asks for a resend of
the last 4 packets.

Now things really go to H... in a Handbasket. It uses the first copy of the
last 4 packets and requests the next group of 8. Those 8 end up behind the
second copy of the last 4 packets. Timeout, Timeout, Timeout ...

We informed Apple of this problem over two years ago. To err is human but
not to be able fix one's mistakes is stupidity.

Does anyone know where the 2 is that is used for the doubling? I would like
to change to about 8.

PS. Many thanks to Jim Bruyn, Computer Systems Group, University of
Waterloo for the ResEdit location of the Broadcast retry interval.

---------

Other articles that followed this said where the "2" is and how to
patch it. Do Shiva give you in INIT or something to drop in your
System folder to patch these numbers for you?

			    ---------
Tom Evans  tom@wcc.oz.au        |
Webster Computer Corp P/L       | "The concept of my
1270 Ferntree Gully Rd          |  existence is an
Scoresby, Melbourne 3179        |  approximation"
Victoria, Australia             |
61-3-764-1100  FAX ...764-1179  |      D. Conway

2109 O'Toole Avenue, Suite J
SAN JOSE CA 95131 - 1303 CALIFORNIA
1-408-954-8054  FAX 1-408-954-1832