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

From: bogao <[email-masked]>
Date: Thu, 01 Jun 2006 14:26:58 -0400

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: [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: Bernd Schloer <[email-masked]>
Date: Thu, 29 Jun 2006 22:13:18 +0200

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