Alexander Aring <[email protected]> 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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
