Like I said, DNS lookups are not part of the connection time. To my knowledge people are not having issues with the Connection time limits - and while it is to bad to undercut the standards there - we simply cannot give afford to give a node more than a couple of seconds to do it's thing (consider your average request is, under ideal condition, going to be 6-10 hops).
Both the clients and the node are _heavily_ threaded. On Sat, Aug 26, 2000 at 11:28:41AM -0500, Signal 11 wrote: > > You could try setting up the connect timeout anyways, if a domain name > > lookup takes you 5 seconds you must be a on a very shabby connections (it > > took me about 2, and I'm on a modem... in Indonesia). > > DNS lookups, and by extension any TCP handshake, defaults to a timeout > of 120 seconds per the RFCs (IIRC)[1]. If you guys are bypassing the OS > defaults to lower the timeouts by default, you'll probably going to see > alot more breakage than this. I could see justifying it for a server > which is under high load or as a DoS responder (shorten the latency, > keep the tables clear), but I'm not so sure it's a great idea for > normal use. If this is the result of having to make a blocking call > (as most dns lookups ARE), and the client in question is not threaded... > that may be justification... but it just undescores why threading > of some sort (even primitively) is necessary. > > ~ Signal 11 > [1] Yes, I know packet sizes < 512 are done via UDP, but the > latencies are the same, I believe. > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev > -- \oskar _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
