On Fri, Aug 02, 2002 at 09:47:03AM -0400, Dan Merillat wrote: > > guardian at ntplx.net writes: > > > I do agree with Oskar, that transient nodes have trouble getting data. > > Should we be ignoring those forced to work behind a non-editable > > firewall config? If freenet truly fails completely behind a NAT > > firewall, I think it needs to be fixed. How? I don't know that. > > It can be done, but won't for a while. Switch to a message based protocol > so multiple queries can run bidirectionally over the same TCP connection.
RTFD. It already does this (how stupid would we need to be to not do that? If you look in the OCM page you'll see many connections have send hundreds and thousands of messages, and they have fields indicating activity for both send and receive). What it doesn't do is: a) Multiplex over the same connection, meaning that if the reply connection is busy, which is completely possible since the masqueraded node will not make more connections then it needs to send the short request messages, the reply will fail. I had code in place to make it wait if there was a busy connection and it couldn't make new ones - but GJ removed it as a cludge (and I tend to agree). b) Make any guarantees what so ever about connections being kept up. Because the synchronous IO limits the number of open connections that a node can support, and because most nodes are very busy, idle connections time out very quickly (the LRU is always thrown out first). I suppose one could make transient nodes try to force keep their connections open - but this would be annoying destructive behavior. > This way, as long as the transient has a query outstanding it keeps > the TCP connection open. Answer(s) all go back on the same connection, > even for multiple outstanding queries. > > It's not an entirely major overhaul of FNP, but not likely to happen > overnight. For one, messages have to be tagged so they go to the > right job, etc. More likely now that kaffe supports NBIO. It would not be a major overhaul to make sure that messages could make it back to masqueraded nodes most of the time. It would entail adding a bunch of cludges to the protocol, destroying some of the layer seperation, and wasting the resources of nodes that are actually doing real work - but it would not be a major overhaul. The simple answer to why this will not be done is that there is no real interest in making it possible. If we could easily make it possible for masqueraded nodes to play a real part in the network, then I think that everyone here would agree that that would be spectacular, but without that, I see little point in going out of our way to help them be leeches. We already have a protocol designed for people who want to access freenet nodes without playing a real part in the network - that protocol is query reply based, always uses the same connections, is more suitable for the purpose, and will work through any NAT you wish to throw it at. It is called FCP. There is absolutely no reason why masqueraded users couldn't just use FCP directly to real nodes (any anonymity provided by a transient node is just bullshit). > Until then, NAT sucks. NAT sucks. And for the future, don't reply and confuse people when you don't know what you are talking about. I don't understand where in the world you could have gotten the impression that FNP is not message based, it is completely evident from all the documentation and the code that it is. Since FNP _is_ documented, there is absolutely no excuse for making up responses on the fly. -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
