On Thu, Sep 04, 2003 at 09:41:28PM -0400, Dan Merillat wrote: > 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?
Every request has a unique ID (a 64 bit number). We keep tags around (RequestDone objects) for old requests, so we don't serve them more than once. Yes, it will get back out, by backtracking - when the node forwards it internally and it fails to find anything, it will fail and return the the border node. > > > 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. Well, it will help the border node to find data. The internal specializations will hopefully adapt as part of the border node's specialization. > > > 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. Except for the fact that freenet needs two way connectivity on connections. > > > 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. No, it doesn't get ignored. The noderef is reset to the gateway node's reference. In any case, references are no longer such a big issue in NGRouting - the border node doesn't give the requester a new node, but it does improve the requester's respect for the border node. > > 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 -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
