[net2-wg] Collection interface

[Philip Levis]

On Dec 23, 2005, at 6:23 PM, Omprakash Gnawali wrote:

>
>> 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.
>

What does Intercept mean if you can send arbitrary-length objects?  
I.e., how do you give the upper layer information on the  
fragmentation/defragmentation?

Do you assume that objects are re-assembled on a per-hop basis, or  
that it's end-to-end? In the former case, how do you allocate  
buffering space?


> 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.

If re-assembly is end-to-end, then you do assume end-to-end NACKs/ACKs?

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'