Alexander Aring <aar@xxxxxxxxxxxxxx> wrote:
>> In a classic SVR4 STREAMS works, it would have been just another
>> module. (No, I'm not a fan of *STREAMS* or of SVR4 in general,
>> although I liked some of the ideas).
>>
> ok, I see you complain about "having a virtual on top of wpan
> interface", or?
> I wanted to talk at first about the queue handling which is introduced
> when 6LoWPAN is not a virtual interface anymore. Or do you want to have
> a queue in front of 6lowpan adaptation (see other mail reply with ASCII
> graphics).
I would like to have a single queue, as close to the hardware as possible,
such that BQL can do it's thing easily. Should we rethink outgoing fragment
handling for 6lowpan? Clearly the BT people had a need.
I don't think they've had a chance to respond to your complaints.
> We can change that you can run multiple interfaces on one
> PHY. Currently we just allow one, because address filtering. Disable
> address filtering
> we will loose ACK handling on hardware.
Yes, that's a limitation of some hardware, and if you enable multiple PANIDs,
that might be the consequence....
> I can try to implement all stuff in software "for fun, maybe see what
> we can do to handle ACK in software, etc" Then you can run multiple
I'm not asking you to do it, I'm asking, now that we've gotten to a certain
point, we have a better idea what the various requirements are, and can we
re-evaluate things and maybe tweak some things.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
