[Tinyos-devel] DisseminationEngineImplP.nc , sendObject function

[Marcin Szczodrak]

Yes, sending message with DISSEMINATION_SEQNO_UNKNOWN allows node to
get updates quickly. I guess depending on the application, there is a
trade off between how quickly a node can join a network, and the
energy that can be wasted during the network's boot up, when the
dissemination process is delayed. I happened to need to postpone the
dissemination of the first message to insure that all nodes in the
network have booted. In this situation, depending how long is the
delay, booted nodes broadcast DISSEMINATION_SEQNO_UNKNOWN messages
until the first dissemination message arrives.

Marcin



On Wed, May 6, 2009 at 2:20 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On May 4, 2009, at 4:59 PM, Marcin Szczodrak wrote:
>
>> Hi All,
>>
>> I was working on the Drip protocol and found something that may be a bug.
>> In tinyos-2.1.0/tos/lib/net/drip/DisseminationEngineImplP.nc  ,
>> function sendObject sends empty messages with sequence number equal to
>> DISSEMINATION_SEQNO_UNKNOWN, as result
>> of Trickle's Timer being fired. However, these messages have been not
>> initialized for dissemination by the application, and I guess they
>> should not be disseminated. They simply waste energy. The problematic
>> lines are the 149-152 , of the original version of code pasted below.
>> I would like suggest to change them as in the modified version of the
>> pasted code in lines 149-155. This will avoid sending empty messages.
>>
>> -Marcin
>>
>> // ORIGINAL
>> 130   void sendObject( uint16_t key ) {
>> 131     void* object;
>> 132     uint8_t objectSize = 0;
>> 133
>> 134     dissemination_message_t* dMsg =
>> 135       (dissemination_message_t*) call AMSend.getPayload(
>> &m_buf,sizeof(dissemination_message_t) );
>> 136     if (dMsg != NULL) {
>> 137       m_bufBusy = TRUE;
>> 138
>> 139       dMsg->key = key;
>> 140       dMsg->seqno = call DisseminationCache.requestSeqno[ key ]();
>> 141
>> 142       if ( dMsg->seqno != DISSEMINATION_SEQNO_UNKNOWN ) {
>> 143         object = call DisseminationCache.requestData[ key ](
>> &objectSize );
>> 144         if ((objectSize + sizeof(dissemination_message_t)) >
>> 145             call AMSend.maxPayloadLength()) {
>> 146           objectSize = call AMSend.maxPayloadLength() -
>> sizeof(dissemination_message_t);
>> 147         }
>> 148         memcpy( dMsg->data, object, objectSize );
>> 149       }
>> 150       call AMSend.send( AM_BROADCAST_ADDR,
>> 151                         &m_buf, sizeof( dissemination_message_t )
>> + objectSize );
>> 152     }
>> 153   }
>>
>>
>> // MODIFIED
>> 130   void sendObject( uint16_t key ) {
>> 131     void* object;
>> 132     uint8_t objectSize = 0;
>> 133
>> 134     dissemination_message_t* dMsg =
>> 135       (dissemination_message_t*) call AMSend.getPayload( &m_buf,
>> sizeof(dissemination_message_t) );
>> 136     if (dMsg != NULL) {
>> 137       m_bufBusy = TRUE;
>> 138
>> 139       dMsg->key = key;
>> 140       dMsg->seqno = call DisseminationCache.requestSeqno[ key ]();
>> 141
>> 142       if ( dMsg->seqno != DISSEMINATION_SEQNO_UNKNOWN ) {
>> 143         object = call DisseminationCache.requestData[ key ](
>> &objectSize );
>> 144         if ((objectSize + sizeof(dissemination_message_t)) >
>> 145             call AMSend.maxPayloadLength()) {
>> 146           objectSize = call AMSend.maxPayloadLength() -
>> sizeof(dissemination_message_t);
>> 147         }
>> 148         memcpy( dMsg->data, object, objectSize );
>> 149
>> 150         call AMSend.send( AM_BROADCAST_ADDR,
>> 151                           &m_buf, sizeof( dissemination_message_t)
>> + objectSize );
>> 152       } else {
>> 153         m_bufBusy = FALSE;
>> 154       }
>> 155     }
>> 156   }
>>
>
> I checked this by Gil Tolle, who wrote the component. The SEQNO_UNKNOWN is
> so that, when a node first boots, it can quickly get updates from its
> neighbors. Otherwise, it will have to wait for a neighbor to advertise a
> newer version number and value. SEQNO_UNKNOWN allows a node to reset the
> Trickle timers of its neighbors.
>
> So I don't think it's a bug.
>
> Phil
>