HP3000-L Archives

September 1996, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Mon, 30 Sep 1996 22:17:38 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (27 lines)
gary flynn wrote:
> Our three telnet express boxes are intermitently dropping connections.
> The problem appears to be related to router CPU and/or traffic
> load. From what I've seen with a protocol analyzer, the box locks up
> and eventually sends a RST to the connecting PC which is usually running
> Reflection for Windows. Other connections are not having problems although
> things slow down somewhat. I haven't attempted to decode the proprietary
> stuff between the Telnet Express and the 3000. Does anyone know how robust
> the TCP implementation is on these boxes?

The 3000 is not very forgiving on longer timeouts, such as a congested
network or distant link; but I have no empirical evidence to support that.
If you are using Reflection's stack, it is not that robust on certain upper
layer error handling.  I did isolate one fault in WRQs stack up through
the 5.0 version (maybe later; but I reported it and it was patched) where
an ICMP redirect would close a connection (treated like an RST).  In your
case of a busy router, an ICMP source quench might cause similar quirks.

While the two (WRQ and 3000) "kick butt" on a local network, I'm not quite
so convinced of their tuning for distant connections with considerable
latency, nor slow links.  Just my own opinion and "feel" about it; again,
no empirical evidence other than the documented ICMP redirect quirk (by
the RFC definitions they should be treated as a transient error and the
packet retried, not reset the connection).

Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2