[net2-wg] Collection interface

[Omprakash Gnawali]

> On Fri, 2005-12-23 at 17:24 -0800, Omprakash Gnawali wrote:
> 
> > 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.
> 
> Does this support data types that are longer than the available
> message_t payload?
> 
> Phil

Because we want it to be an application defined data type, I think we
should support arbitrary length data. Of course there is always a size
limit because of the platform but this seems to be the wrong place to
impose such constraint. If Cyclops applications want to ship the image
to the sink, they will appreciate this functionality.

I am going to bet that if someone wants to use arbitrary length data
the user is willing to cope with some inefficiency compared to
fragmenting the data at the application with application-specific
knowledge.

If we want to build a reference collection that fully complies with
this interface, it will require some extra work to handle
fragmentation/reassembly and maybe we will not have something clean by
the deadline but I think it is a good goal to have.

Now thinking about implementation, it might be complex to do
fragmentation/reassembly for dissemination, but for collection, at
least relatively, the task is straightforward because you can
reassemble at the sink and you don't get too much performance hit. The
implications are larger headers, more sequence numbers, and overall
increased complexity in the forwarding engine.

Now that I have said all this, I am OK if the rest of the group is
leaning towards limiting the size of the payload to keep things
simple.