Your wasted space issue makes a lot of sense to me. For deeply-nested messages, the extra overhead of storing a message type at each level may be unjustifiable, especially if a given message is not likely to be used to contain more than one different submessage.
Perhaps there could be a compromise, with some sort of prefix code system. For instance, given your example below, I would consider it highly likely that many different components would like to use a Routed Reliable Active Messages, so we could associate that three-message prefix with a single AM type. Automatic recursive unmarshalling would still be possible with such a prefix scheme, but might require a bit more "smarts" in the decoder.
Conversely, I don't consider it very likely that different applications would put their own messages under SurgeMsg, so perhaps SurgeMsg is not really a container msg and thus does not even need its own type at all.
As a sidenote, getBuffer() doesn't seem to do anything that couldn't be done at compile time. All it does is make a call to offsetof() to find the start of the data field, and I'd imagine that's a compile-time macro anyway.
Gil
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
