![]() Data Comes To An Abrupt FINish By Bill Alderson and J. Scott Haugdahl Q: We are responsible for maintaining a mission-critical network at a major hospital and outpatient clinic. A number of times throughout the day, users--anyone requiring access to patient data--are unexpectedly kicked out of a terminal-to-host application that communicates patient information to and from a minicomputer. Needless to say, users are becoming irritated. The problem occurs on both our Windows for Workgroups and Windows95 workstations.
Scott: Perhaps the problem is in the ether, since Ethernet is servicing all the users with problems. Bill: In that case, let's just switch them to a T oken-Ring configuration. Scott: Yeah. Then we could have them take two tokens and call us in the morning. Bill: On the other hand, maybe ATM is the solution. Scott: Are you kidding? And have those cells running all over the clinic? Bill: OK...we started by looking at the network path between the client and the host. Scott: Basically, we were looking at 10BASE-T Ethernet hubs in the clinic that attached to FDDI via translational bridging. The hos t, a Digital Alpha, connected directly to the FDDI. Bill: The user's application relied on the old standby, telnet, a remote login protocol that operates over TCP. Scott: The telnet packet was sent through a router on the FDDI, which, in turn, performed protocol translation between telnet and Local Area Transport (LAT), a proprietary Digital terminal protocol. Bill: The router functioned as a gateway, communicating with users using TCP/IP and communicating with the Alpha using LAT. Scott: Users reported random application kick-outs with no apparent rhyme or reason. Bill: As we noted in one of our very first columns (see "A Whole Lot of LAT..." at techweb.cmp. com/nc/513/513colalderson.html), the LAT protocol is susceptible to network delays. Scott: We set up a second analyzer on the FDDI Ring to see if delays through the bridge, then the gateway, could be causing a problem. Bill: Analysis of traffic on both sides of the gateway showed minimal delay, so we didn't feel that LAT time-outs would be an issue. Scott: By analyzing packets on the clinic's Ethernet segment containing the most users of the ap plication in question, and having them notify us immediately upon a disconnection, we were able to catch a few disconnects--a process that took nearly two hours.
|
|
by Art WIttmann FreeWire by Bill Frezza Corporate VIew by Brian Walsh In The Middle by Bruce Robertson Updated May 23, 1997 |


Bill:
How about a diagnosis and a prescription to help with their problem?











