frottle: Defeating the Wireless Hidden Node Problem

jasonjordan writes "The West Australian FreeNet Group was the first to go War Flying - and now we've released "frottle" (freenet throttle) - an open source project to control & manage traffic on fixed wireless networks. Such control eliminates the common hidden-node effect even on large scale wireless networks. frottle works by scheduling client traffic by using a master node to co-ordinate - effectively eliminating collisions! Developed and tested on the large community wireless network of WaFreeNet, We've found it has given us a significant improvement in network usability and throughput. "

Comments

Re:Good news.

[Phydoux]

The article relates to 802.11, however this would probably work on packet radio too.

You could achieve the same thing on packet radio by using a digipeater instead of having all nodes transmit/receive on the same frequency, and I think you'd get better thruput with a digipeater than using Frottle.

Attention Project Namers:

[MyHair]

Never call anything Freenet. It is too generic a term and is used for several different commercial and nonprofit organizations and projects.

It's much worse than Firebird.

If nothing else, realize that it messes up people who search for you on Google because of all the @freenet.com email addresses.

token-passing on top of CDCSMA

[Medievalist]

Seems like using a fork in a drillpress for a daquiri blender... doable, but rather outside the intentions of the tool designers!

Perhaps this will stimulate some hardware vendor to make token-passing wireless network hardware to eliminate the latency problems. IBM, Madge and Thomas Conrad must have boatloads of relevant expertise already....

AODV

[Anonymous Coward]

I dunno, seems a bit of a kludge. Why not run the 802.11 network in ad-hoc mode and dynamic route via AODV. If there are bandwidth problems, pop in more nodes==routes. Yes, the peak performance is necessarily lower, but the worst-case performance must be much better?

Re:Just read the article..

[RevMike]

..and all this is, is a glorified token ring implemented at the OS layer on top of 802.11.

Color me unimpressed.

Why are you critical of the solution? It appears to work well and is inexpensive. What is wrong with that?

A friend who used to work for a "baby bell" was involved with a project to provide VoIP and video services, as well as internet, over their DSL infrastructure. The problem that they ran into was that IP, as supported by their commodity DSL equipment, did not support QoS. Their solution was to tunnel a more advanced network protocol (ATM I think) over the entire DSL IP connection. Then they ran their voice and video over ATM directly and ran IP as another tunnel over ATM. It wasn't elegant, but it was cheaper and more effective than manufacturing new devices.

Anytime you can use commodity off-the-shelf hardware, you can usually save money.

Re:TokenRing?

[El]

It's also an order of magnitude more difficult to implement (due to problems like recovering lost tokens) and was limited by spec. to 16Mbits/second, with a higher proportion of those bits devoted to overhead. Oh, and chipsets to do Token Ring were an order of magnitude more expensive. Token Ring is to Ethernet as Steam Engines are to Internal Combustion engines -- yes, if they'd put as much time, energy, and money into developing Token Ring as they have into Ethernet, it would be a better technology than Ethernet (mostly because like you said, worse case packet delivery time is deterministic). But they haven't!