Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!cbosgd!ulysses!ucbvax!daveg.UUCP@seismo.css.gov@dartvax.UUCP
From: daveg.UUCP@seismo.css.gov@dartvax.UUCP
Newsgroups: mod.protocols.appletalk
Subject: Submission for mod-protocols-appletalk
Message-ID: <8703110255.AA15314@dartmouth.EDU>
Date: Tue, 10-Mar-87 21:55:55 EST
Article-I.D.: dartmout.8703110255.AA15314
Posted: Tue Mar 10 21:55:55 1987
Date-Received: Thu, 12-Mar-87 22:42:31 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 56
Approved: info-applebus@c.cs.cmu.edu

Path: dartvax!daveg
From: daveg@dartvax.UUCP (Dave Green)
Newsgroups: mod.protocols.appletalk
Subject: lsp name binding problem
Message-ID: <5808@dartvax.UUCP>
Date: 11 Mar 87 02:55:55 GMT
Reply-To: daveg@dartvax.UUCP (Dave Green)
Distribution: usa
Organization: Dartmouth College, Hanover, NH
Lines: 46

Newsgroups: mod.protocols.appletalk
Subject: lsp name-binding error
Expires: 
References: 
Sender: 
Reply-To: daveg@dartvax.UUCP (Dave Green)
Followup-To: 
Distribution: usa
Organization: Dartmouth College, Hanover, NH
Keywords: 

Hi there,
  I have been having some mysterius errors occur while using 
lightspeed pascal and the appltalk interface.  I open a socket
with ATPopenSocket.  Register with NBPRegister, and then
as for a request with ATPGetRequest.  At the same time,  I have
another mac doing NBPLookup for the applebus in question.
   The trouble arises when I try and use the address and 
entityName returned by the lookup/extract combination.  The 
searching macintosh finds the original with the correct 
EntityName, net number,  and node number,  but gives me a 
socket value of one no matter what I do.  i have had a few
people with appletalk experience look at the code and they 
seem to think it is legit.  Does anyone know what type of 
mistake I could be making to get the lookup to return a socket
value of one no mater what the actual value of an entities
socket is?  I am mystified.
  Upon looking at the data flow on the bus with peek,  I find
that the original register is working fine,  but when the
global lookup is done by the second mac,  the first does 
actually reply with a packet that implies that it resides 
at socket one.  First of all,  what is socket one ( I think it
is something special isn't it?)?  Second,  why would this darn
blasted thing always report that it is sitting in socket one no
matter if it is in 187, 96, or 254?  I am getting frustrated.
any help from the net would be greatly appreciated as this 
project is due in three days and is fairly important to me.

					Dave Green
					Dartmouth College

daveg@dartvax.UUCP
daveg@dartmouth.EDU
daveg@dartcms1.Bitnet
daveg%dartvax@CSNET