X-no-Archive:yes
We purchased an application, with source code for all but the 'middleware',
that was designed to run on top of a telnet session (not NS/VT), with the
client component 'screen-scraping' the data while attempting to emulate a
terminal (not an approach that I can recommend, IMO). We could reliably see
hangs with a small number of users on the far side of our customer's WAN,
and quickly and easily reproduce the problem under a well-defined set of
conditions (which included high-traffic business hours. We never got this
failure to occur after 5PM, in spite of trying).

One of our network engineers asked me if I could in any way have the host
application 'log' what it was 'displaying' to this pseudo-terminal, which I
could, and did. We found that the application would write single char ACKs,
and given enough users under these well-defined conditions, one of these
would fail to appear on the (Token Ring) LAN, which is to say its packet did
not showed up in a trace on the host's local segment. HP also performed a
link trace on the NIC itself, but I would have to check my notes to be sure
of the results of that. The client should have issued an ENQ when it did not
see an ACK or NAK within its timeout, but it did not. Had it done so, it
would have almost certainly recovered. HP allowed us access to a beta patch
for telnet, that very quickly went General Release. This patch relieved this
failure.

The behavior that you describe sounds like you may have more than one
problem, since the symptoms vary. Your situation is very much complicated by
having multiple WAN connections, both Ethernet and Token Ring, and frame
relay over Cisco routers in this mix. The only difference I see between your
network situation and ours is that our LAN connected to a WAN, to connect
thru the customer's firewall to their nationwide WAN. We had only the one
customer, not multiple sites. I asked TR users on this list to send me notes
on their experience, and no one else reported problems with TR itself,
apparently exonerating HP's implementation of it. Our customer did later
install a new firewall, and migrate us over to it, which greatly improved
our ftp times, so their older firewall was not helping things.

HTH. Feel free to contact me with any questions you have on this.

Gregory Stigers
978-946-3186
Senior Consultant
CGI Information Systems and Management Consultants, Inc.
http://www.cgiusa.com