wnn@dsunx1.dsrd.ornl.gov (W. N. Naegeli) (11/18/88)
We have recently had a great deal of problems and lost many hours to detective
work until we found Apple's Responder as the culprit. Responder is an INIT
that comes with System software 6.0.2 and is intended to be used on every
networked Mac when the network administrator uses Apple's Inter*Poll software
to check on network integrity.
The problem affected Mac Plus users of NCSA Telnet 2.2 and TCP/Connect.
In most cases, when the user tried to open a connection, she or he would get
a message that Telnet (or TCP/Connect) could not connect to the host and a
second message stating that the Local host or Gateway was not responding.
If a connection was established, it was usually extremely sluggish, with long
delays until characters entered at the keyboard would be echoed, and pauses
of up to 30 seconds during the display of long text documents. Sometimes
the connection simply timed out in the middle of a session. Interestingly,
this problem was not experienced by a Mac II user on the same LocalTalk
segment as the Mac Pluses.
The "Local host or gateway not responding" message misled us. After
checking the host, restarting and finally even replacing the KFPS-3 gatway,
we finally concentrated on the AppleTalk traffic on the LocalTalk segment
and found, that the affected Macs seemed not to process the majority of
AppleTalk packets addressed to them. Finally, after removing other Apple
Talk INITs we removed Responder on one of the machines, and our TCP performance
was suddently back to normal.carr@Apple.COM (Randy Carr) (11/23/88)
In article <8811172050.AA05789@dsunx1> wnn@dsunx1.dsrd.ornl.gov (W. N. Naegeli) writes: >We have recently had a great deal of problems and lost many hours to detective >work until we found Apple's Responder as the culprit. Responder is an INIT >that comes with System software 6.0.2 and is intended to be used on every >networked Mac when the network administrator uses Apple's Inter*Poll software >to check on network integrity. > The problem affected Mac Plus users of NCSA Telnet 2.2 and TCP/Connect. >In most cases, when the user tried to open a connection, she or he would get >a message that Telnet (or TCP/Connect) could not connect to the host and a >second message stating that the Local host or Gateway was not responding. >If a connection was established, it was usually extremely sluggish, with long >delays until characters entered at the keyboard would be echoed, and pauses >of up to 30 seconds during the display of long text documents. Sometimes >the connection simply timed out in the middle of a session. Interestingly, >this problem was not experienced by a Mac II user on the same LocalTalk >segment as the Mac Pluses. > The "Local host or gateway not responding" message misled us. After >checking the host, restarting and finally even replacing the KFPS-3 gatway, >we finally concentrated on the AppleTalk traffic on the LocalTalk segment >and found, that the affected Macs seemed not to process the majority of >AppleTalk packets addressed to them. Finally, after removing other Apple >Talk INITs we removed Responder on one of the machines, and our TCP performance >was suddently back to normal. Hi, I'm the author of that troublesome little INIT known as Responder (formerly known as Snitch). Responder's job is to first look on the workstation's startup volume and determine system information & whether or not the older AppleTalk drivers are installed. An ATP socket is opened (dynamically) and if successful, that socket's number is registered onto the network with the workstation user name (from the Chooser). If the older AppleTalk drivers are present (less that driver 19) then Echo protocol is installed (Mac Plus or less usually). A single _ATPGetRequest is queued and the async completion routine only returns a single ATP packet with the desired system information in it. Responder also patches _Open & _Close so that if the AppleTalk drivers are opened or closed Responder can remove or reinstall the system info socket accordingly. It also can deal with the system doing a switch launch to another system folder so that it can truely return the correct information. I suspect that one of the Mac+'s running that specialized software is not able to open an ATP socket because too many are already opened. The mac+ can only have 6 ATP sockets open at one time, while the Mac II can have 126 [Reference: pg.V519 of Inside Mac Vol V]. Typically, mail programs and other startup style AppleTalk programs each up 1 or more sockets (as well as Responder's 1 socket) I'll bet that that TelNet & TCP/connect software is not checking to see if its own internal sockets have actually opened successfully. The program continues , but, of course, no data can actually be received (or mostly likely sent) I would try to see if there are some other programs and or INITs that can be removed w/o affecting performance/ or features desired. Good Luck... Randy Carr Network Systems Development Domain: carr@apple.com Apple Computer, Inc. UUCP: {nsc,dual,sun,voder}!apple!carr 20525 Mariani Ave. M/S 27-O AppleLink: CARR2 Cupertino, CA 95014 Opinions & Responses are my own and do NOT represent my employer...
amanda@lts.UUCP (Amanda Walker) (11/24/88)
In article <21089@apple.Apple.COM>, carr@Apple.COM (Randy Carr) writes: > Hi, I'm the author of that troublesome little INIT known as Responder Hi, I'm one of the authors of TCP/Connect. > I'll bet that that TelNet & TCP/connect software is not checking to > see if its own internal sockets have actually opened successfully. > The program continues, but, of course, no data can actually be > received (or mostly likely sent) Well, it was a good theory. However, NCSA Telnet (and TCP/Connect, which uses the same networking code) doesn't use ATP. It installs a DDP socket listener for DDP protocols 22 & 23 (IP and ARP) and does all of the rest by itself. It does indeed check to see if the listener is properly installed, and that it can open a DDP socket to use for sending & receiving packets. Nothing that could possibly interfere with Responder or vice versa, right? Grin. That's what I said, when Mr. Naegli and I were trying to work this out over the phone... However, it does at least seem to be the culprit, from what he has said to me (in summary: boot from floppy with vanilla 6.0.2, it runs fine; boot from floppy with vanilla 6.0.2+the Responder that comes with 6.0.2, it runs like molasses). I have not not been able to duplicate the problem here on our Mac Plusses (note that everything's fine on a Mac II), but I have every reason to believe that it doesn't work at ORNL. Maybe it's a local anomaly in the force of gravity or something :-). Don't ya love these kinds of problems? -- Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net InterCon, 11732 Bowman Green Drive, Reston, VA 22090 -- "The best way to predict the future is to invent it." -- N. Negroponte