Default Mode (A/P) according to IP address

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Default Mode (A/P) according to IP address

Post by TheParanoidOne » 2003-05-31 17:44

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?
The world is coming to an end. Please log off.

DC++ Guide | Words

Garet Jax
Posts: 34
Joined: 2003-05-26 15:06
Location: Poland
Contact:

Post by Garet Jax » 2003-05-31 18:11

Brilliant !!! :D
"Blessed is he who expects nothing,
for he shall never be disappointed."

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-05-31 19:16

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? :)

Twink
Posts: 436
Joined: 2003-03-31 23:31
Location: New Zealand

Post by Twink » 2003-05-31 21:23

There are some clients (BCDC) as far as I know that can get the external IP from the hub (if the hub supports it also). No need for dynamic dns hacks. As for testing the port from remote location, I think they normally have a function in the server that does that.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-05-31 21:32

$UserIP isn't anywhere near universally supported, so it's not a viable solution right now. Port checking does probably belong in the server, but it doesn't seem to be part of DCH++, or NMDC of course.

TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Post by TheParanoidOne » 2003-06-01 04:52

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 ...
The world is coming to an end. Please log off.

DC++ Guide | Words

Locked