[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

Okay, I'll switch my code around to do it the second way.  I can see
that it makes sense.

Just a note, having multiple network ids doesn't really make it "just
another AMid"-- it's more like the dispatch value that comes with an
ethernet frame, which pushes AM up to be a protocol on top of that.

Steve

On Tue, Jun 30, 2009 at 1:52 PM, Miklos Maroti<mmaroti at math.u-szeged.hu> wrote:
> Hi Stephen,
>
>> I think what we're talking about is:
>>
>> We could have an interface which provides the following to 802.15.4 clients
>> Resource as SendResource[client]
>> Send;  - networkId is the first byte of the payload
>> Receive[networkId]
>>
>> Alternatively, we could have
>> Resource as SendResource[client]
>> Send[networkId];  - networkid is not part of the payload
>> Receive[networkId]
>>
>> I prefer the first because I believe it hues more closely to the
>> standard, although we are still dispatching on a non-standard field.
>> Payloads are treated identically from send and receive, though: both
>> include the network byte.
>
> I would prefer the second one.
>
>>> Maybe you anticipate several components on the same mote to use
>>> different network ids?
>>
>> We already have this, right?  AM uses one, and 802154 uses some other
>> ones.  When we talked about this a while back, there was strong
>> push-back from Om and Phil that we must support AM and 802.15.4/IP on
>> the same mote.  That's why we have some of these issues.
>
> What I meant is that you want more components other than these two. In
> fact this would turn the network_id just into another am_type.
>
>>> Now thinking more about the send side I also have some problems. Do
>>> you want the payload to contain the network id when passed to the Send
>>> interface? If no, then the receive/send will be asymmetric, if yes,
>>> then you do not do fanout with send, only with receive. By the way, I
>>> think there should NOT be a built in fanout based on client id. The
>>> radio stack should simply provide a resource arbiter, and the
>>> AMSenderC and Ieee154SenderC should take care of the locking.
>>
>> Doesn't this mean that they will receive sendDone events for messages
>> they did not send?  They could filter these, I just thought it would
>> be cleaner not to do it this way.
>>
>> You're correct about the fanout only happening on receive; we can't
>> wire multiple components to the same receive interface because if we
>> do, we get multiple message_ts returned for the buffer swap.
>
> Well, I thought we would do it like the AM type, so sendDone would fan
> out (just like for AM) by the network type. Only one will receive it,
> the one who sent it.
>
> Notice, that the first option in the top of my mail would NOT allow
> this fan out of sendDone (so that would be a very strange solution for
> me).
>
> Miklos
>