[Tinyos-beta-commits] CVS: tinyos-1.x/beta/Drip DripM.nc, 1.1, 1.2 README.txt, 1.2, 1.3

[Gilman Tolle]

Update of /cvsroot/tinyos/tinyos-1.x/beta/Drip
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11947

Modified Files:
	DripM.nc README.txt 
Log Message:
updated readme, took out old log commands

Index: DripM.nc
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/Drip/DripM.nc,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** DripM.nc	19 Jan 2005 00:01:17 -0000	1.1
--- DripM.nc	17 Feb 2005 01:12:20 -0000	1.2
***************
*** 171,175 ****
        dripMsg->metadata.seqno = 
  	call DripState.getSeqno[dripMsg->metadata.id]();
!       
        retMsg = signal Receive.receive[dripMsg->metadata.id]
  	(pMsg, dripMsg->data, pMsg->length - offsetof(DripMsg,data));
--- 171,175 ----
        dripMsg->metadata.seqno = 
  	call DripState.getSeqno[dripMsg->metadata.id]();
! 
        retMsg = signal Receive.receive[dripMsg->metadata.id]
  	(pMsg, dripMsg->data, pMsg->length - offsetof(DripMsg,data));

Index: README.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/Drip/README.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** README.txt	15 Feb 2005 06:47:13 -0000	1.2
--- README.txt	17 Feb 2005 01:12:20 -0000	1.3
***************
*** 1,14 ****
  Drip is a transport-layer component for epidemically disseminating
! messages throughout a network. Each message "channel" uses a sequence
! number and retransmissions to ensure that every node eventually gets
! the newest message sent on that channel. Neighborhood suppression is
! also present, to prevent the dissemination from overwhelming the
! network.
  
  Programming With Drip:
  
  Drip provides two interfaces: Receive and Drip. To maintain its
! per-channel metadata, it uses a third interface: DripState. Wire to
! them like this:
  
    TestDripM.ReceiveDrip -> DripC.Receive[AM_TESTDRIPMSG];
--- 1,33 ----
  Drip is a transport-layer component for epidemically disseminating
! messages throughout a network.
! 
! Why Drip is better than Bcast:
! 
! - Epidemic reliable delivery. After sending a message, Drip will
!   continually retransmit to ensure that it eventually reaches every
!   node in the network.
! 
! - Neighborhood Suppression: If a node transmits, its neighbors will
!   delay their own transmissions. This means that fewer messages will
!   be sent, as compared to Bcast.
! 
! - Trickle timers: Each time a node retransmits, it waits double the
!   amount of time until it retransmits again. This ensures that traffic
!   eventually drops down to a low base rate, while still maintaining
!   epidemic reliability. A new message kicks the transmit rate back up,
!   for fast dissemination.
! 
! - Transport layer: With Drip, the identifiers you use for Drip
!   messages are nested within the Drip header. This means you can only
!   collide identifiers with other Drip messages. With Bcast, you have
!   to place your message AM id within the top-level header by playing
!   wiring tricks.
  
  Programming With Drip:
  
  Drip provides two interfaces: Receive and Drip. To maintain its
! per-channel metadata, it uses a third interface: DripState. 
! 
! Wire to them like this:
  
    TestDripM.ReceiveDrip -> DripC.Receive[AM_TESTDRIPMSG];
***************
*** 17,22 ****
      DripStateC.DripState[unique("DripState")];
  
! In StdControl.init(), you must call Drip.init(). This initializes the
! sequence number for the channel.
  
  Receive.receive(...) will be signaled when Drip receives a new
--- 36,42 ----
      DripStateC.DripState[unique("DripState")];
  
! In your StdControl.init(), you must call Drip.init(). This initializes
! the sequence number for the channel. If you wire Drip multiple times,
! you must call Drip.init() for each time.
  
  Receive.receive(...) will be signaled when Drip receives a new
***************
*** 26,29 ****
--- 46,56 ----
  the message, as well.
  
+  event TOS_MsgPtr Receive.receive(TOS_MsgPtr msg, void* payload,
+                                   uint16_t payloadLen) {
+    memcpy(&clientCache, payload, sizeof(clientCache));
+    // client acts on the message here
+  }
+ 
+ 
  To make the dissemination propagate epidemically, Drip will
  occasionally signal Drip.rebroadcastRequest(TOS_MsgPtr msg, void*
***************
*** 32,40 ****
  msg, void *payload, uint8_t len), with the length of the payload.
  
  To inject new messages from the PC side, you can use the Drip.java
! component. To inject a new message from the mote, you call
! Drip.changed(). Then, the next time you get a
! Drip.rebroadcastRequest() event, you give it the new message instead
! of the message you had previously cached.
  
  Testing Drip:
--- 59,73 ----
  msg, void *payload, uint8_t len), with the length of the payload.
  
+  event result_t Drip.rebroadcastRequest(TOS_MsgPtr msg, void* payload) {
+    memcpy(payload, &clientCache, sizeof(clientCache));
+    call Drip.rebroadcast(msg, payload, sizeof(clientCache));
+  }
+ 
  To inject new messages from the PC side, you can use the Drip.java
! component.
! 
! To inject a new message from the mote, you call Drip.changed(). Then,
! the next time you get a Drip.rebroadcastRequest() event, you give it
! the new message instead of the message you had previously cached.
  
  Testing Drip:
***************
*** 59,65 ****
  From another Java app, it can be used to inject arbitrary messages. 
  
!   Drip drip = new Drip(<drip channel ID>);
!   MyMsg msg = new MyMsg();
!   drip.send(msg, MyMsg.DEFAULT_MESSAGE_SIZE);	
  
  Known Shortcomings:
--- 92,99 ----
  From another Java app, it can be used to inject arbitrary messages. 
  
!   Drip drip = new Drip(AM_TESTDRIPMSG);
!   TestDripMsg msg = new TestDripMsg();
!   msg.set_data((short)Integer.parseInt(period));
!   drip.send(msg, TestDripMsg.DEFAULT_MESSAGE_SIZE);
  
  Known Shortcomings: