Path: utzoo!attcan!uunet!lts!amanda From: amanda@lts.UUCP (Amanda Walker) Newsgroups: comp.protocols.appletalk Subject: Re: Responder problems Summary: Nope, try again :-) Message-ID: <726@lts.UUCP> Date: 24 Nov 88 00:49:07 GMT References: <8811172050.AA05789@dsunx1> <21089@apple.Apple.COM> Organization: InterCon Corporation, Reston, VA Lines: 33 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