See attached. That big block of the same Local connect to the same system is ME. Over night the IP Lease changed and usually I Kick and Block manually. I have tried with Lan Peer Finder loaded and active, and also with it NOT loading at startup. Neither work. Only Kick and Ban of my own IP.
I keep an eye on that view for over 10 minutes and nothing changed. It is just stuck on those systems it is trying to initiate from Local. Needs a specific timeout for local connection attempts. Not to mention 'Allow multiple connections' is Disabled. So why is it trying so many times to connect to the same system?
As to trying to connnect to myself. Perhaps The Auto-discover External IP in the Tracker/Server could get an 'Update at Startup' Check Box. And then an additional check box for 'Ban External IP'. The Ban would not be only for the 'Update at Startup', but if someone has a Static IP, it would prevent this Loopback connection attempt.
Although, I have thought that instead of in Tracker/Server, that the 'Auto-discover External IP' would be better in Connection. As the External IP is for the whole of Vuze.
If you go with this, I suggest it be at the TOP of the Connection Panel. Here is what I think it sould look like:
External IP address [123.456.789.123] Auto-discover external IP [x] At Startup
[x] Block External IP Loopback Connection
This would still allow the External IP to be set Manually, or Only by clicking Auto-Discover. But also alllow automatic update at Vuze Startup. And optionally Block the loopback. I say Block, but it is really a Ban. But the user changes or uses the Auto-Discover. It should remove the previous IP block and replace it with the new External IP. Perhaps when adding to the Blocked IPs have it TAGGED as [External IP Looback Block], or something like that. So it can be swapped if the external IP is updated Manually, or Via Auto-Discover.
So there it is. I can continue to manually Kick/Ban my external IP. But hope that at some point the Timeout of Local outbound connection attempts and also the Loopback problem will be resolved. Not to mention the multiple attempts to the same system.
Definitely a no rush issue. As I can see this being sensitive. So better to get it right that rush.
I keep an eye on that view for over 10 minutes and nothing changed. It is just stuck on those systems it is trying to initiate from Local. Needs a specific timeout for local connection attempts. Not to mention 'Allow multiple connections' is Disabled. So why is it trying so many times to connect to the same system?
As to trying to connnect to myself. Perhaps The Auto-discover External IP in the Tracker/Server could get an 'Update at Startup' Check Box. And then an additional check box for 'Ban External IP'. The Ban would not be only for the 'Update at Startup', but if someone has a Static IP, it would prevent this Loopback connection attempt.
Although, I have thought that instead of in Tracker/Server, that the 'Auto-discover External IP' would be better in Connection. As the External IP is for the whole of Vuze.
If you go with this, I suggest it be at the TOP of the Connection Panel. Here is what I think it sould look like:
External IP address [123.456.789.123] Auto-discover external IP [x] At Startup
[x] Block External IP Loopback Connection
This would still allow the External IP to be set Manually, or Only by clicking Auto-Discover. But also alllow automatic update at Vuze Startup. And optionally Block the loopback. I say Block, but it is really a Ban. But the user changes or uses the Auto-Discover. It should remove the previous IP block and replace it with the new External IP. Perhaps when adding to the Blocked IPs have it TAGGED as [External IP Looback Block], or something like that. So it can be swapped if the external IP is updated Manually, or Via Auto-Discover.
So there it is. I can continue to manually Kick/Ban my external IP. But hope that at some point the Timeout of Local outbound connection attempts and also the Loopback problem will be resolved. Not to mention the multiple attempts to the same system.
Definitely a no rush issue. As I can see this being sensitive. So better to get it right that rush.
