Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
MetaNetDesign
Edit
PageHistory
Diff
Info
LikePages
Discussion document for replacement for wand/wansd Please note: This is related to the wand/wansd programs which are __only__ responsible for distributing and learning other peoples IP/port -> MAC translation. It in particular does not relate to the actual tunnel which is run by Etud, which uses the IP/port -> MAC translations provided to talk to it's peers. Please add any issues you can foresee, or pros and cons of any of the current issues. [MattBrown]'s proposed replacement design for WAND/WANSD is at http://www.mattb.net.nz/metanet/protocol.txt !!! TCP vs UDP TCP makes it harder to spoof source address, and allows things like SSL. TCP requires a connection to be made, either for each query/update (high overhead for both ends) or a persistant connection (more complex, deal with your remote end comming and going, firewalls timing out connections, etc etc). UDP is very simple and non-stateless, but has issues with updates not fitting into a single packet (means that we need to cope with / expect multiple packets for an update) and will have problems doing auth properly. !!! Client/Server vs "p2p" !robustness - no reliance on single (or group) of machines Although if a server (eg deuterium) does go down, the other routers can still talk to each other. Making the current wand talk to more than one wansd is a simple way to fix this, requires a timestamp to be provided by each wansd server (so the clients can pick the "upto date" entry if different entries are ever returned) and the wansd's to have a method to sync themselves to each other. ! Complexity need n^2 paths if every peer talks to every other peer. ipt's routing protocol was n^2/2, not brilliant, but not too bad. I have better ideas of how to reduce this even further with what I've learnt from other routing protocols since then. Perhaps O(n)? AddToMe
One page links to
MetaNetDesign
:
MetaNetToDo
