Per IP-address peer limiting?

[kdeme]

First off:
I'm not sure if the application the right place to do this. Perhaps this should be arranged system wide as this is typically a kind of restriction that can be variable per system. However, some advice on it should be formulated then.

The concern is that when having a limitation of amount of connected peers (see #107 & #108) combined with certain high timeouts on the handshakes in the rlpx protocol and sub-protocols that one node could easily launch many connects and allow them to timeout hogging up the connections.
This is obviously not completely correct as currently the limit is not enforced by amount of open connections but by amount of actual completed handshakes (and thus fully connected peers, which would be more intensive for a node to pull off). Just mentioning this part, in case we would change that.

However, there is still a higher limit that remains valid which is the open files limit on Unix systems.

First step should probably be to investigate if there are actually locations where there is no timeout at all (other than the TCP timeout): like are these OK?
Basic solution could also be to just lower the timeouts with a decent amount. (For Whisper I actually never used the 10 second timeout)

[jlokier]

It's worth a note that some IPs appear to be heavily used NAT exit points for ISPs. In particular, from China recently there was one IP responsible for about 1/3 of incoming connections, with different enode keys. Reverse DNS suggested an ISP IP.