Quote from: achow101 on February 01, 2016, 03:59:17 AM

I think that is actually a bad idea. You run into memory issues at some point and having more connections takes up more bandwidth. I tried setting MAX_OUTBOUND_CONNECTIONS to something really high before and it crashed the program. It just took up way to much memory.

I don' think you would have significant issues if you would increase MAX_OUTBOUND_CONNECTIONS to 16. But in any case as I previously mentioned, I am quite sure it will still not solve the problem that there are much more IPv4 peers than IPv6 peers connected to and from the node, unless the maximum outbound connections setting is being separated for each IPv4 and IPv6 addresses.

Quote from: .anto. on February 01, 2016, 03:29:45 AM

I think it might be better to have an option to prioritize one network over another e.g. get as many IPv6 connections as possible before getting IPv4 connections.

I think I will try writing some code up and submitting a PR for that.

I think it will be more complex to implement that kind of network type prioritisation. Suppose that you want to prioritise IPv6 over IPv4. How do you manage the threshold of the number of IPv6 peers before you allow IPv4 peers to be connected to the node and being connected from the node? How about if the nodes would never reach that threshold, resulting you have less IPv6 peers and no IPv4 peer for a long time? Would you use a dynamic timer to avoid that issue? As the network is dynamic, would you keep maintaining the number of IPv6 peers to always above the threshold regularly? Or would you manage that base on the timer? And so on

And if you manage to find the solution for that without increasing MAX_OUTBOUND_CONNECTIONS or the maximum outbound connection slots remain 8, the chances that the node will have less IPv4 peers for longer time than before the implementation of your solution is quite high.