On Thu, 04 Sep 2003, Gordan wrote: > On Thursday 04 September 2003 08:23, Dan Merillat wrote: > > I understand that. However, unless the border node is heavily CPU bound, that > would probably be slower in the long term than having one really big border > node and no internal nodes - from the view of the outside, that is. Or am I > wrong here? Is proxying a request faster/less intensive than serving? I > wouldn't have thought so...
No, to the outside it's not as good as having one huge node. It is a chokepoint to all the internal nodes. From an internal standpoint, you get faster results since portions of the keyspace end up being specialized within your LAN/WAN. Toad: How does the loop detection code work? Given the hypothetical situation: Data is outside the lan, in a part of the keyspace that an internal node responds quickly to. If a query hits the gateway supernode and goes back inside, is it possible to get back out? > Yes, but the outside nodes should drop the 10.x routes automatically anyway, > as far as I understand. Yes, but that also drops the keyspace associated with those nodes, making any data stored inside your lan invisible. The network will function, but non-optimally. > Ideally, you'd block everything outgoing as well, then only enable > specifically the ports you want. Ideally for WHAT? A prison? Yes. A corperate server farm? Yes. A LAN designated for phone-support personel? Yes. An appartment complex providing high-speed access to the tenants? _NO_NO_NO_. You can't always count on a magic firewall to do the blocking for you, since freenet isn't "well behaved" by internet standards. You can block SMTP traffic by blocking port 25, but there's no way to block freenet traffic short of cutting off all connectivity in both directions. > But will it really break things that badly? Surely, the nodes will quickly > learn to route to the border node(s) instead of trying to route further in. > In fact, they won't even bother routing further in because the references > will have private IP addresses on them which will get dropped before making > it into the routing table in the first place. Or am I wrong here? Exactly. But the problem that I'm trying to explain is this: Outside node 1 searches for key "KA". Routes it to your gateway, gateway routes it to internal node 2. Node 2 responds with a 10.x address, gets passed through the gateway to 1. Now 1 has a 10.x noderef for that keyspace and it gets ignored. Thus, a successful transfer did NOT improve routing at all. If the gateway resets the DS, node 1 gets the data "from" the supernode. Now the routing table learns that the supernode is a good place to go for KA. See the difference? --Dan
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
