Hello!
There are a *lot* of people who come here thinking that DC++ doesn't work, mainly because they are behind a router and the default mode of DC++ is in Active mode.
How about the default mode is based on the following:
1. Detect IP
2. If IP is in private range (eg. 192.168.*.*) set mode to Passive
else set mode to Active.
This would only be done when no DCPlusPlus.xml file exists - ie. at installation. At all other times the mode would be picked up from the file.
This idea sprang fom something that GargoyleMT mentioned a while ago about reducing problems by making the software more intelligent. This would mean that most people would have fewer problems at the beginning.
Those that knew what they were doing, would evetually find the Active mode setting anyway, and be able to activate it.
It seems like a good idea to me, but I'm sure there are other pros and cons, so anyone have any comments?
Default Mode (A/P) according to IP address
Moderator: Moderators
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Well, it should check for all of the RFC 1918 private networks, or at least 192.168/16 and 10/8... Personally, I'd almost like a dialog box, but that would confuse people. If there was an in-application Log of some sort, you could print a nice big Red message about "possible misconfiguration". Or maybe have a blinking icon in the application's status bar that would pop-up a dialog.
A more thorough solution would test if the port was actually reachable from the outside, but you'd need the assistance of another computer to do that... And if one was set up by some kind soul, it would have to be fortified in such a way that it couldn't be abused.
I'm half tempted to look at other GPLed P2P applications and see if they have code to transverse firewalls (to determine external IP)... at least that would get rid of the dynamic DNS hacks. But wouldn't solve the problem of unreachable ports.
Thoughts on my thoughts?
A more thorough solution would test if the port was actually reachable from the outside, but you'd need the assistance of another computer to do that... And if one was set up by some kind soul, it would have to be fortified in such a way that it couldn't be abused.
I'm half tempted to look at other GPLed P2P applications and see if they have code to transverse firewalls (to determine external IP)... at least that would get rid of the dynamic DNS hacks. But wouldn't solve the problem of unreachable ports.
Thoughts on my thoughts?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
It may or may not be feasible to get the external IP. Who knows. Maybe that's the end goal, but what I suggested is a simple fix which would be a stop-gap solution that I think would solve a *lot* of problems straightaway (or at least just put them off till later )
Just keep the IP resolving entirely at the client, without making any sort of network connections.
If this were in Java, I could have coded it, integrated it and tested it within the hour, instead of just talking about it. :sigh:
Time to go back to testing the RAM in my ill machine ...
Just keep the IP resolving entirely at the client, without making any sort of network connections.
If this were in Java, I could have coded it, integrated it and tested it within the hour, instead of just talking about it. :sigh:
Time to go back to testing the RAM in my ill machine ...