Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!rutgers!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.appletalk Subject: Re: Rutgers CAP - Updated again. Message-ID: Date: 30 Nov 90 05:19:13 GMT References: <1990Nov27.182401.24745@usenet.ins.cwru.edu> <1990Nov28.145303.22548@abcfd20.larc.nasa.gov> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 16 To: kludge@scb3.larc.nasa.gov If I understand correctly the way atlook works, I believe it sends a request to the nearest Appletalk router, asking the router to broadcast an NBP lookup on all networks in the zone you are asking about. Every host on such a network will then send a response directly back to your machine. This means you get lots of packets coming back all at once. My suspicion is that somehow you are unable to handle lots of packets at once. There are several possibilities. The first to check is whether the UDP socket being used by atlook is properly set up. When packets come in they are put on a queue until the program can read them. That queue has a finite size. Could be it's simply too small. I'm not sure quite how to change it. It could be a parameter when building the kernel, an ioctl, or both. Another possibility is that your system simply can't handle large numbers of packets arriving at the same time. Some of the DEC Ethernet interfaces were well known for having this problem, but the 5000 is recent enough that this wouldn't be my first thought.