I like the approach that Cory has taken with his protocol code, and think this could be extended further. Most RPC systems support a notion of a stub generator that emits specialized code to marshal/unmarshal message types on the wire. Generating appropriate NesC components to handle this as well as the buffer management would be fantastic. It could even be extended to support specific retransmission policies, etc. moving the complexity from runtime to compile time. Good course project idea...
On Tue, 2004-03-23 at 18:03, Philip Levis wrote: > On Tuesday, March 23, 2004, at 01:33 PM, Gilman Edwin Tolle wrote: > > > Let me see if I understand what you mean. > > > > The current system looks like this: > > > > TOS_Msg.type = AM_SURGEMSG > > TOS_Msg.data ---------> MultihopMsg.fields > > MultihopMsg.data -----> SurgeMsg.fields > > > > What we have now is a single global namespace for all nested > > combinations of messages. That is, a TOS_Msg with type AM_SURGEMSG > > must contain a MultihopMsg containing a SurgeMsg. > > > > > > What I'm arguing for is something more like this: > > > > TOS_Msg.type = AM_MULTIHOPMSG > > TOS_Msg.data ---------> MultihopMsg.fields > > MultihopMsg.type = MH_SURGEMSG > > MultihopMsg.data ------> SurgeMsg.fields > > > > I'd like to see explicit type information at each level, with a > > separate namespace for each level of containment. Following what Alec > > said, this allows a cleaner encapsulation of services, and requires > > less coordination between users of protocols at different layers. > > > > The issue is the possibility of wasted space. If you have 256 AM IDs > available, why add another level of dispatch? For one level, this makes > sense; but when you have fine-grained layering (as Cory's stuff does), > this becomes onerous. E.g.: > > AM -> ReliableAM (retransmissions) -> Routing -> SurgeMsg -> > SurgeMsgType > > I recall that we wanted to do this way back when with mig, to allow > nested packet types, but there was this tricky corner case where it > would break down. > > > > Your message seems to imply something like my second example, but with > > each nested type having a globally unique value. I would actually > > argue that as long as the type of each contained message is always > > stored by the container message in a field named "type", possibly with > > a fixed offset from the start of the message, then we could have a > > separate namespace at each level and still perform automatic recursive > > processing. Each message type will still have a uniquely associated > > ID, but it needs only to be interpreted in the context of its > > containing messages. > > > > I'm not sure why this would require wiring information in mig, and in > > fact, because each message is wholly independent of its container, it > > should require even less information about the containment hierarchy. > > > > If a unique name is required for each distinct nested set of messages, > > as in the current model, then the namespace would probably be > > exhausted sooner than if a name was only associated with each message. > > If we allowed overlap, such that two messages could share the same ID > > as long as one was intended to be sent out within a MultihopMsg and > > the other to be sent out within a BcastMsg, then we would have even > > less chance of namespace exhaustion. > > Namespace exhaustion isn't nearly as great a problem as namespace > management and efficient structuring. The current getBuffer() approach > pushes all of this to run-time, when really it could be done at compile > time with some dynamic component generation (as Cory has done). This > also gives you better type checking. > > However, I think that you're right, at a coarse grain. One could > imagine, for certain major services, such as routing and dissemination, > you may add another single level of dispatch. The problem is, when done > at a fine grain, things go ill. > > Phil > > ------- > > "We shall not cease from exploration > And the end of all our exploring > Will be to arrive where we started > And know the place for the first time." > > - T. S. Eliot, 'Little Gidding' > > _______________________________________________ > Tinyos-users mailing list > [EMAIL PROTECTED] > http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users _______________________________________________ Tinyos-users mailing list [EMAIL PROTECTED] http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users
