Penguin
Diff: MetaNetDesign
EditPageHistoryDiffInfoLikePages

Differences between version 7 and predecessor to the previous major change of MetaNetDesign.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 7 Last edited on Sunday, January 19, 2003 11:58:04 pm by PerryLorier Revert
Older page: version 2 Last edited on Sunday, January 19, 2003 8:49:17 pm by JamieCurtis Revert
@@ -1,18 +1,25 @@
 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. 
  
 !!! 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. 
+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