home 
wiki
wiki
Spelling: MWRPAdhocFrottleFlowcharts
These here are some flowcharts I've been working on that describe how
I think an OLSR version of Frottle should work.
Previously I've written that we should try to write a version of
Frottle that works for any Adhoc routing protocol - or no routing
protocol at all. I've since learnt a bit about OLSR plugins and have
decided that OLSR's neighbor databases would be very handy to use.
Also, OLSR seems to be streets ahead of other Adhoc routing protocols
in terms of cross-platform implementation - so we don't lose much by
not supporting other protocols.
I believe a Frottle OLSR Plugin may need to use a new type of Hello
packet - replacing the regular hello packet of regular OLSR or the
LQ_hello packet of the ETX plugin. Because Frottle requires that all
packets be delayed until polled, the regular hello packets will
probaly not work as they are sent at timed intervals
These flowcharts are a work in progress, but I think the reader will
get the gist of what I'm on about. The idea is closely based on the
ideas in these two papers:
http://www.eecs.berkeley.edu/~ergen/docs/wtrpiscc.pdf
http://faculty.cs.tamu.edu/welch/papers/icnp01.pdf
The main problem to overcome is that not every node is a neighbor of
every other node. So tokens need rules to be able to backtrack when
they hit a dead end. Nodes need to keep track of the node that passed
them the token - known as the predecessor, and of the node that they
will pass the token to - known as the successor. Also, a node may
receive a token more than once, so it may have more than one
predecessor and successor. The node needs to keep track of the order
of it's predecessor/successor pairs.
MAIN FUNCTION
RX FUNCTION
TOKEN FUNCTION
SOLICIT SUCCESSOR FUNCTION
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]