Oskar Sandberg writes: > 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. > > a) Multiplex over the same connection, meaning that if the reply
DUH. This is exactly what I was talking about. Send individual messages rather then treat a connection as a state machine. What the hell did you think I meant? That we open a TCP connection for EVERY MESSAGE WE SEND? > b) Make any guarantees what so ever about connections being kept up. > Because the synchronous IO limits the number of open connections that a Mmm, and I did mention NBIO, didn't I? Yes, I did. > 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. That's the wrong way to do it. Right Way is to A) move to NBIO, B) quit treating a connection as a state machine. As for wasting resources: Establishing a connection is expensive. Sending a message over an established connection is less so. If I need to send two queries to another node at the same time, which is cheaper? A) establish two connections, send two queries, teardown x2. Other node establishes connections for reply, sends reply. B) establish one connection, send two queries, (possible teardown) Remote node sends two replies (possible re-establish) > 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 ... meaning "I have no clue what you're talking about, so I'm going to shoot it down as a bad idea." Hint, minor changes, major performance boost. Spend some braincycles thinking about it. > [Just use FCP!] Hmm, because foreign nodes don't supply FCP ports as a rule? Just a wild thought. Oh yea, and transient nodes protect you against packet sniffing. FCP does not, unless you have a SSH account on a foreign server to tunnel to. It also involves you hitting the same server for every query, where running a transient node will route you to random remote servers. Do you even understand the differences in threat level involved? Hint: Running a full server grants you no anonymity when they come for your box. Anything you don't want them to see could very well end up being on your system in plaintext. (Files you uploaded/downloaded) You'd have to have an encrypted filesystem to work off of to avoid that attack. > 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. No, it's not message based, it's state-based with verbose state labels. There's quite a large difference. For future reference, try reading and comprehending before blasting people. I'm well aware of how the connections work. Re-using connections != multiplexing. --Dan _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
