[net2-wg] tos msg vs ADU send for collection

[Philip Levis]

On Fri, 2006-01-13 at 14:58 -0800, Omprakash Gnawali wrote:
> This is a follow up on a specific thread from our meeting
> yesterday. It was mentioned that providing tos msg send will enable
> implementing ADU send on top of it but not necessarily the other way
> around.
> 
> It is not clear why this is the case. One can call the ADU send with a
> tos msg as an argument; the ADU send which will package it inside its
> own tos msg. The argument why this does not work is because there are
> headers in a tos msg. As far as I can tell, collection applications do
> not care about the header in a tos msg. Users of collection should
> only care about data.
> 
> Are there instances when users of collection care about the header ?
> If there are instances of this then collection must provide a tos msg
> send interface.

I don't understand. Are you saying that if I provide an

interface Collect<message_t*>;

then in my

Collect.send(type* val, uint8_t len) { ... }

I can copy a message_t into a message_t payload (message_t tunneling)?
By definition, the former is larger than the latter's payload. 

Or are you thinking that message_t is a special case, and that you only
embed the payload? I assume you'd be doing this with a generic. Would
message_t* then be a special case, it its own (non-generic)
implementation?

I've always thought that a lot of the complexities of TinyOS networking
could be removed by instituting judicious use of copies. E.g., a lot of
the weird contortions (e.g., right justification) of message_t could be
avoided if the packet layer translated a data-link-independent message_t
into a data-link-specific buffer.

As I commented on briefly at the end of the telecon, copying in higher
layers of the stack can be a one-way ticket. That is, once you institute
a copying approach, then each successive layer has to copy. E.g., if I
want to implement some kind of retransmission/transport on top of
collection, then what I want to pass is a transport_packet_t. However,
if I want an application to use this transport, e.g., send an
app_packet_t, then I'll get this behavior:

app passes app_packet_t to transport
transport copies app_packet_t into transport_packet_t
transport passes transport_packet_t to collection
collection copies transport_packet_t into message_t payload
collection passes packet to data link layer

That is, you get into a situation where you have to copy at each layer. 

I absolutely agree that just being able to pass an ADU and then have it
sent out makes life a lot easier. The problem is that this only works if
the ADU layer is just above the packet layer. Otherwise, it has trouble
scaling as you build up networking layers.

So let's try this another way: is there a way to provide an ADU sending
abstraction without requiring copies? E.g., a component that you could
layer on top of a packet layer (or another ADU layer) that would give
you a nicer interface without encountering these problems? 

How about something like this:

interface AduSend<adu> {
  command adu* getAdu();
  command error_t sendAdu(adu*);
  event void aduSent(adu*, error_t err);
}

It sits on top of a standard Send interface:

generic module AduSender(typedef adu) {
  provides interface AduSend;
  uses interface Send;
};
implementation {
  message_t msg;

  command adu* AduSend.getAdu() {
    return (adu*)call Packet.getPayload(&msg);
  }

  command error_t sendAdu(adu* a) {
    if (a != call AduSend.getAdu()) {
      return FAIL;
    }
    else {
      return Send.send(&msg);
    }
  }
  
  event void Send.sendDone(message_t* m, error_t err) {
    if (m == &msg) {
      signal AduSend.sendDone(call AduSend.getAdu(), err);
    }
  }
}

Now, I do see some issues with this interface. Specifically, it's easy
for the caller to make the mistake of modifying the ADU while it's in
flight. But by taking an approach such as this, you can keep the
collection engine packet based (not requiring copies) while providing
programmers the ability to use the alternative AduSender if they want.

Thoughts?

Phil