On Tue, 6 Feb 1996 09:06:38 -0600 Susan McClure said:
On Feb 5,  2:11pm, Brett Walker (408)256-0265 wrote:
Subject: Re: ANS4017E Session rejected: TCP/IP communications failure
>> One other thing that you could try would be to reduce the size of
>> the TCPWindowsize and TCPBuffsize parameters.  In our quest for
>performance
>> we tend to bump these values up to their maximum, but on some networks
>this
>> may be detrimental.
>> Just a thought ;-)
>> Brett Walker
>> ADSM Development
>>-- End of excerpt from Brett Walker (408)256-0265

I have this seen this problem but, only with Macs and then specifically
Macs connected via Appletalk.  I've filed them into a general hole I
have with Appletalk connected Macs period though.  I see ANR0480W,
just while quiting ADSM normally, I've got more than a dozen Macs that
always seem to have protocol violations or just timeout during
schedule backups and I've already set COMMTIMEOUT to 15 minutes.
The Macs are random though, sometimes it's this one for a few weeks
then it moves to another so I'm conviced that it's not a cable problem,
the Macs aren't being moved and sometimes it's more of them failing
and sometimes less.


The problem is always just with Appletalk Macs though and
TCPWindowsize and TCPBuffsize are set at 1 and 2 and slowincremental
is on on all the Macs.  My opinion was always that the local (and much
antiquated FastPaths) were just overloaded trying to keep up with the
traffic and dropped packets that weren't recovered.  Telecomm though
states that there just isn't that much traffic compared to the day and
I've seen the numbers but, they only poll every 5 minutes and I suspect
is has much to do with momentary slams of data.  We never have a
protocol or timeout problem when backups are run manually, just the
occasional ANR0480W but, scheduled backups die consistantly.  I've tried
running tracing just to get a better feel for the problem but, the Macs
work consistantly with tracing enabled and go right back to failing
when it's turned off.  Much bummer there.

The Fastpaths actually show an amazing small number of errors though
and even though ADSM is running at the application level I've always
wondered if it was just a bit light or perhaps relying overly on the
data layer to take care of transfers and not bothering to
re-check/re-try connection status before giving up on a connection
or when receiving data that results in a protocol failure and just
shutting the connection down rather than rolling the transaction
backwards and retrying.  I'm sure the client is performing fine and
see the problem definitely as a server relate one.  One day when I'm
really bored I'll dump all the data packets on one of these Appletalk
Macs and see what's going on but, I doubt I'll have the deal with
it anytime soon.

---
Keith A. Crabb         Keith AT UH DOT EDU
Keith A. Crabb         Keith AT UH DOT EDU
University of Houston  Operating Systems Specialist +1-713-743-1530