< phantomcircuit>
for reference on linux systems the max number of fd's is typically 1024
< sipa>
phantomcircuit: we already have code for trying to raise the number of fds, if i remember
< phantomcircuit>
return nMinFD; // getrlimit failed, assume it's fine
< phantomcircuit>
lol
< phantomcircuit>
sipa, yeah i see it
< phantomcircuit>
gmaxwell, opinions on changing the default max connections when using poll or on windows?
< wumpus>
luke-jr: I know you're joking but it makes me think, I don't think I've heard heard of *anything* using QtNetwork, let alone hardened P2P code
< wumpus>
phantomcircuit: I think we should still move to libevent at some point, but first things first, I suppose this refactoring will move in the right direction for that
< wumpus>
the thing I'm most worried about, is the same when switching over the P2P layer to libevent: how can we test this enough to be confident enough to merge this, without running into random trouble for users or suddenly losing connectable nodes etc
< wumpus>
I think the whitelisting was a good idea at least, it means we're not exposed to issues for platforms it hasn't been tested on
< phantomcircuit>
wumpus, any opinion on setting the default maxconnections higher on systems with high limits
< phantomcircuit>
the reason not to is that each connection uses memory
< phantomcircuit>
(which reminds me we should have a -maxmemory flag that sets all the other ones)
< gmaxwell>
because memory, and because there currently isn't a need... hosts aren't getting maxed out.
< stevenroose>
gettxoutsetinfo reports on the totals about the utxo set, right? (about total value, f.e.)
< stevenroose>
Does that mean that provably unspent outputs (like OP_RETURN) are not included?