Subject: [Nsis-imp] RE: [NSIS] Some small errors

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 4 Jul 2006 10:19:15 +0100

hi bo,

sorry for the delayed reply (this mail got stuck in a small
black hole for a while). see below:

> -----Original Message-----
> From: bogao [mailto:[email-masked]] 
> Sent: 01 June 2006 19:27
> To: Hancock, Robert
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Some small errors
> 
> 
> Hello, Robert,
>  From a implementor's point of view, if the NSLP calls the 
> RecvMessage 
> and it also has determined that peer association should be setup, how 
> can it let the NTLP know that peer association is needed? You have 
> mentioned that "its reaction determines whether peering takes place". 
> How can it react with NTLP about this?

the discussion is in B.2 of the spec (the paragraphs under 
'Routing-State-Check'). it's slightly abstract in that 
it is phrased in terms of a primitive RecvMessage going *from*
GIST *to* the NSLP, in which case the boolean and NSLP payload
mentioned in the discussion of the Routing-State-Check argument
go *from* the NSLP *to* GIST. and this is the interaction you
are looking for.

>  The service interface between the NSLP and NTLP is really 
> confusing me. 
> Do you have any recommendation about how to implement the 
> service interface?

i think this is an exercise for the skill and judgement of the
implementor; we purposely kept it abstract in the specification.
the Goettingen people have concrete version based on passing
messages over a pipe, and we have also defined one in C using 
a mixture of downcalls and registered callbacks. but really it
is up to you.

robert h.

> I am working on the implementation now 
> (http://www.cs.concordia.ca/~gao_b/thesis) and have finished 
> the timer 
> based on the TCP timer of Comer<<Interworking with TCP/IP>>. 
> It is very 
> interesting!
> 
> Have a nice day!
> 
> Hancock, Robert wrote:
> 
> >>Also I have a question about the local processing, How could the 
> >>signaling application indicate  it wishes to become a 
> signaling peer 
> >>with the Querying node? I checked the service interface 
> between GIST 
> >>and NSLP, I couldn't figure out if it is a functionality of the 
> >>SendMessage or a functionality of RecvMessage. Is the parameter " 
> >>Transfer-Attribute " in the ReceMessage a in-out parameter?
> >>    
> >>
> >
> >this is handled in the RecvMessage primitive: when a Query 
> is received
> >the NSLP gets a RecvMessage, and its reaction determines 
> whether peering
> >takes place and the payload in the Response. See the 
> discussion of the
> >Routing-State-Check argument to RecvMessage in B.2 (and references
> >therein).
> >
> >cheers,
> >
> >r.
> >
> >  
> >
> >>Sincerely
> >>
> >>Bo Gao
> >>E-mail: [email-masked]
> >>Web: http://www.cs.concordia.ca/~gao_b
> >>
> >>
> >>
> >>_______________________________________________
> >>nsis mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/nsis
> >>
> >>    
> >>
> 
> 

_______________________________________________
NSIS-imp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis-imp

---

From: bogao <[email-masked]>
Date: Mon, 10 Jul 2006 09:44:51 -0400

Hi,Roberts,
Thanks a lot for clarification.  I am using the named fifos for the 
service interface as I treat NSLP and NTLP as two separated precesses.

Have a nice day!
Best Regards,
Bo