[net2-wg] Collection interface

[Omprakash Gnawali]

This is what I am thinking as a top-level interface for collection
protocol.

We had a discussion on whether we should consider multiple sinks in
the collection protocol but we did not decide what multiple sinks
meant. There are two interpretations of multi-sink scenario in the
context of a collection protocol:

1. Collection protocol has an internal capability to construct
multiple trees but the multiple sinks are never exposed to the
application running on top of collection. It is up to the collection
protocol to define and implement the behavior -- use multiple sinks
for failover or other reasons.

2. Collection protocol exposes the capability for applications to be
able to send data to a specified sink. In most cases, collection
protocol might not provide this capability (it might not construct
multiple trees or discover routes to multiple sinks) in which case the
collection protocol decides to ignore "sink" or collection protocol
implements a simpler interface that only has a single collect call.


The consumer interface (on the sink(s)):

interface collectRecv {
   event result_t collectRecv(void *data, uint8_t len, addr_t src);
}


The producer interface (on the sources):

interface collect {
   command result_t collectSink(void *data, uint8_t len, addr_t sink);
   command result_t collect(void *data, uint8_t len);
}


>From what I understand, we are going to follow the simple and existing
policy on how buffers are managed -- the applications are responsible
for maintaining their buffers. So the application will maintain
buffers corresponding to *data.

Another decision is whether the arguments are void *data to
collect/Sink and collectRecv. I think it will ease application
development a lot if the applications are not responsible for dealing
with TOS Msg. They instead deal with data type of their
choice. Instantiating generics to the appropriate type instead of void
*data will make it even easier for applications.

Regarding the intercept interface, there might be two types of
in-network packet processing -- application specific and generic
packet processing application to all the packets. I do not know how
common the first case is, but if it is common then we might consider
providing an Intercept interface that hands over void *data or <t>
data to the application rather than TOS Msg. Otherwise, we can stay
with the current Intercept interface which looks something like this
(copied from Intercept.nc):

interface Intercept {
  event result_t intercept(TOS_MsgPtr msg, void* payload, uint16_t payloadLen);
}

My only comment here is passing msg ptr and payload seems
redundant. Lets make them separate because they are there for two
different usage models.

Can someone remind me some good examples of using intercept interface.

- om_p