Sure. If you look at the Deluge source, the advertisement contains a source address and an advertisement type field, which Deluge uses to detect advertisement messages from the PC. At the time, I couldn't justify putting those fields into the Drip message header. The Drip payloads are so small, in general, and doubling the size of the Drip header to support the uncommon case of injection through a Drip node seemed unwarranted.
However, were I to write Drip over again today, I'd do it, if for no other reason than that having a source address field in the packet would make debugging and management easier. The Drip behavior you describe does sound like a bug. Are any of your nodes rebooting? A rebooting node that loses its data and requests new information from its neighbors will cause their Trickle timers to return to a high update rate. This is normal behavior. But, if none of the nodes are rebooting, about how long does a node have to run before its timer rolls over? Gil On 1/31/06, Joe Polastre <[EMAIL PROTECTED]> wrote: > Can you clarify why I cannot Drip to a node running Drip, similar in > the way that I can either Deluge to a node that runs Deluge or a node > that runs TOSBase. That flexibility has been extremely valuable in > application development. > > I understand that Drip does not do this currently because it sends all > advertisements over the radio (thus, messages from the PC are only > responded to on the radio, and not back through the UART when such a > request is issued). Why was the design decision made to not support > the Deluge style of interaction? > > Lastly, with the code in CVS, I've seen a "roll-over" effect. > Basically the trickle timer "rolls-over" and goes back to a very high > update rate after having slowed down due to no new advertisements. I > would classify this as a bug, yes? > > -Joe > > On 1/31/06, Gilman Tolle <[EMAIL PROTECTED]> wrote: > > Thanks for the heads-up. It's checked into CVS now. > > > > Gil > > > > On 1/30/06, Joe Polastre <[EMAIL PROTECTED]> wrote: > > > My CVS does not have apps/TestDrip which is required by > > > net.tinyos.drip.* to compile (according to the Makefile). > > > apps/TestDripDrain does exist, however. > > > > > > -Joe > > > > > > On 1/30/06, Gilman Tolle <[EMAIL PROTECTED]> wrote: > > > > I'm the Drip author, and it seems like the README file wasn't included > > > > in the TinyOS source tree for some reason. I just checked it into CVS, > > > > and I've attached it to this email also. > > > > > > > > Gil > > > > > > > > On 1/30/06, Liu, Ping (GE, Research) <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Hi All, > > > > > > > > > > Drip has been mentioned in several places as the better approach than > > > > > Bcast, > > > > > but I haven't been able to find any decent documentation at all. > > > > > Anybody has > > > > > pointers to it? > > > > > > > > > > Thanks for the attention! > > > > > > > > > > -T. > > > > > > > > > > _______________________________________________ > > > > > Tinyos-help mailing list > > > > > [email protected] > > > > > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Tinyos-help mailing list > > > > [email protected] > > > > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
