Re: [Nsis-imp] Re: [NSIS] Some small errors

[Bernd Schloer <bschloer at cs.uni-goettingen.de>]

Hi,

the timer code from your site is really interesting.

You create two threads, both are looping forever, and a pipe as IPC between 
them. The thread_timer() is suspended by usleep() for the given timeout value 
and after some time has elapsed a linked list is searched for corresponding 
events. These events are written into the pipe.

On the other side of the pipe a read call receives the events. When accessing 
the linked list, it is locked for other threads. The timeout trigger is created 
 neither with a signal nor using select().

When the pipe is empty, the read() blocks. But this filedescriptor can also be 
handled by select(). Compared to a single-threaded timer-function this might be 
a bit slower, as you have the context-switches between the threads and 
reading/writing from/to a pipe takes also some time.

Bernd





bogao wrote:
> 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 service interface between the NSLP and NTLP is really confusing me. 
> Do you have any recommendation about how to implement the service 
> interface?
> 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: gao_b at cs.concordia.ca
> > > Web: http://www.cs.concordia.ca/~gao_b
> > >
> > >
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > >
> > >   
>
>
>
> _______________________________________________
> NSIS-imp mailing list
> NSIS-imp at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis-imp

_______________________________________________
NSIS-imp mailing list
NSIS-imp at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/nsis-imp